Download ppt - Factory Patterns

Factory Patterns

RHS – SOC 2

Being less concrete

• One important OO principle is: ”Program to an interface, not an implementation”

• Interfaces reduces the coupling between code and concrete types

• Code does not need to know the concrete type of an object

RHS – SOC 3

Being less concrete

Animalsleep()makeSound()lookForFood()

Dogsleep()makeSound()lookForFood()

Horsesleep()makeSound()lookForFood()

RHS – SOC 4

Being less concrete

Animal oneAnimal = new Horse();

…

oneAnimal.sleep();

oneAnimal.makeSound();

oneAnimal.lookForFood():

…

RHS – SOC 5

Being less concrete

Animal oneAnimal = new Dog();

…

oneAnimal.sleep();



…

RHS – SOC 6

Being less concrete

• This is fine, but we still need to be concrete when creating an object

• Also, we might need to choose – at run-time – between various concrete types

RHS – SOC 7

Being less concrete

Animal oneAnimal;

…

if (needToRide)

oneAnimal = new Horse();

else if (mustBeMammal)

oneAnimal = new Dog();

else

oneAnimal = new Parrot();

…

oneAnimal.sleep();



…

RHS – SOC 8

Being less concrete

• Is anything wrong with this…?

• What if we need to add some new concrete types?

• In that case, we will need to change the code in order to include the new types

• ”Closed for modification, open for extension…”

RHS – SOC 9

Being less concrete

• We want to isolate the references to concrete types to another class

• One class produces concrete objects, using their concrete types

• Another class processes the objects, knowing only the interface

• The processing class can then be closed for modification

RHS – SOC 10

Being less concrete

• A class which produces objects is usually called a Factory Class

• A factory class usually has a single method: create(…)

• The create method often – but not always – takes a parameter, defining what concrete object to create

RHS – SOC 11

Being less concrete

Animalsleep()makeSound()lookForFood()

Dogsleep()makeSound()lookForFood()

Horsesleep()makeSound()lookForFood()

AnimalFactoryAnimal create(String info)

RHS – SOC 12

Being less concretepublic class AnimalFactory

{

public Animal create(String info)

{

if (info.equals(”Dog”))

return new Dog();

else if (info.equals(”Horse”))

return new Horse();

else if (info.equals(”Parrot”))

return new Parrot();

else

return null;

}

}

RHS – SOC 13

Being less concrete

AnimalFactory fac;

…

Animal oneAnimal = fac.create(”Dog”);

…

oneAnimal.sleep();



…

RHS – SOC 14

Being less concrete

• Have I achieved something, or am I just moving code around…?

• With this setup, we can now parameterise the processing code further

• This removes the last references to concrete types

RHS – SOC 15

Being less concrete

public void processAnAnimal(String type)

{

AnimalFactory fac = new AnimalFactory();

…

Animal oneAnimal = fac.create(type);

…

oneAnimal.sleep();



…

}

Type specifi-cation is a parameter

RHS – SOC 16

Being less concrete

public void processAnAnimal

(String type, AnimalFactory fac)

{


…

oneAnimal.sleep();



…

}

Type specifi-cation and object factory are parameters

RHS – SOC 17

Being less concrete

• This pattern is known as Simple Factory

• We have separated code for producing objects, and code for processing objects

• Processing code only knows about the interface

• Fewer responsibilities per class – ”Classes should only have one reason to change”

RHS – SOC 18

Exercises

• Download the NetBeans project FactoryExample from the Website (go to Classes, Week 43)

• Examine the code; we have defined a Pizza interface, and three concrete pizza classes SevenSeasPizza, TorinoPizza and Vegetarian pizza

• We have also defined a base class for a PizzaStore, and two concrete pizza stores, PizzaStoreA and PizzaStoreB

• Examine the difference between PizzaStoreA and PizzaStoreB. The first one creates pizza objects directly in the code, while the second one uses a simple factory (SimplePizzaFactory)

• Try to add a new pizza type RomaPizza (remember it must implement the Pizza interface), and update the pizza factory.

