Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-18T03:41:40Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implements the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which object they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The 'new' operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype.<ref name="javaprototype">http://java.dzone.com/articles/intro-design-patterns-prototype </ref>
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the [http://www.dotnetlead.com/design-patterns/prototype prototype design pattern] comes into picture and helps you avoid those expensive initializations.

We have a look at the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] for the prototype design pattern on the right:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern <ref name="codeprototype">http://www.codeproject.com/Articles/185348/Prototype-Design-Pattern </ref> ]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead <ref name="codeprototype"></ref>.

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:These example have been taken from <ref name="javaprototype"></ref>
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes <ref name="differences">http://community.topcoder.com/tc?module=Static&d1=tutorials&d2=prototypePattern </ref>.

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern], to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* [http://en.wikipedia.org/wiki/Abstract_factory_pattern The Abstract Factory], Prototype, or [http://en.wikipedia.org/wiki/Builder_pattern Builder patterns], which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory <ref name="msdn">http://msdn.microsoft.com/en-us/library/orm-9780596527730-01-05.aspx </ref>.
==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-18T03:37:11Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implements the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which object they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The 'new' operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype.<ref name="javaprototype">http://java.dzone.com/articles/intro-design-patterns-prototype </ref>
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the [http://www.dotnetlead.com/design-patterns/prototype prototype design pattern] comes into picture and helps you avoid those expensive initializations.

We have a look at the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] for the prototype design pattern on the right:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern <ref name="codeprototype">http://www.codeproject.com/Articles/185348/Prototype-Design-Pattern </ref> ]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead <ref name="codeprototype"></ref>.

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:These example have been taken from <ref name="javaprototype"></ref>
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes <ref name="differences">http://community.topcoder.com/tc?module=Static&d1=tutorials&d2=prototypePattern </ref>.

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern], to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* [http://en.wikipedia.org/wiki/Abstract_factory_pattern The Abstract Factory], Prototype, or [http://en.wikipedia.org/wiki/Builder_pattern Builder patterns], which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory <ref name="msdn">http://msdn.microsoft.com/en-us/library/orm-9780596527730-01-05.aspx </ref>.
==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-18T03:36:44Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implements the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which object they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype.<ref name="javaprototype">http://java.dzone.com/articles/intro-design-patterns-prototype </ref>
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the [http://www.dotnetlead.com/design-patterns/prototype prototype design pattern] comes into picture and helps you avoid those expensive initializations.

We have a look at the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] for the prototype design pattern on the right:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern <ref name="codeprototype">http://www.codeproject.com/Articles/185348/Prototype-Design-Pattern </ref> ]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead <ref name="codeprototype"></ref>.

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:These example have been taken from <ref name="javaprototype"></ref>
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes <ref name="differences">http://community.topcoder.com/tc?module=Static&d1=tutorials&d2=prototypePattern </ref>.

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern], to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* [http://en.wikipedia.org/wiki/Abstract_factory_pattern The Abstract Factory], Prototype, or [http://en.wikipedia.org/wiki/Builder_pattern Builder patterns], which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory <ref name="msdn">http://msdn.microsoft.com/en-us/library/orm-9780596527730-01-05.aspx </ref>.
==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-18T03:32:23Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implements the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype.<ref name="javaprototype">http://java.dzone.com/articles/intro-design-patterns-prototype </ref>
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the [http://www.dotnetlead.com/design-patterns/prototype prototype design pattern] comes into picture and helps you avoid those expensive initializations.

We have a look at the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] for the prototype design pattern on the right:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern <ref name="codeprototype">http://www.codeproject.com/Articles/185348/Prototype-Design-Pattern </ref> ]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead <ref name="codeprototype"></ref>.

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:These example have been taken from <ref name="javaprototype"></ref>
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes <ref name="differences">http://community.topcoder.com/tc?module=Static&d1=tutorials&d2=prototypePattern </ref>.

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern], to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* [http://en.wikipedia.org/wiki/Abstract_factory_pattern The Abstract Factory], Prototype, or [http://en.wikipedia.org/wiki/Builder_pattern Builder patterns], which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory <ref name="msdn">http://msdn.microsoft.com/en-us/library/orm-9780596527730-01-05.aspx </ref>.
==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:59:25Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the Composite pattern, to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:57:55Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the Composite pattern, to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:57:32Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the Composite pattern, to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:56:24Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the Composite pattern, to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:55:54Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the Composite pattern, to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:54:49Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the Composite pattern, to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:54:23Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the Composite pattern, to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:53:58Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

* prototypeList variable: It is the collection that stores all the prototypes
* AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number
* GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

*copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

*Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.
* Keep the number of classes in the system to a minimum.
* Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

* With the Composite pattern, to provide archiving.
* Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

* Flexibility is important.
* Objects can be extended in subclasses
* There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.
* A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

* The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:48:48Z

Vcorrei: /* Difference between factory method pattern and prototype pattern */

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

• prototypeList variable: It is the collection that stores all the prototypes

• AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number

• GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

• copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

• Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:
* Hide concrete classes from the client.
* Add and remove new classes (via prototypes) at runtime.

•

•

• Keep the number of classes in the system to a minimum.

• Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

• With the Composite pattern, to provide archiving.

• Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

• Flexibility is important.

• Objects can be extended in subclasses

• There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.

• A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

• The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:46:46Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming] concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of [http://en.wikipedia.org/wiki/Creational_pattern creational pattern]. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML diagram] on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

We have a look at the UML diagram for the prototype design pattern:

[[File:protypeuml.PNG|650 px|thumb|right|UML Diagram for prototype pattern]]

From the above diagram we can decipher the following things that are: PrototypeManager class is just a manager class that is used to add and retrieve prototypes by an index number; it has the following variable and methods:

• prototypeList variable: It is the collection that stores all the prototypes

• AddPrototype method: Allows you to add a prototype to the collection and assigning it an index number

• GetPrototype method: Allows you to retrieve a prototype from the collection using an index number

The IPrototype interface specifies the methods that all prototype classes must implement. It has the Clone method that returns an IPrototype interface.

The ConcretePrototype class is the actual prototype class; it implements the IPrototype interface and has the following property and method:

• copyProperty variable holds the information that is prepopulated. If the variable value is changed then the new instances created will have the new value.

• Clone method will make a copy of itself and return it. If the copyProperty is a value type (such as int or string) then we can use shallow copy. If the copyProperty is a reference type (such as an object that contains other objects) then we go for deep copy of the variable.

The key to this pattern is that you will create your first object with the expensive initializations, and then store the values as a prototype in the repository. When you need create the same object again you can just get the copy of the prototype from the repository with all the values already populated. This reduces the performance overhead [12].

===Java Sample code to show prototype design pattern===
The following is an example of the Prototype Pattern. The prototype object is an Animal object. The Animal prototype contains two concrete prototype subclasses namely Sheep and Chicken. TheAnimalCreator class contains references to the two concrete prototypes. During the initialization of theAnimalCreator class the two concrete prototypes, Sheep and Chicken are created and stored as the two concrete prototypes members of the AnimalCreator class. The AnimalCreator class contains a retrieveAnimal method that clones a prototype Animal depending on the parameter that is passed to it.

'''Animal.java'''

The Animal class is the abstract prototype of the two concrete prototypes in the example. The client invokes methods on the two different concrete prototypes through the Animal type to ensure the client does not know the type of the concrete prototypes.
Most importantly, the Animal prototype defines a clone method to assist the two subtypes or concrete prototypes to clone themselves.

Code:
public Animal clone() {
Animal clonedAnimal = null;
try {
clonedAnimal = (Animal) super.clone();
clonedAnimal.setDescription(description);
clonedAnimal.setNumberOfLegs(numberOfLegs);
clonedAnimal.setName(name);
} catch (CloneNotSupportedException e) {
e.printStackTrace();
} // catch
return clonedAnimal;
} // method clone

'''Sheep.java'''

The Sheep object is a concrete prototype that extends the Animal prototype. The Sheep prototype has a clone method to clone itself to create a new object.

Code:

public class Sheep extends Animal {

'''Chicken.java'''

The Chicken object is a concrete prototype that extends the Animal prototype. The Chicken prototype has a clone method to clone itself to create a new object.

Code:

public class Chicken extends Animal {

'''AnimalCreator.java'''

The AnimalCreator class is used to create and manage prototype objects. The AnimalCreator class contains two concrete prototypes that are initialized during the initialization of the class. The AnimalCreator class forms part of the "Prototype" pattern by returning a cloned object (Animal) to the client without the client knowing the type of the prototype.

Code:

public Animal retrieveAnimal(String kindOfAnimal) {
if ("Chicken".equals(kindOfAnimal)) {
return (Animal) chicken.clone();
} else if ("Sheep".equals(kindOfAnimal)) {
return (Animal) sheep.clone();
} // if
return null;
} // method retrieveAnimal

'''AnimalClient.java'''

The AnimalClient class makes use of the AnimalCreator class to create a concrete prototypes of typeAnimal. The AnimalClient class does not know the type of the concrete prototypes but references them through the Animal prototype.

Code:

AnimalCreator animalCreator = new AnimalCreator();
Animal[] animalFarm = new Animal[8];
animalFarm[0] = animalCreator.retrieveAnimal("Chicken");
animalFarm[1] = animalCreator.retrieveAnimal("Chicken");
animalFarm[2] = animalCreator.retrieveAnimal("Chicken");
animalFarm[3] = animalCreator.retrieveAnimal("Chicken");
animalFarm[4] = animalCreator.retrieveAnimal("Sheep");
animalFarm[5] = animalCreator.retrieveAnimal("Sheep");
animalFarm[6] = animalCreator.retrieveAnimal("Sheep");
animalFarm[7] = animalCreator.retrieveAnimal("Sheep");
for (int i= 0; i<=7; i++) {
System.out.println(animalFarm[i].helloAnimal());
} // for [13]

===Difference between factory method pattern and prototype pattern===

The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are creational patterns that will create objects of some interface without needing to specifically know the underlying class types.

The main difference between the two patterns however involves how objects are constructed. The factory pattern will, generally, construct an object using the same construction parameters each time. Each object will be initialized with the same state information and be roughly equivalent to each other. The prototype pattern, on the other hand, can use any clone able object that is given to it — even if those objects are of the same class type but with different state information assigned to them. Each object then becomes the prototype or template for any objects cloned from them. An example can demonstrate this:

public void factoryDoSomething(Factory factory) {
Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {
Point pt = (Point) prototype.clone();
... do something with the point ...
}

You will notice that in the factoryDoSomething method, the point that is created is initialized in the same way and cannot be customized1. The prototypeDoSomething method can create a point from any other point with any type of state assigned to it. We could have called it with a "new Point(23,85)" or a "new Point(2929,59483)" and the cloned object would have similar state to those prototypes. The, ahem, point of the matter is that we can customize the state of the objects that will be created by the prototype pattern.

Another major difference between the two patterns is the type of classes that can be created. A factory pattern will know (either through a registry or through sub classing) the various class types that can be created. The prototype pattern is not restricted to this as long as the object can be cloned. This allows the cloning of objects that are loaded dynamically from a class loader or ddl library or some other source where the class of the object is unknown either to the application or the component itself.

Lastly, a factory pattern can handle a limited set of class types efficiently but gets bogged down as the number of types increase. The more types a factory pattern can create, the more cumbersome the factory pattern becomes from the overhead of managing those classes (both in the factory itself and in creating the necessary supporting classes). If the classes that are managed by the factory pattern are a hierarchy of classes for any given implementation, that hierarchy is generally repeated for each type regardless of how similar each class is to any other implementation. If the factory pattern uses a registry of some sort, the registry becomes harder to manage and certainly consumes more resources. On the other hand, the prototype pattern does not suffer from these issues since the pattern is focused on an existing object. The pattern is very scalable as the types increase because it has no management or overhead associated to it. If a class hierarchy is involved for each implementation, the pattern becomes very efficient because it can reduce the number of redundant classes involved since any class can be simply cloned (in other words, you can mix and match classes from different types where applicable).

To sum up, a prototype pattern provides benefits over a factory pattern when the state of the objects should can be customized by the calling application, the class types are dynamically loaded or otherwise unknown or when there is a large number of class type implementations that potentially deal with a lot of similar classes [14].

'''Use the Prototype pattern when'''

You want to:

• Hide concrete classes from the client.

• Add and remove new classes (via prototypes) at runtime.

• Keep the number of classes in the system to a minimum.

• Adapt to changing structures of data at runtime.

'''Consider using this pattern:'''

• With the Composite pattern, to provide archiving.

• Instead of the Factory Method pattern, when subclasses start proliferating.

'''Use the Factory Method pattern when'''

• Flexibility is important.

• Objects can be extended in subclasses

• There is a specific reason why one subclass would be chosen over another-this logic forms part of the Factory Method.

• A client delegates responsibilities to subclasses in parallel hierarchies.

'''Consider using this pattern instead of:'''

• The Abstract Factory, Prototype, or Builder patterns, which are more flexible (though also more complex).The Prototype pattern to store a set of objects to clone from the abstract factory [15].

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:38:32Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:26:11Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from <ref name="userpagestemp" />

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:23:46Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern <ref name="ootemplate" /> ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:21:38Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern <ref name="userpagesfactory" />
]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:19:44Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create. <ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from <ref name="sourcemakingfact" />

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same.<ref name="ootemplate">http://www.oodesign.com/template-method-pattern.html </ref>Template method pattern is a behavioural design pattern.<ref name="wikitemplate">http://en.wikipedia.org/wiki/Template_method_pattern </ref> Template method pattern helps to avoid code duplication and aids in code reuse.<ref name="userpagestemp">http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf </ref>

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:11:57Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create<ref name="userpagesfactory" />

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from [4]

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same[8].Template method pattern is a behavioural design pattern[9]. Template method pattern helps to avoid code duplication and aids in code reuse[10]

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:09:47Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.<ref name="sourcemakingfact">http://sourcemaking.com/design_patterns/factory_method </ref>

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create[7]

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from [4]

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same[8].Template method pattern is a behavioural design pattern[9]. Template method pattern helps to avoid code duplication and aids in code reuse[10]

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:06:13Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="userpagesfactory">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.[4]

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create[7]

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from [4]

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same[8].Template method pattern is a behavioural design pattern[9]. Template method pattern helps to avoid code duplication and aids in code reuse[10]

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:05:44Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client.<ref name="web">http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf </ref>

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.[4]

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create[7]

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from [4]

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same[8].Template method pattern is a behavioural design pattern[9]. Template method pattern helps to avoid code duplication and aids in code reuse[10]

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:02:07Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client. [7]

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.[4]

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create[7]

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from [4]

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same[8].Template method pattern is a behavioural design pattern[9]. Template method pattern helps to avoid code duplication and aids in code reuse[10]

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

==References==

<references />

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T23:00:47Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.<ref name="web">http://www.oodesign.com/factory-pattern.html </ref>Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client. [7]

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.[4]

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create[7]

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from [4]

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same[8].Template method pattern is a behavioural design pattern[9]. Template method pattern helps to avoid code duplication and aids in code reuse[10]

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

===Prototype Design Pattern===
The Prototype pattern creates a new object by cloning an existing object. The client using the prototype object does not need to know what kind of object it deals with as long as the concrete prototype extends or implements the prototype interface or class. The concrete prototype object is responsible for cloning itself and hence returning the cloned object.
The pattern thus enables a client to create the kind of object required at runtime by selecting the appropriate prototype. The prototype classes are created generically by the client without the client knowing the exact type of the concrete prototype. New concrete prototypes can be added at run-time as long as they are similar to the abstract prototype [11].
This pattern allows you to avoid expensive initialization routines when you construct objects that are very similar. Also the goal is to minimize the amount of work needed in creating new objects when the initialization routines are expensive. For example, if the initialization routine requires database queries, file look ups, or service calls and you already have other objects in the system that are very similar to the object you are constructing, then the prototype pattern comes into picture and helps you avoid those expensive initializations.

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:55:45Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 

'''Factory Method'''

Factory method pattern is an Object Oriented Programming concept in which objects can be created without specifying the class to which they belong.Factory method pattern implement the concept of using an object to generate other objects.[1]Factory method is thus a type of creational pattern. An interface is defined for object creation. However the subclasses decide which class they want to instantiate. Factory methods thus abstract object instantiation from the client. [7]

The new operator is used in languages like Java to create an object. However in this case the object creation details are not encapsulated. Factory method allows a client to request for an object so that the object creation is encapsulated. Factory method uses inheritance for object creation. The superclass has ‘placeholders’ for the steps involved in object creation. The actual details of the object creation are specified in the subclass.[4]

Use of factory method pattern makes the code more flexible to change. In factory method pattern, interface is used to create an object and the actual instantiation of objects is deferred to subclasses that implement this interface. New classes can be added that implement this interface. In this way it becomes easy to add new concrete classes with minimal changes to the classes that use these objects.[head_first_design_pattern]. Factory method can be used when a class does not know the type of objects that it needs to create[7]

=== UML Diagram for Factory Method Pattern ===
[[File:Factoryuml.JPG|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, Product is the interface for the type of object created by the factory method. The Product interface is implemented by ConcreteProduct. The factory method which returns an object of type Product, is declared in Creator. The factory method is overridden inside ConcreteCreator to return an instance of ConcreteProduct.

=== Code Example ===
This example has been taken from [4]

public interface ImageReader {
public DecodedImage getDecodedImage();
}
public class GifReader implements ImageReader {
public GifReader( InputStream in ) {
// check that it's a gif, throw exception if it's not, then if it is decode it.
}
public DecodedImage getDecodedImage() {
return decodedImage;
}
}
public class JpegReader implements ImageReader {
//...
}
In the example above the ImageReader interface is defined. In this interface, a method getDecodedImage is defined that should return a decoded image. However this image may have been encoded in any format for example GIFF or JPEG. Therefore the functionality of actually decoding the image is implemented inside two classes GifReader and JpegReader . In this way, the responsibility of creating objects decoded in the appropriate format has been delegated to the subclass implementing the interface.

=== Template Pattern ===
Template method pattern is used to specify the format of an algorithm. The basic skeleton of an algorithm is defined in the base class using abstract operations. Subclasses override these abstract operations in order to provide concrete behaviour. In this way, two different subclasses may have different implementations of the abstract functions, but the overall structure of the algorithm will remain same[8].Template method pattern is a behavioural design pattern[9]. Template method pattern helps to avoid code duplication and aids in code reuse[10]

=== UML Diagram for Template Method Pattern ===
[[File:Template_method_implementation_-_uml_class_diagram.gif|650 px|thumb|right|UML Diagram for factory method pattern ]]
In the UML diagram on the right, abstract primitive operations are defined for which the subclasses provide the implementation. Template method is implemented which specifies the structure of the algorithm. The primitive operations are called within this template method. The ConcreteClass provides subclass specific implementation for the primitive operations.

=== Code Example ===
This example has been taken from [10]

public abstract class TextDocument {
public final void printPage () {
Document document = createDocument();
document.printTextHeader();
System.out.println(document.body());
document.printTextFooter();
}
public abstract Document createDocument();
public abstract void printTextHeader();
public abstract void printTextFooter();
...
}

public class PlainTextDocumentBuilder extends TextDocument {
public PlainTextDocumentBuilder(InputStream in){
//check that it is an Plain text document or throw error
}
public Document createDocument()
{
return new PlainTextDocument();
}
public void printTextHeader () {
// Code for header plain text header here.
}
public void printTextFooter () {
// Code for header plain text footer here.
}
...
}

public class HtmlTextDocumentBuilder extends TextDocument {
public HtmlTextDocumentBuilder(InputStream in){
//check that it is an HTML text document or throw error
}
public Document createDocument()
{
return new HtmlTextDocument();
}
public void printTextHeader () {
// Code for header HTML text header here.
}
public void printTextFooter () {
// Code for header HTML text footer here.
}
...
}

In the above example, two types of text documents are processed, plain text Document and HTML text document. To print any of the document, the procedure to print the document body is the same. However the methods to print the header and the footer are different for both the documents. Therefore they are defined in the abstract class but the specialized implementation is provided in the subclass. printPage() is the template method. Two types of objects are used, PlainTextDocument and HtmlTextDocument. A Factory method createDocument() is called within the Template method printPage() for this purpose.

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:54:57Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:53:31Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:51:56Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:51:22Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:48:50Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:39:53Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:38:44Z

Vcorrei:

File:Template method implementation - uml class diagram.gif

2012-11-16T22:37:43Z

Vcorrei: UML diagram for Template Method Pattern

UML diagram for Template Method Pattern

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:34:54Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:33:21Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:32:16Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:26:17Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:25:14Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:24:26Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:23:17Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:21:30Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:21:02Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:20:45Z

Vcorrei:

File:Factoryuml.JPG

2012-11-16T22:18:12Z

Vcorrei: This is a UML diagram of Factory pattern

This is a UML diagram of Factory pattern

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:14:39Z

Vcorrei:

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T22:01:56Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big> 
'''Factory Method'''

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T21:59:56Z

Vcorrei:

<big>''' Factory Method pattern and the related patterns (Template, Prototype)'''</big>

CSC/ECE 517 Fall 2012/ch2b 2w36 av

2012-11-16T21:56:30Z

Vcorrei: Created page with "hjhfukhfhu"

hjhfukhfhu

CSC/ECE 517 Fall 2007/wiki3 4 aa

2012-11-16T21:49:55Z

Vcorrei:

'''Factory'''
----
''Take the Interface Segregation principle and catalog the information on it available on the Web. We didn't cover it in class, but you can look it up on the Web or in the ACM DL. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.''

==Interface Segregation Principle (ISP)==

The Interface Segregation Principle states that ''"Clients should not be forced to depend upon interfaces that they do not use"''.

==ISP in OO Design==

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. This relationship is illustrated below, where Fig.1 indicates OO Design without ISP and Fig.2 indicates OO Design with ISP. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible. ISP is about high cohesion in the interface level. It is often referred to as poor man's Single Responsibility Principle (SRP) because SRP deals with cohesion at the class level.

[[Image:isp.jpg|thumb|left|300x350px|Fig.1) Design without ISP]] [[Image:isp2.jpg|thumbnail|none|425x420px|Fig.2) Design with ISP]]

Without ISP, the OO Design may contain fat interfaces. "Fat" interfaces arise from classes whose member methods can be broken into two or more groups. Each group of methods in turn serves a different set of clients. The Interface Segregation Principle suggests that client should not know about the method groups as a single class. Instead, clients should know about abstract base classes, one for each method group, which have cohesive interfaces. Fat interfaces lead to inadvertent couplings between clients that ought otherwise to be isolated. By making use of the ADAPTER pattern, either through delegation (object form) or multiple inheritance (class form), fat interfaces can be segregated into abstract base classes that break the unwanted coupling between clients.

The ISP acknowledges that there are objects that require non-cohesive interfaces; however it suggests that clients should not know about them as a single class. Instead, clients should know about abstract base classes that have cohesive interfaces. Some languages
refer to these abstract base classes as “interfaces”, “protocols” or “signatures”.

==Examples of ISP==

===Example 1===

The following example is a very easy to understand example of how ISP can be employed in a real world system design.

Consider a cell phone had interfaces of a phone and a MP3 player. ISP advises to keep these two interfaces completely independent of each other. This way the phone can be treated purely as a phone or as a MP3 player. Programmatically,use only the interface of a MP3 player in an implemented method called playSong. In future even if the interface for the phone is modified, the method playSong would remain the same[3].

This example can be used to give a general overview of ISP, without going into much detail of how ISP is used in making complex OO design decision.

===Example 2===

The following example is best example that shows how ISP is used to deal with fat interfaces. In the illustrations below, UML (Unified Modeling Language) has been used to bring out the design decisions that have been made.

Consider a security system. In this system there are Door objects that can be locked and unlocked, and which know whether they are open or closed. The Door class is abstract so that clients can use objects that conform to the Door interface, without having to depend upon particular implementations of Door. Now consider that one such implementation. TimedDoor needs to sound an alarm when the door has been left open for too long. In order to do this the TimedDoor object communicates with another object called a Timer.

How can we get the TimerClient class to communicate with the TimedDoor class so that the code in the TimedDoor can be notified of the timeout? We force Door, and therefore TimedDoor, to inherit from TimerClient. This ensures that TimerClient can register itself with the Timer and receive the TimeOut message.

Although this solution is common, it is not without problems. Chief among these is that the Door class now depends upon TimerClient. Not all varieties of Door need timing. Indeed, the original Door abstraction had nothing whatever to do with timing. If timingfree derivatives of Door are created, those derivatives will have to provide nil implementations for the TimeOut method. Moreover, the applications that use those derivatives will have to include the definition of the TimerClient class, even though it is not used.

Figure 3 shows a common syndrome of object oriented design in statically typed languages like C++. This is the syndrome of interface pollution. The interface of Door has been polluted with an interface that it does not require. It has been forced to incorporate this interface solely for the benefit of one of its subclasses. If this practice is pursued, then every time a derivative needs a new interface, that interface will be added to the base class. This will further pollute the interface of the base class, making it “fat”

Moreover, each time a new interface is added to the base class, that interface must be implemented (or allowed to default) in derived classes. Indeed, an associated practice is to add these interfaces to the base class as
nil virtual functions rather than pure virtual functions; specifically so that derived classes are not burdened with the need to implement them. As we learned in class, such a practice violates the Liskov Substitution principle (LSP), leading to maintenance and reusability problems.

The solution to these problems are intriguing. The answer to this lies in the fact that clients of an object do not need to access it through the interface of the object. Rather, they can access it through delegation, or through a base class of the object.

Figure 4 show how Multiple Inheritance can be used, in the class form of the ADAPTER pattern, to achieve the ISP. In this model, TimedDoor inherits from both Door and TimerClient. Although clients of both base classes can make use of TimedDoor, neither actually depend upon the TimedDoor class. Thus, they use the same object through separate interfaces [2].

[[Image:isp3.jpg|thumb|left|300x350px|Fig.3) Timed Door Design without ISP]]
[[Image:isp4.jpg|thumb|none|460x420px|Fig.4) Timed Door Design with ISP]]

'''Out of all the four examples that are presented in this article we consider this the most suitable to be taught in class.
'''
===Example 3===

The following example deals with the design of UI for a client-sever architecture. Consider a system in which the user has a choice of three types of UIs, namely GUI (Graphical User Interface), Touchpad and a Console. There is a central server that has to satisfy the request from clients, collects the display interfaces and displays customized result back to the user (Server class). In a system without ISP, addition of a new type of UI, will require a changes in the server interface. Furthermore, it would also require all the other UIs to be recompiled. If proper ISP is applied in the OO Design, new UIs can be added without requiring changes to the server's interfaces. Also the other UIs are not affected. The Fig.5 illustrates this example.

The ISP are implemented by using an intermediary interfaces that interact with the server. These intermediary interfaces implement common functionality of each of the UIs, thus abstracting the actual implementation of the UIs from the server class. Hence new UIs can be added without requiring change to the server and other UIs[4].

[[Image:isp5.jpg|thumb|center|425x420px|Fig.5) UI Design ]]

