PDF Archive

Easily share your PDF documents with your contacts, on the Web and Social Networks.

Share a file Manage my documents Convert Recover PDF Search Help Contact



a .pdf



Original filename: a.pdf
Title: Design Patterns
Author: glory

This PDF 1.5 document has been generated by Microsoft® Office PowerPoint® 2007, and has been sent on pdf-archive.com on 16/06/2011 at 04:48, from IP address 124.106.x.x. The current document download page has been viewed 1113 times.
File size: 1.7 MB (53 pages).
Privacy: public file




Download original PDF file









Document preview


Extending Object-Oriented
Programming
 OOP was originally introduced as programs became

larger and more complex.
 The idea was to wrap functionality inside objects. In
other words, the inspiration was to divide and conquer.
 Until OOP appeared, you could divide your code into
functions, but that wasn’t enough in the long run. As
programs became longer and longer, some way of
dividing them up in terms of easily handled concepts
was needed. What those concepts were, depended on
the program itself, and those concepts came to be
known as objects.

The big four OOP building blocks
 Abstraction is the good kind of breakdown
 Abstraction isn’t a programming technique; in

essence, it just means that you conceptualize a
problem before applying OOP techniques.
 Abstraction is all about breaking your approach to a
problem into natural segments.
 Working with design patterns often means spending
more time on the abstraction part of the process than
on the concrete classes part.

The big four OOP building blocks
 Encapsulation - you wrap methods and data up to the

object
 You remove the complexity from view and make it into
an easily graspable object.
 When you encapsulate functionality into an object,
you decide what interface that object exposes to the
world.
 you decide what getter and setter methods and/or

public properties your objects present to the rest of
the application so that the application can interact
with it.

The big four OOP building blocks
 That’s the idea behind encapsulation — you hide the

complexities inside objects and then create a simple
interface to let that object interact with the rest of your
code.
 Design patterns are particularly big on encapsulation.
 One of the primary design insights here is that you

should encapsulate what changes the most.
 Extracting the part of your code that changes the most,

or that needs the most maintenance, and encapsulating
that part into its own object for easier handling.

The big four OOP building blocks
 Polymorphism: the ability to write code that can work

with different object types and decide on the actual
object type at runtime.
 For example, you might want to write code that
handles all kinds of different shapes — rectangles,
circles, triangles, and so on. Although they’re different
shapes, they all have in common certain actions as far
as your code goes — for example, they can all be
drawn.

Start with this Shape class that draws a generic shape when you
call its draw
method:

class Shape
{
public virtual void Draw()
{
MessageBox.Show("Drawing a Shape");
}
}

Then you inherits a new class, Rectangle, from Shape, and let it
draw a rectangle when you call its draw method as follows:

class Rectangle : Shape
{
public override void Draw()
{
MessageBox.Show("Drawing a Rectangle");
}
}

Draw a Shape
Shape myShape = new Shape();
myShape.Draw();
myShape = new Rectangle();
myShape.Draw();

 So you used the same variable, shape, to hold a shape

object and a rectangle object,
 In this way, you can decide what type of object to load into
the shape variable at runtime, leaving your code
unchanged.

The big four OOP building blocks
 The last of the formal cornerstones of OOP is

inheritance: the process by which one class can inherit
methods and properties from another.

Design Patterns
 Polymorphism often comes into play when you work

with design patterns because design patterns tend to
favor composition over inheritance. (You use
composition when your object contains other objects
instead of inheriting from them.)
 Inheritance sets up “is-a” relationships — Rectangle

“is-a” Shape, for example. As you’re going to see,
however, that can introduce unexpected rigidity and
problems into your code, especially when it comes
time to maintain that code.

Design Patterns
 When you use composition, your code contains other

objects, rather than inheriting from them. And to be
supple enough to deal with the various kinds of
contained objects in the same way, with the same code,
design-patterns often rely on polymorphism.

Composition versus inheritance
 Create a base class – Vehicle with a Go() method
 Create classes and inherit the Vehicle class.


Cars, Bus, Jet, Airplane
class Vehicle
{
public Vehicle()
{}
public void Go()
{
MessageBox.Show("I am driving");
}
}

class Car : Vehicle
{
}
class Bus: Vehicle
{
}
class Airplane: Vehicle
{
}
class Jet: Vehicle
{
}

Where is the problem?
Car car = new Car();
car.Go();
Bus bus = new Bus();
bus.Go();
Airplane airplane = new Airplane();
airplane.Go();

The Problem...
 Spreading the way a single task is accomplished —

driving a car or flying
 An airplane or Jet — across several generations of
classes.
 How you want to handle that task is going to change
fairly often, having to edit all those classes becomes a
maintenance issue.

Inheritance isn’t the answer
 when you have to spread out the handling of a

changeable task over several generations of classes.
You’re going to be maintaining a lot of customized code
across generations of classes when that task changes.
 And as the derived classes get to be long and involved,