• Do you need to change the code in PizzaStoreA as well?

• Do you need to change the code in PizzaStoreB as well?

RHS – SOC 19

Abstraction to the next level

• The processing code needs a parameter which carries the type information for the object being created

• However, we also suggested that the factory itself could be a parameter

• Why would we do that….?

RHS – SOC 20


public void processAnAnimal

(String type, AnimalFactory fac)

{


…

oneAnimal.sleep();



…

}

Type specifi-cation and object factory are parameters

RHS – SOC 21


• Consider a word processor:– A document is composed of various

typographic objects, like Heading, Emphasis, and so on

– All such classes implement the interface Typo– Given some input source, a piece of code

must produce a list of Typo objects

RHS – SOC 22


// Part of input processing code

TypoFactory theTypoFactory;

public void createDocument(DocInput in)

{

ArrayList<Typo> doc = new ArrayList<Typo>();

while (in.hasNext())

{

TypoInput tyIn = in.next();

Typo typ = makeTypo(tyIn);

doc.add(typ);

}

}

RHS – SOC 23



private Typo makeTypo(TypoInput in)

{

String text = in.getText();

String type = in.getType();

Typo theTypo = theTypoFactory.create(type);

thetypo.addText(text);

return theTypo;

}

RHS – SOC 24


// TypoFactory code

private Typo create(String type)

{

if (type.equals(”Heading”))

return new Heading();

else if (type.equals(”Emphasis”))

return new Emphasis();

...

else

return null;

}

RHS – SOC 25


• The code processing the input does not know about concrete Typo classes – good

• But the code is still ”constrained”…

• What is a Typo object really – it is a ”binding” between a text and a certain way of formatting the text

• Different concrete Typo classes provide different bindings

RHS – SOC 26


• A Heading might be– Font size 24– Bold– Calibri font

• An Emphasis might be– Bold– Red font color

RHS – SOC 27


• A Typo factory thus defines a set of bindings between text and formatting – a layout

• What if we wish to change the layout of a document?

• We could then just define a different Typo factory, with different bindings

RHS – SOC 28



TypoFactoryFormalLayout theTypoFactory;


{

ArrayList<Typo> doc = new ArrayList<Typo>();

while (in.hasNext())

{

TypoInput tyIn = in.next();

Typo typ = makeTypo(tyIn);

doc.add(typ);

}

}

Just change the type of the Typo factory…

RHS – SOC 29


• This solution is still quite static

• Changing to a different factory requires code modification

• Why not use interfaces once again!

• We could also define an interface for the factory side, making the processing code independent of a specific factory

RHS – SOC 30


TypoaddText()

TypoFactoryTypo create(…)

RHS – SOC 31


TypoTypoFactory

TypoFactory-FormalLayout

TypoFactory-SmartLayout

RHS – SOC 32


TypoTypoFactory

TypoHeading-Formal

TypoEmphasis-Formal

TypoHeading-Smart

TypoEmphasis-Smart

RHS – SOC 33


TypoHeading-Formal

TypoEmphasis-Formal

TypoHeading-Smart

TypoEmphasis-Smart



RHS – SOC 34


• The factory for Formal layout only knows the concrete classes TypoHeading-Formal and TypoEmphasisFormal

• The factory for Smart layout only knows the concrete classes TypoHeadingSmart and TypoEmphasisSmart

• The factory interface only knows about the Typo interface

RHS – SOC 35


// A configurable document creator class

public class DocumentCreator

{

TypoFactory typoFac;

public DocumentCreator(TypoFactory typoFac)

{

this.typoFac = typoFac;

}

public void createDocument(DocInput in) {...}

}

RHS – SOC 36


public void createFormalDocument()

{

TypoFactory typoFac = new TypoFactoryFormalLayout();

DocumentCreator docCre = new DocumentCreator(typoFac);

docCre.createDocument(getDocInput());

}

RHS – SOC 37


• Note that the only thing that changes between two TypoFactory implementa-tions is the create method

• We may include concrete methods in the Typo interface – making it an abstract class – if it makes sense