===Example 4===

Consider a slightly more significant example. The traditional Automated Teller Machine (ATM) problem. The user interface of an ATM machine needs to be very flexible. The output may need to be translated into many different language. It may need to be presented on a screen, or on a braille tablet, or spoken out a speech synthesizer. Clearly this can be achieved by creating an abstract base class that has pure virtual functions for all the different messages that need to be presented by the interface. Fig.6 Represents a general UI design for the ATM.

[[Image:ATM_UI.jpg|thumb|center|400x400px|Fig.6) ATM UI Design ]]

Also consider that different transactions that the ATM can perform is encapsulated as a derivative of the class Transaction. Thus we might have classes such as DepositTransaction, WithdrawlTransaction, TransferTransaction, etc. Each of these objects issues message
to the UI. For example, the DepositTransaction object calls the RequestDepositAmount member function of the UI class. Whereas the transferTransaction object calls the RequestTransferAmount member function of UI. This corresponds to the diagram in Figure 7.

[[Image:ATM_TRN.jpg|thumb|center|400x400px|Fig.7) ATM TRANSACTION Design ]]

Notice that this is precisely the situation that the ISP tells us to avoid. Each of the transactions is using a portion of the UI that no other object uses. This creates the possibility that changes to one of the derivatives of Transaction will force corresponding change to the UI, thereby affecting all the other derivatives of Transaction, and every other class that depends upon the UI interface.