it’s going to be tough to maintain them through all
those changes. You’re going to have to update the go
method forever.

Remember...
 The problem you’re trying to solve is how to avoid

spreading out the handling of a particular, changeable
task over several generations of classes.
 If you don’t avoid that, you’ll be editing a lot of files to
update your code.
 Creating an IFly interface and implemented by derived
classes wont solve the problem.

Separate what changes from what
stays the same...
 Separate the parts of your code that will change the

most from the rest of your application and try to make
them as freestanding as possible for easy maintenance.
 You should also always try to reuse those parts as much

as possible.
 Take what varies and encapsulate it so it wont affect

the rest of your code

Handling Change with “has-a”
Instead of “is-a”
 you can extract the volatile parts of your code and encapsulate

them as objects, you can use those objects as you need them —
and the entire task is handled by the code in such an object, it’s
not spread out over generations of classes. Doing so allows you to
customize your code by creating composites of objects.

 With composites, you select and use the objects you want,

instead of having a rigid hard-coded internal way of doing
things. That gives you a “has-a” relationship with those objects
— a bus “has-a” certain way of moving, which is encapsulated in
an object;

 A jet“has-a” different way of moving, which is also encapsulated

in an object. And each object performs a task.

Handling Change with “has-a”
Instead of “is-a”
 One object, one task often makes sense instead of writing multi-

generation code where one task is spread out over a dozen
generations.

 In other words, you’re reorganizing around the tasks, not around

the generations of classes that inheritance gives you.

 Using inheritance automatically sets things up in terms of strict,

inclusive “is-a” relationships, which is more likely to cause
maintenance and extensibility issues down the line.

 If you want to plan for change, it usually helps to think as much

as you can in terms of “has-a” relationships, where your code has
a number of objects whose code can be more easily updated as
change happens.

TIP
 When planning for change, consider “has-a” instead of

“is-a” relationships, and put volatile code in the objects
your application contains, rather than inheriting that
code.

Creating your Algorithm
 In design pattern terms, each implementation of the

go
 method is called an algorithm (basically that’s just
another name for a strategy).
 So you want to create a set of algorithms that can be
used by your various Car, Helicopter, and Jet objects.
Doing so separates the volatile code into algorithms.
Each algorithm handles one complete task, so you
don’t have to spread out the handling of that task over
generations of classes.

Program to an interface, not to an
implementation
 Change the behavior at runtime
 Use an Interface to represent behavior
 The behavior class will implement the behavior

interface

Program to an interface, not to an
implementation
 The point is to exploit polymorphism by programming

to a supertype so that the actual runtime object isn’t
locked into the code.
 The declared type of variables should be a supertype,
ususally an astract class or interface
 The objects assigned to those variables can be of any
concrete implementation of the supertype which
means the class declaring tem doesn’t have to know
about the actual object types

Program to an interface, not to an
implementation
 // programming to an implementation

Car car = new Car();
car.Go();
 // programming to an interface

Vehicle vehicle = new Bus();
vehicle.Go();

Assign a concrete implementation
at runtime...
Vehicle myVehicle = getVehicle();
myVehicle.Go();
We dont know WHAT the is the actual vehicle... All we
care is that it knows how to respond to a Go() method.

Codes... Creating the Algorithm
 To make sure that all the algorithms implement the

same methods (that’s just the go method), you need to
create an interface

public interface GoAlgorithm
{
public void Go();
}

Create the behavior classes and
implement the behavior
class GoByDriving : GoAlgorithm
{
#region GoAlgorithm Members
public void Go()
{
MessageBox.Show("Now I am driving!");
}
#endregion
}

Create the behavior classes and
implement the behavior
class GoByFlying:GoAlgorithm
{
#region GoAlgorithm Members
public void Go()
{
MessageBox.Show("Now I am Flying!");
}
#endregion
}

Using Algorithm
 Now you’ve got a number of algorithms you can create

objects from in order to build your code using “has-a”,
not “is-a”, relationships.
 After you create an object from an algorithm, you’ve
got to store that object somewhere,
 So add a new method to the Vehicle base class,
setGoAlgorithm. That method stores the algorithm
you want to use in an internal, private variable,
goAlgorithm as shown in the following:

Store the object
public abstract class Vehicle
{
GoAlgorithm goAlgorithm;
public void setGoAlgorithm(GoAlgorithm goAlgorithm)
{
this.goAlgorithm = goAlgorithm;
}
public void Go()
{
this.goAlgorithm.Go();
}
}

public class Car : Vehicle
{
public Car()
{
this.setGoAlgorithm(new GoByDriving());
}
}

public class Jet: Vehicle
{
public Jet()
{
this.setGoAlgorithm(new GoByFlying());
}
}

//programming to an implementation
Car car = new Car();
car.Go();
Bus bus = new Bus();
bus.Go();
Airplane airplane = new Airplane();
airplane.Go();
Jet jet = new Jet();
jet.Go();