• This is known as the Factory Mehtod pattern

RHS – SOC 38

The Factory method pattern

ProductFactorycreate()someMethod()

ConcreteFactorycreate()

ConcreteProduct

RHS – SOC 39

Exercises• Download the NetBeans project FactoryMethodExample from the Website

(go to Classes, Week 43)

• Examine the code; we have introduced two styles of pizza; LA-style (Los Angeles), and SF-style (San Francisco), so all pizzas now come in these two variants. Corresponding pizza classes have been created

• A PizzaFactory interface has also been included, with a single method createPizza. Two concrete pizza factories have been implemented, corresponding to the two pizza styles (PizzaFactoryLAStyle and PizzaFactoryLAStyle)

• A new pizza store PizzaStoreC has been implemented. This pizza store takes a PizzaFactory object as a parameter to its constructor

• A test of the new pizza store is found in Main. Try it out! See what happens if you change the parameter to the constructor

• If time permits, try to implement a third style for pizzas, including new pizza classes and a new pizza factory class

RHS – SOC 40

The Abstract Factory

• Our code can now work with different concrete factories, through a Factory interface

• What if we need to create several types of ”products”, not just a single type?– Typo – formattings of text– Graphic – formattings of graphic objects

RHS – SOC 41


• Answer seems simple: just use Factory Method pattern twice

TypoTypoFactory



GraphicGraphicFactory

GraphicFactory-FormalLayout

GraphicFactory-SmartLayout

RHS – SOC 42


• This looks fine…

• …but does it reflect our intention?

• Would it make sense to have a document, with – text using Formal layout– graphics using Smart layout

• Model does not include any ”binding” between related products

RHS – SOC 43



{

TypoFactory tFac = new TypoFactoryFormalLayout();

GraphicFactory gFac = new GraphicFactorySmartLayout();

DocumentCreator docCre = new DocumentCreator(tFac,gFac);


}

Oooppss!

RHS – SOC 44


• A Typo and a Graphic are not – as seen from a type point-of-view – related

• Would be somewhat artificial – or perhaps even impossible – to introduce a common base class

• However, we can enforce the binding through a shared factory class!

RHS – SOC 45


DocItemFactorycreateTypo()createGraphic()

FormalDocItemFactory SmartDocItemFactory

RHS – SOC 46



{

DocItemFactory fac = new FormalDocItemFactory ();

DocumentCreator docCre = new DocumentCreator(fac);


}

RHS – SOC 47



{

...

Typo aTypo = theFactory.createTypo(typoInfo);

...

Graphic aGraphic = theFactory.createGraphic(graphicInfo);

...

}

Using the same factory for creating Typo and Graphic objects!

RHS – SOC 48


• This pattern is known as the Abstract Factory pattern

• By making a creator class with several create… methods, we restrict the product combinations the client can create

RHS – SOC 49


• The methods in the Abstract Factory are product-type dependent, so if we add another product, we need to change the interface of the base class

• This is a price we must pay for binding (formally) non-related types together

• Patterns are also compromises…

RHS – SOC 50

Exercises• Download the NetBeans project AbstractFactoryExample from the Website (go to

Classes, Week 43)• Examine the code; we have now included a Beverage as well. We assume that a

pizza is always served with a beverage. In L.A., the beverage is always cola, and in S.F., the beverage is always coffee

• Classes representing beverages have been included in the code, along with two beverage factories.

• In the new pizza store PizzaStoreD, the store is now initialised with a pizza factory and a beverage factory. See the test in Main. However, there is a problem, since we can choose to use two factories representing different styles…

• In order to fix this problem, we introduce a MealFactory interface, with two methods createPizza and createBeverage. We have also included two concrete implementations of the interface, MealFactoryLAStyle and MealFactorySFStyle.

• Inspect the implementation of the concrete meal factories and PizzaStoreE, to see how the problem of mixing factories of different styles have been eliminated

• If time permits, experiment with adding a ”side order” to a meal, like french fries, pie, ice cream, or whatever you can imagine