This unfortunate coupling can be avoided by segregating the UI interface into individual abstract base classes such as DepositUI, withdrawUI and TransferUI. These abstract base classes can then be multiply inherited into the final UI abstract class. Fig.8 show this model[5].

[[Image:segregation.jpg|thumb|center|400x400px|Fig.8) ATM SEGREGATION Design ]]

==Catalog / Reference==
1. [http://www.objectmentor.com/resources/articles/isp.pdf objectMentor] 
2. [http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html doodleproject] 
3. [http://ifacethoughts.net/2006/03/28/interface-segregation-principle/ ifacethoughts] 
4. [http://www.everything2.com/index.pl?node_id=1259576 everything_oo] 
5. [http://www.cmcrossroads.com/articles/agile-cm-environments/principles-of-agile-version-control:-from-ood-to-tbd.html cmc_oodesign] 
6. [http://jayflowers.com/WordPress/?p=91 jayflowers] 
7. [http://www.cet.sunderland.ac.uk/~cs0her/COM379%20Lectures/Lecture3.ppt sunderland_technologies] 
8. [http://www.parlezuml.com/metrics/OO%20Design%20Principles%20&%20Metrics.pdf uml] 
9. [http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html javaboutique] 
10.[http://www.ddj.com/blog/architectblog/archives/2006/06/interface_segre.html arch_of_oo] 
11.[http://hocit.com/forum/showthread.php?p=13932 OOforum]