Suppose there’s a change in the
driving speed...
 You are in the NLEX and the minimum speed must be

100km per hour...
 What will you do?

 Just update the GoByDriving class...

class GoByDriving : GoAlgorithm
{
#region GoAlgorithm Members

public void Go()
{
MessageBox.Show("Now I am driving 100km per hour!");
}
#endregion
}

 Now all the code that uses this algorithm is updated

automatically;
 no need to go searching through a lot of class files.
 In this way, when you concentrate how you handle a
task into a single algorithm object, you have a lot more
control over that task, especially when you want to
make changes to it.

Strategy Pattern
 This design principle comes into play when it makes

sense to extract code that handles specific tasks from
your app.
 Creating a family of algorithms lets you choose your
strategy by choosing consciously which algorithm(s)
you want to work with.
 This design pattern is often used as an alternative to
inheritance, where you can end up spreading out the
way you handle one specific task over many class files.

Strategy Pattern
Role
 The Strategy pattern involves removing an algorithm from
its host class and putting it in a separate class. There may
be different algorithms (strategies) that are applicable for a
given problem.
 If the algorithms are all kept in the host, messy code with
lots of conditional statements will result.
 The Strategy pattern enables a client to choose which
algorithm to use from a family of algorithms and gives it a
simple way to access it.
 The algorithms can also be expressed independently of the
data they are using.

Strategy Pattern

 Context- A class that maintains contextual

information for an IStrategy object’s algorithm to work
on
 Istrategy - Defines an interface common to all the
strategies
 StrategyA, StrategyB - Classes that include algorithms
that implement the IStrategy interface

Use Strategy when...
 Many related classes differ only in their behavior.
 There are different algorithms for a given purpose, and

the selection criteria can be codified.
 The algorithm uses data to which the client should

not have access.

Uses
 You have volatile code that you can separate out of

your application for easy maintenance.
 You want to avoid muddling how you handle a task by
having to split implementation code over several
inherited classes.
 You want to change the algorithm you use for a task at
runtime.

Remember...
 The GoF book says the Strategy design pattern should:

“Define a family of algorithms, encapsulate each one,
and make them interchangeable. Strategy lets the
algorithm vary independently from clients that use it.”

Design Principles
 Encapsulate what varies
 Favor Composition over Inheritance
 Program to Interface, not Implementations

class Program
{
static void Main(string[] args)
{
Console.WriteLine("Select Pizza:");
Console.WriteLine("1 - Meat Lovers: 500");

Console.WriteLine("2 - New York's Finest: 600\n");
int selectedPizza = Convert.ToInt32(Console.ReadLine());

Pizza pizza = (selectedPizza == 1) ? (Pizza) new MeatLovers() : new NewYorkFinest();
do
{
Console.WriteLine("\nSelect additional topping/s\n");
Console.WriteLine("3 - Extra veggies: 80\n");
Console.WriteLine("1 - Extra meat: 200");
Console.WriteLine("2 - Extra cheese: 100");



int selectedTopping = Convert.ToInt32(Console.ReadLine());
switch (selectedTopping)
{
case 1:
pizza = new MeatToppings(pizza);
break;
case 2:
pizza = new CheeseToppings(pizza);
break;
case 3:
pizza = new VeggieToppings(pizza);
break;
default:
break;
}
Console.WriteLine("\nAdd more toppings? Y/N");
} while (Console.ReadLine().ToUpper() == "Y");
Console.WriteLine("\nOrdered pizza complete\n");
Console.WriteLine(pizza.Description);
Console.WriteLine("\nTotal cost of pizza is: {0}\n",
pizza.Cost.ToString("F"));
Console.ReadLine();
}
}



public abstract class Newspaper
{
List<NewspaperReader> npObservers;
string propertyName = null;
public string GetChangedPropertyName()
{
return this.propertyName;
}
public void AddObserver(NewspaperReader npObserver)
{
if (npObservers == null)
npObservers = new List<NewspaperReader>();

this.npObservers.Add(npObserver);
npObserver.SetSubscription(this);

}
public void RemoveObserver(NewspaperReader npObserver)
{
if (npObservers == null)
return;
if (this.npObservers.Contains(npObserver))
{
this.npObservers.Remove(npObserver);
npObserver.RemoveSubscription(this);
}

}
public void SetNewspaperUpdate<T>(string propertyName, T value)
{
this.GetType().GetProperty(this.propertyName = propertyName).
SetValue(this, value, null);

}

this.NotifyObservers();
}
void NotifyObservers()
{
foreach (var npObserver in this.npObservers)
{
npObserver.DeliverNewspaperUpdates(this);
}
}


Related documents


devry cis 115 week 5 exercise
ryan hart resume
document1
resume mochen
javasyllabus
26i17 ijaet1117400 v6 iss5 2187 2195


Related keywords