https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=Kal+el 2026-10-04T12:03:53Z User contributions MediaWiki 1.41.0 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28826 2009-11-18T23:00:26Z

<p>Kal el: /* What is factory method? */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> In the Application class the CreateDocument method either has a default implementation or it doesn't have any implementation at all, this operation being redefined in the MyApplication subclass so that it creates a MyDocument object and returns a reference to it.<br /> <br /> &lt;code&gt;<br /> public Document CreateDocument(String type){<br /> if (type.isEqual(&quot;html&quot;))<br /> return new HtmlDocument();<br /> if (type.isEqual(&quot;proprietary&quot;))<br /> return new MyDocument();<br /> if (type.isEqual(&quot;pdf&quot;))<br /> return new PdfDocument ();<br /> }<br /> &lt;/code&gt;<br /> <br /> Assuming that the Application class has a member called docs that represents a list of documents being handled by the application, then the NewDocument method should look like this:<br /> <br /> public void NewDocument(String type){<br /> Document doc=CreateDocument(type);<br /> Docs.add(doc);<br /> Doc.Open();<br /> }<br /> <br /> This method will be inherited by the MyApplication class and, so, through the CreateDocument method, it will actually instantiate MyDocument objects. We will call the CreateDocument method a Factory Method because it is responsible with 'making' an object. Through this method, redefined in Application's subclasses, we can actually shape the situation in which the Application class creates objects without knowing their type. From this point of view the factory method is pattern which provides us a way to achieve the DIP principle.<br /> <br /> Specific problems and implementation<br /> <br /> When implementing the Factory Method design pattern some issues may appear:<br /> <br /> Definition of Creator class<br /> <br /> If we apply the pattern to an already written code there may be problems with the way we have the Creator class already defined. There are two cases:<br /> <br /> * Creator class is abstract and generating method does not have any implementation. In this case the ConcreteCreator classes must define their own generation method and this situation usually appears in the cases where the Creator class can't foresee what ConcreteProduct it will instantiate.<br /> * Creator class is a concrete class, the generating method having a default implementation. If this happens, the ConcreteCreator classes will use the generating method for flexibility rather than for generation. The programmer will always be able to modify the class of the objects that the Creator class implicitly creates, redefining the generation method.<br /> <br /> Factory method is just a particular case of the factory design pattern. In the same time it is the most known factory pattern, maybe because it was published in the GoF. In modern programming languages the factory with registration is more used.<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Examples of Factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ===Limitations of factory pattern===<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> The main reason for which the factory pattern is used is that it introduces a separation between the application and a family of classes (it introduces weak coupling instead of tight coupling hiding concrete classes from the application). It provides a simple way of extending the family of products with minor changes in application code.It provides customization hooks. When the objects are created directly inside the class it's hard to replace them by objects which extend their functionality. If a factory is used instead to create a family of objects the customized objects can easily replace the original objects, configuring the factory to create them.The factory has to be used for a family of objects. If the classes doesn't extend common base class or interface they can not be used in a factory design template.<br /> <br /> The factory method is one of the most used and one of the more robust design patterns. There are only few points which have to be considered when you implement a factory method.<br /> <br /> When you design an application just think if you really need it a factory to create objects. Maybe using it will bring unnecessary complexity in your application. Anyway if you have many object of the same base type and you manipulate them mostly as abstract objects, then you need a factory.<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28816 2009-11-18T22:54:10Z

<p>Kal el: /* Factory pattern implementation in programming languages */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> In the Application class the CreateDocument method either has a default implementation or it doesn't have any implementation at all, this operation being redefined in the MyApplication subclass so that it creates a MyDocument object and returns a reference to it.<br /> <br /> &lt;code&gt;<br /> public Document CreateDocument(String type){<br /> if (type.isEqual(&quot;html&quot;))<br /> return new HtmlDocument();<br /> if (type.isEqual(&quot;proprietary&quot;))<br /> return new MyDocument();<br /> if (type.isEqual(&quot;pdf&quot;))<br /> return new PdfDocument ();<br /> }<br /> &lt;/code&gt;<br /> <br /> Assuming that the Application class has a member called docs that represents a list of documents being handled by the application, then the NewDocument method should look like this:<br /> <br /> public void NewDocument(String type){<br /> Document doc=CreateDocument(type);<br /> Docs.add(doc);<br /> Doc.Open();<br /> }<br /> <br /> This method will be inherited by the MyApplication class and, so, through the CreateDocument method, it will actually instantiate MyDocument objects. We will call the CreateDocument method a Factory Method because it is responsible with 'making' an object. Through this method, redefined in Application's subclasses, we can actually shape the situation in which the Application class creates objects without knowing their type. From this point of view the factory method is pattern which provides us a way to achieve the DIP principle.<br /> <br /> Specific problems and implementation<br /> <br /> When implementing the Factory Method design pattern some issues may appear:<br /> <br /> Definition of Creator class<br /> <br /> If we apply the pattern to an already written code there may be problems with the way we have the Creator class already defined. There are two cases:<br /> <br /> * Creator class is abstract and generating method does not have any implementation. In this case the ConcreteCreator classes must define their own generation method and this situation usually appears in the cases where the Creator class can't foresee what ConcreteProduct it will instantiate.<br /> * Creator class is a concrete class, the generating method having a default implementation. If this happens, the ConcreteCreator classes will use the generating method for flexibility rather than for generation. The programmer will always be able to modify the class of the objects that the Creator class implicitly creates, redefining the generation method.<br /> <br /> Factory method is just a particular case of the factory design pattern. In the same time it is the most known factory pattern, maybe because it was published in the GoF. In modern programming languages the factory with registration is more used.<br /> <br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Examples of Factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ===Limitations of factory pattern===<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> The main reason for which the factory pattern is used is that it introduces a separation between the application and a family of classes (it introduces weak coupling instead of tight coupling hiding concrete classes from the application). It provides a simple way of extending the family of products with minor changes in application code.It provides customization hooks. When the objects are created directly inside the class it's hard to replace them by objects which extend their functionality. If a factory is used instead to create a family of objects the customized objects can easily replace the original objects, configuring the factory to create them.The factory has to be used for a family of objects. If the classes doesn't extend common base class or interface they can not be used in a factory design template.<br /> <br /> The factory method is one of the most used and one of the more robust design patterns. There are only few points which have to be considered when you implement a factory method.<br /> <br /> When you design an application just think if you really need it a factory to create objects. Maybe using it will bring unnecessary complexity in your application. Anyway if you have many object of the same base type and you manipulate them mostly as abstract objects, then you need a factory.<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28815 2009-11-18T22:53:38Z

<p>Kal el: /* More Examples of factory pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> In the Application class the CreateDocument method either has a default implementation or it doesn't have any implementation at all, this operation being redefined in the MyApplication subclass so that it creates a MyDocument object and returns a reference to it.<br /> <br /> &lt;code&gt;<br /> public Document CreateDocument(String type){<br /> if (type.isEqual(&quot;html&quot;))<br /> return new HtmlDocument();<br /> if (type.isEqual(&quot;proprietary&quot;))<br /> return new MyDocument();<br /> if (type.isEqual(&quot;pdf&quot;))<br /> return new PdfDocument ();<br /> }<br /> &lt;/code&gt;<br /> <br /> Assuming that the Application class has a member called docs that represents a list of documents being handled by the application, then the NewDocument method should look like this:<br /> <br /> public void NewDocument(String type){<br /> Document doc=CreateDocument(type);<br /> Docs.add(doc);<br /> Doc.Open();<br /> }<br /> <br /> This method will be inherited by the MyApplication class and, so, through the CreateDocument method, it will actually instantiate MyDocument objects. We will call the CreateDocument method a Factory Method because it is responsible with 'making' an object. Through this method, redefined in Application's subclasses, we can actually shape the situation in which the Application class creates objects without knowing their type. From this point of view the factory method is pattern which provides us a way to achieve the DIP principle.<br /> <br /> Specific problems and implementation<br /> <br /> When implementing the Factory Method design pattern some issues may appear:<br /> <br /> Definition of Creator class<br /> <br /> If we apply the pattern to an already written code there may be problems with the way we have the Creator class already defined. There are two cases:<br /> <br /> * Creator class is abstract and generating method does not have any implementation. In this case the ConcreteCreator classes must define their own generation method and this situation usually appears in the cases where the Creator class can't foresee what ConcreteProduct it will instantiate.<br /> * Creator class is a concrete class, the generating method having a default implementation. If this happens, the ConcreteCreator classes will use the generating method for flexibility rather than for generation. The programmer will always be able to modify the class of the objects that the Creator class implicitly creates, redefining the generation method.<br /> <br /> Factory method is just a particular case of the factory design pattern. In the same time it is the most known factory pattern, maybe because it was published in the GoF. In modern programming languages the factory with registration is more used.<br /> <br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Factory pattern implementation in programming languages===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ===Limitations of factory pattern===<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> The main reason for which the factory pattern is used is that it introduces a separation between the application and a family of classes (it introduces weak coupling instead of tight coupling hiding concrete classes from the application). It provides a simple way of extending the family of products with minor changes in application code.It provides customization hooks. When the objects are created directly inside the class it's hard to replace them by objects which extend their functionality. If a factory is used instead to create a family of objects the customized objects can easily replace the original objects, configuring the factory to create them.The factory has to be used for a family of objects. If the classes doesn't extend common base class or interface they can not be used in a factory design template.<br /> <br /> The factory method is one of the most used and one of the more robust design patterns. There are only few points which have to be considered when you implement a factory method.<br /> <br /> When you design an application just think if you really need it a factory to create objects. Maybe using it will bring unnecessary complexity in your application. Anyway if you have many object of the same base type and you manipulate them mostly as abstract objects, then you need a factory.<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28814 2009-11-18T22:52:26Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> In the Application class the CreateDocument method either has a default implementation or it doesn't have any implementation at all, this operation being redefined in the MyApplication subclass so that it creates a MyDocument object and returns a reference to it.<br /> <br /> &lt;code&gt;<br /> public Document CreateDocument(String type){<br /> if (type.isEqual(&quot;html&quot;))<br /> return new HtmlDocument();<br /> if (type.isEqual(&quot;proprietary&quot;))<br /> return new MyDocument();<br /> if (type.isEqual(&quot;pdf&quot;))<br /> return new PdfDocument ();<br /> }<br /> &lt;/code&gt;<br /> <br /> Assuming that the Application class has a member called docs that represents a list of documents being handled by the application, then the NewDocument method should look like this:<br /> <br /> public void NewDocument(String type){<br /> Document doc=CreateDocument(type);<br /> Docs.add(doc);<br /> Doc.Open();<br /> }<br /> <br /> This method will be inherited by the MyApplication class and, so, through the CreateDocument method, it will actually instantiate MyDocument objects. We will call the CreateDocument method a Factory Method because it is responsible with 'making' an object. Through this method, redefined in Application's subclasses, we can actually shape the situation in which the Application class creates objects without knowing their type. From this point of view the factory method is pattern which provides us a way to achieve the DIP principle.<br /> <br /> Specific problems and implementation<br /> <br /> When implementing the Factory Method design pattern some issues may appear:<br /> <br /> Definition of Creator class<br /> <br /> If we apply the pattern to an already written code there may be problems with the way we have the Creator class already defined. There are two cases:<br /> <br /> * Creator class is abstract and generating method does not have any implementation. In this case the ConcreteCreator classes must define their own generation method and this situation usually appears in the cases where the Creator class can't foresee what ConcreteProduct it will instantiate.<br /> * Creator class is a concrete class, the generating method having a default implementation. If this happens, the ConcreteCreator classes will use the generating method for flexibility rather than for generation. The programmer will always be able to modify the class of the objects that the Creator class implicitly creates, redefining the generation method.<br /> <br /> Factory method is just a particular case of the factory design pattern. In the same time it is the most known factory pattern, maybe because it was published in the GoF. In modern programming languages the factory with registration is more used.<br /> <br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ===Limitations of factory pattern===<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> The main reason for which the factory pattern is used is that it introduces a separation between the application and a family of classes (it introduces weak coupling instead of tight coupling hiding concrete classes from the application). It provides a simple way of extending the family of products with minor changes in application code.It provides customization hooks. When the objects are created directly inside the class it's hard to replace them by objects which extend their functionality. If a factory is used instead to create a family of objects the customized objects can easily replace the original objects, configuring the factory to create them.The factory has to be used for a family of objects. If the classes doesn't extend common base class or interface they can not be used in a factory design template.<br /> <br /> The factory method is one of the most used and one of the more robust design patterns. There are only few points which have to be considered when you implement a factory method.<br /> <br /> When you design an application just think if you really need it a factory to create objects. Maybe using it will bring unnecessary complexity in your application. Anyway if you have many object of the same base type and you manipulate them mostly as abstract objects, then you need a factory.<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28813 2009-11-18T22:49:56Z

<p>Kal el: /* Limitations */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> In the Application class the CreateDocument method either has a default implementation or it doesn't have any implementation at all, this operation being redefined in the MyApplication subclass so that it creates a MyDocument object and returns a reference to it.<br /> <br /> &lt;code&gt;<br /> public Document CreateDocument(String type){<br /> if (type.isEqual(&quot;html&quot;))<br /> return new HtmlDocument();<br /> if (type.isEqual(&quot;proprietary&quot;))<br /> return new MyDocument();<br /> if (type.isEqual(&quot;pdf&quot;))<br /> return new PdfDocument ();<br /> }<br /> &lt;/code&gt;<br /> <br /> Assuming that the Application class has a member called docs that represents a list of documents being handled by the application, then the NewDocument method should look like this:<br /> <br /> public void NewDocument(String type){<br /> Document doc=CreateDocument(type);<br /> Docs.add(doc);<br /> Doc.Open();<br /> }<br /> <br /> This method will be inherited by the MyApplication class and, so, through the CreateDocument method, it will actually instantiate MyDocument objects. We will call the CreateDocument method a Factory Method because it is responsible with 'making' an object. Through this method, redefined in Application's subclasses, we can actually shape the situation in which the Application class creates objects without knowing their type. From this point of view the factory method is pattern which provides us a way to achieve the DIP principle.<br /> <br /> Specific problems and implementation<br /> <br /> When implementing the Factory Method design pattern some issues may appear:<br /> <br /> Definition of Creator class<br /> <br /> If we apply the pattern to an already written code there may be problems with the way we have the Creator class already defined. There are two cases:<br /> <br /> * Creator class is abstract and generating method does not have any implementation. In this case the ConcreteCreator classes must define their own generation method and this situation usually appears in the cases where the Creator class can't foresee what ConcreteProduct it will instantiate.<br /> * Creator class is a concrete class, the generating method having a default implementation. If this happens, the ConcreteCreator classes will use the generating method for flexibility rather than for generation. The programmer will always be able to modify the class of the objects that the Creator class implicitly creates, redefining the generation method.<br /> <br /> Factory method is just a particular case of the factory design pattern. In the same time it is the most known factory pattern, maybe because it was published in the GoF. In modern programming languages the factory with registration is more used.<br /> <br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations of factory pattern==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> The main reason for which the factory pattern is used is that it introduces a separation between the application and a family of classes (it introduces weak coupling instead of tight coupling hiding concrete classes from the application). It provides a simple way of extending the family of products with minor changes in application code.It provides customization hooks. When the objects are created directly inside the class it's hard to replace them by objects which extend their functionality. If a factory is used instead to create a family of objects the customized objects can easily replace the original objects, configuring the factory to create them.The factory has to be used for a family of objects. If the classes doesn't extend common base class or interface they can not be used in a factory design template.<br /> <br /> The factory method is one of the most used and one of the more robust design patterns. There are only few points which have to be considered when you implement a factory method.<br /> <br /> When you design an application just think if you really need it a factory to create objects. Maybe using it will bring unnecessary complexity in your application. Anyway if you have many object of the same base type and you manipulate them mostly as abstract objects, then you need a factory.<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28812 2009-11-18T22:48:28Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> In the Application class the CreateDocument method either has a default implementation or it doesn't have any implementation at all, this operation being redefined in the MyApplication subclass so that it creates a MyDocument object and returns a reference to it.<br /> <br /> &lt;code&gt;<br /> public Document CreateDocument(String type){<br /> if (type.isEqual(&quot;html&quot;))<br /> return new HtmlDocument();<br /> if (type.isEqual(&quot;proprietary&quot;))<br /> return new MyDocument();<br /> if (type.isEqual(&quot;pdf&quot;))<br /> return new PdfDocument ();<br /> }<br /> &lt;/code&gt;<br /> <br /> Assuming that the Application class has a member called docs that represents a list of documents being handled by the application, then the NewDocument method should look like this:<br /> <br /> public void NewDocument(String type){<br /> Document doc=CreateDocument(type);<br /> Docs.add(doc);<br /> Doc.Open();<br /> }<br /> <br /> This method will be inherited by the MyApplication class and, so, through the CreateDocument method, it will actually instantiate MyDocument objects. We will call the CreateDocument method a Factory Method because it is responsible with 'making' an object. Through this method, redefined in Application's subclasses, we can actually shape the situation in which the Application class creates objects without knowing their type. From this point of view the factory method is pattern which provides us a way to achieve the DIP principle.<br /> <br /> Specific problems and implementation<br /> <br /> When implementing the Factory Method design pattern some issues may appear:<br /> <br /> Definition of Creator class<br /> <br /> If we apply the pattern to an already written code there may be problems with the way we have the Creator class already defined. There are two cases:<br /> <br /> * Creator class is abstract and generating method does not have any implementation. In this case the ConcreteCreator classes must define their own generation method and this situation usually appears in the cases where the Creator class can't foresee what ConcreteProduct it will instantiate.<br /> * Creator class is a concrete class, the generating method having a default implementation. If this happens, the ConcreteCreator classes will use the generating method for flexibility rather than for generation. The programmer will always be able to modify the class of the objects that the Creator class implicitly creates, redefining the generation method.<br /> <br /> Factory method is just a particular case of the factory design pattern. In the same time it is the most known factory pattern, maybe because it was published in the GoF. In modern programming languages the factory with registration is more used.<br /> <br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> The main reason for which the factory pattern is used is that it introduces a separation between the application and a family of classes (it introduces weak coupling instead of tight coupling hiding concrete classes from the application). It provides a simple way of extending the family of products with minor changes in application code.It provides customization hooks. When the objects are created directly inside the class it's hard to replace them by objects which extend their functionality. If a factory is used instead to create a family of objects the customized objects can easily replace the original objects, configuring the factory to create them.The factory has to be used for a family of objects. If the classes doesn't extend common base class or interface they can not be used in a factory design template.<br /> <br /> The factory method is one of the most used and one of the more robust design patterns. There are only few points which have to be considered when you implement a factory method.<br /> <br /> When you design an application just think if you really need it a factory to create objects. Maybe using it will bring unnecessary complexity in your application. Anyway if you have many object of the same base type and you manipulate them mostly as abstract objects, then you need a factory.<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28811 2009-11-18T22:45:51Z

<p>Kal el: /* Factory Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> In the Application class the CreateDocument method either has a default implementation or it doesn't have any implementation at all, this operation being redefined in the MyApplication subclass so that it creates a MyDocument object and returns a reference to it.<br /> <br /> &lt;code&gt;<br /> public Document CreateDocument(String type){<br /> if (type.isEqual(&quot;html&quot;))<br /> return new HtmlDocument();<br /> if (type.isEqual(&quot;proprietary&quot;))<br /> return new MyDocument();<br /> if (type.isEqual(&quot;pdf&quot;))<br /> return new PdfDocument ();<br /> }<br /> &lt;/code&gt;<br /> <br /> Assuming that the Application class has a member called docs that represents a list of documents being handled by the application, then the NewDocument method should look like this:<br /> <br /> public void NewDocument(String type){<br /> Document doc=CreateDocument(type);<br /> Docs.add(doc);<br /> Doc.Open();<br /> }<br /> <br /> This method will be inherited by the MyApplication class and, so, through the CreateDocument method, it will actually instantiate MyDocument objects. We will call the CreateDocument method a Factory Method because it is responsible with 'making' an object. Through this method, redefined in Application's subclasses, we can actually shape the situation in which the Application class creates objects without knowing their type. From this point of view the factory method is pattern which provides us a way to achieve the DIP principle.<br /> <br /> Specific problems and implementation<br /> <br /> When implementing the Factory Method design pattern some issues may appear:<br /> <br /> Definition of Creator class<br /> <br /> If we apply the pattern to an already written code there may be problems with the way we have the Creator class already defined. There are two cases:<br /> <br /> * Creator class is abstract and generating method does not have any implementation. In this case the ConcreteCreator classes must define their own generation method and this situation usually appears in the cases where the Creator class can't foresee what ConcreteProduct it will instantiate.<br /> * Creator class is a concrete class, the generating method having a default implementation. If this happens, the ConcreteCreator classes will use the generating method for flexibility rather than for generation. The programmer will always be able to modify the class of the objects that the Creator class implicitly creates, redefining the generation method.<br /> <br /> Factory method is just a particular case of the factory design pattern. In the same time it is the most known factory pattern, maybe because it was published in the GoF. In modern programming languages the factory with registration is more used.<br /> <br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28805 2009-11-18T22:41:02Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> In the Application class the CreateDocument method either has a default implementation or it doesn't have any implementation at all, this operation being redefined in the MyApplication subclass so that it creates a MyDocument object and returns a reference to it.<br /> <br /> public Document CreateDocument(String type){<br /> if (type.isEqual(&quot;html&quot;))<br /> return new HtmlDocument();<br /> if (type.isEqual(&quot;proprietary&quot;))<br /> return new MyDocument();<br /> if (type.isEqual(&quot;pdf&quot;))<br /> return new PdfDocument ();<br /> }<br /> <br /> Assuming that the Application class has a member called docs that represents a list of documents being handled by the application, then the NewDocument method should look like this:<br /> <br /> public void NewDocument(String type){<br /> Document doc=CreateDocument(type);<br /> Docs.add(doc);<br /> Doc.Open();<br /> }<br /> <br /> This method will be inherited by the MyApplication class and, so, through the CreateDocument method, it will actually instantiate MyDocument objects. We will call the CreateDocument method a Factory Method because it is responsible with 'making' an object. Through this method, redefined in Application's subclasses, we can actually shape the situation in which the Application class creates objects without knowing their type. From this point of view the factory method is pattern which provides us a way to achieve the DIP principle.<br /> <br /> Specific problems and implementation<br /> <br /> When implementing the Factory Method design pattern some issues may appear:<br /> <br /> Definition of Creator class<br /> <br /> If we apply the pattern to an already written code there may be problems with the way we have the Creator class already defined. There are two cases:<br /> <br /> * Creator class is abstract and generating method does not have any implementation. In this case the ConcreteCreator classes must define their own generation method and this situation usually appears in the cases where the Creator class can't foresee what ConcreteProduct it will instantiate.<br /> * Creator class is a concrete class, the generating method having a default implementation. If this happens, the ConcreteCreator classes will use the generating method for flexibility rather than for generation. The programmer will always be able to modify the class of the objects that the Creator class implicitly creates, redefining the generation method.<br /> <br /> Factory method is just a particular case of the factory design pattern. In the same time it is the most known factory pattern, maybe because it was published in the GoF. In modern programming languages the factory with registration is more used.<br /> <br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28802 2009-11-18T22:38:50Z

<p>Kal el: /* Factory Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> &lt;code&gt;<br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28800 2009-11-18T22:37:08Z

<p>Kal el: /* Factory Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> public interface Product { … }<br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product { … }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28797 2009-11-18T22:34:47Z

<p>Kal el: /* Factory Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> <br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28796 2009-11-18T22:33:59Z

<p>Kal el: /* Factory Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> public interface Product<br /> { <br /> }<br /> public abstract class Creator<br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> protected abstract Product factoryMethod();<br /> }<br /> public class ConcreteProduct implements Product {<br /> }<br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> public class Client<br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> <br /> <br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> <br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28793 2009-11-18T22:27:25Z

<p>Kal el: /* Example of factory method */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> public interface Product{ <br /> }<br /> <br /> public abstract class Creator{<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> <br /> public class ConcreteProduct implements Product {<br /> }<br /> <br /> public class ConcreteCreator extends Creator {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> <br /> public class Client{<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> <br /> <br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> <br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===More Examples of factory pattern===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28792 2009-11-18T22:26:20Z

<p>Kal el: /* What is factory method? */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> public interface Product{ <br /> }<br /> <br /> public abstract class Creator{<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> <br /> public class ConcreteProduct implements Product {<br /> }<br /> <br /> public class ConcreteCreator extends Creator {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> <br /> public class Client{<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> <br /> <br /> <br /> *'''Applicability &amp; Examples'''<br /> <br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> <br /> <br /> *'''Example - Documents Application'''<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28789 2009-11-18T22:23:38Z

<p>Kal el: /* Factory Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> The participants classes in this pattern are:<br /> <br /> * Product defines the interface for objects the factory method creates.<br /> * ConcreteProduct implements the Product interface.<br /> * Creator(also refered as Factory because it creates the Product objects) declares the method FactoryMethod, which returns a Product object. May call the generating method for creating Product objects<br /> * ConcreteCreator overrides the generating method for creating ConcreteProduct objects<br /> <br /> All concrete products are subclasses of the Product class, so all of them have the same basic implementation, at some extent. The Creator class specifies all standard and generic behavior of the products and when a new product is needed, it sends the creation details that are supplied by the client to the ConcreteCreator. Having this diagram in mind, it is easy for us now to produce the code related to it. Here is how the implementation of the classic Factory method should look:<br /> <br /> public interface Product { … }<br /> <br /> public abstract class Creator <br /> {<br /> public void anOperation() <br /> {<br /> Product product = factoryMethod();<br /> }<br /> <br /> protected abstract Product factoryMethod();<br /> }<br /> <br /> public class ConcreteProduct implements Product { … }<br /> <br /> public class ConcreteCreator extends Creator <br /> {<br /> protected Product factoryMethod() <br /> {<br /> return new ConcreteProduct();<br /> }<br /> }<br /> <br /> public class Client <br /> {<br /> public static void main( String arg[] ) <br /> {<br /> Creator creator = new ConcreteCreator();<br /> creator.anOperation();<br /> }<br /> }<br /> <br /> <br /> <br /> Applicability &amp; Examples<br /> The need for implementing the Factory Method is very frequent. The cases are the ones below:<br /> <br /> * when a class can't anticipate the type of the objects it is supposed to create<br /> * when a class wants its subclasses to be the ones to specific the type of a newly created object<br /> <br /> <br /> <br /> Example 1 - Documents Application.<br /> <br /> Take into consideration a framework for desktop applications. Such applications are meant to work with documents. A framework for desktop applications contains definitions for operations such as opening, creating and saving a document. The basic classes are abstract ones, named Application and Document, their clients having to create subclasses from them in order to define their own applications. For generating a drawing application, for example, they need to define the DrawingApplication and DrawingDocument classes. The Application class has the task of managing the documents, taking action at the request of the client (for example, when the user selects the open or save command form the menu).<br /> <br /> Because the Document class that needs to be instantiated is specific to the application, the Application class does not know it in advance, so it doesn't know what to instantiate, but it does know when to instantiate it. The framework needs to instantiate a certain class, but it only knows abstract classes that can't be instantiated.<br /> <br /> The Factory Method design pattern solves the problem by putting all the information related to the class that needs to be instantiated into an object and using them outside the framework, as you can see below<br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=28786 2009-11-18T22:21:20Z

<p>Kal el: /* Factory Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''Motivation'''<br /> <br /> Also known as Virtual Constructor, the Factory Method is related to the idea on which libraries work: a library uses abstract classes for defining and maintaining relations between objects. One type of responsibility is creating such objects. The library knows when an object needs to be created, but not what kind of object it should create, this being specific to the application using the library.<br /> <br /> The Factory method works just the same way: it defines an interface for creating an object, but leaves the choice of its type to the subclasses, creation being deferred at run-time. A simple real life example of the Factory Method is the hotel. When staying in a hotel you first have to check in. The person working at the front desk will give you a key to your room after you've paid for the room you want and this way he can be looked at as a “room” factory. While staying at the hotel, you might need to make a phone call, so you call the front desk and the person there will connect you with the number you need, becoming a “phone-call” factory, because he controls the access to calls, too.<br /> <br /> *'''Intent'''<br /> <br /> * Defines an interface for creating objects, but let subclasses to decide which class to instantiate<br /> * Refers to the newly created object through a common interface<br /> <br /> <br /> *'''Implementation'''<br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27309 2009-11-17T14:31:21Z

<p>Kal el: /* Types of Creational Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== <br /> In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== <br /> Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== <br /> Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== <br /> It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== <br /> This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== <br /> In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== <br /> This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27303 2009-11-17T13:50:21Z

<p>Kal el: /* Architectural pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27295 2009-11-17T13:26:23Z

<p>Kal el: /* Creational patterns */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ==== Factory method pattern ==== In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ==== Abstract factory pattern ==== Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27294 2009-11-17T13:25:40Z

<p>Kal el: /* Types of Creational Pattern */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> <br /> ====Factory method pattern==== In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ====Abstract factory pattern==== Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27293 2009-11-17T13:24:50Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale.<br /> <br /> ==Creational patterns==<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> ====Factory method pattern==== In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> ====Abstract factory pattern==== Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> ====Prototype pattern==== Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> ====Builder pattern==== It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> ====Singleton pattern==== This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> ====Object pool==== In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> ====Lazy initialization pattern==== This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27291 2009-11-17T13:22:48Z

<p>Kal el: /* Classification */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ====Architectural pattern====<br /> Architectural pattern are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale.<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27287 2009-11-17T13:19:27Z

<p>Kal el: /* Classification */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> ====Structural pattern====<br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize <br /> relationships between entities.<br /> <br /> ====Behavioral pattern====<br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27286 2009-11-17T13:18:44Z

<p>Kal el: /* Classification */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ====Creational pattern====<br /> <br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> <br /> ====Structural pattern====<br /> <br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities.<br /> <br /> <br /> ====Behavioral pattern====<br /> <br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27284 2009-11-17T13:17:53Z

<p>Kal el: /* Classification */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> *Creational pattern<br /> <br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> *Structural pattern<br /> <br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities.<br /> <br /> *Behavioral pattern<br /> <br /> In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27282 2009-11-17T13:17:08Z

<p>Kal el: /* Introduction to Design Patterns */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> *Creational pattern<br /> <br /> In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.<br /> <br /> *Structural pattern<br /> <br /> In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities.<br /> <br /> *Concurrency pattern<br /> <br /> In software engineering, concurrency patterns are those types of design patterns that deal with multi-threaded programming paradigm.<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27279 2009-11-17T13:12:30Z

<p>Kal el: /* Classification */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27278 2009-11-17T13:11:13Z

<p>Kal el: /* Introduction to Design Patterns */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> ===Classification===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.For a complete list go to<br /> [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29#Classification_and_list]<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27276 2009-11-17T13:09:19Z

<p>Kal el: /* Introduction to Design Patterns */</p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> &quot;Don't reinvent the wheel&quot; all of us have heard this saying and &quot;Design Patterns&quot; is the software engineer's way of saying the same thing. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. The credit for introduction and formalization of these reusable solutions goes to the &quot;Gang of Four&quot;(Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides)[http://c2.com/cgi/wiki?GangOfFour]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> Design patterns reside in the domain of modules and interconnections. At a higher level there are Architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system.<br /> ===Classification and list===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27271 2009-11-17T12:59:33Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> Design patterns reside in the domain of modules and interconnections. At a higher level there are Architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system.<br /> ===Classification and list===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.<br /> <br /> ==Creational patterns==<br /> ===What is creational pattern===<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> <br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> ===What is factory method?===<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27270 2009-11-17T12:58:01Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.<br /> <br /> Design patterns reside in the domain of modules and interconnections. At a higher level there are Architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system.<br /> ===Classification and list===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.<br /> <br /> *'''What is factory method?'''<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''What is creational pattern?'''<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> ==Creational patterns==<br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27269 2009-11-17T12:54:28Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> <br /> ===Classification and list===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.<br /> <br /> *'''What is factory method?'''<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''What is creational pattern?'''<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> ==Creational patterns==<br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Factory Pattern==<br /> <br /> ===When to use Factory Method?===<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ===Example of factory method===<br /> <br /> ====Factory method in '''Java'''====<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ====Factory method in '''Python'''====<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ====Factory method in Ruby====<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ====Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]====<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27268 2009-11-17T12:53:09Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> <br /> ===Classification and list===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.<br /> <br /> *'''What is factory method?'''<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''What is creational pattern?'''<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> ==Creational patterns==<br /> <br /> ===Types of Creational Pattern===<br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Class diagram of Factory Method==<br /> <br /> ==When to use Factory Method?==<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ==Example of factory method==<br /> <br /> ===Factory method in '''Java'''===<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ===Factory method in '''Python'''===<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ===Factory method in Ruby===<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ===Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]===<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=27267 2009-11-17T12:51:47Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> <br /> ===Classification and list===<br /> <br /> Design patterns were originally grouped into the categories Creational patterns, Structural patterns, and Behavioral patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern that may be applied at the architecture level of the software such as the Model-View-Controller pattern.<br /> <br /> *'''What is factory method?'''<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''What is creational pattern?'''<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> ==List of creational patterns==<br /> <br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Class diagram of Factory Method==<br /> <br /> ==When to use Factory Method?==<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ==Example of factory method==<br /> <br /> ===Factory method in '''Java'''===<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ===Factory method in '''Python'''===<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ===Factory method in Ruby===<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ===Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]===<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=26958 2009-11-15T21:17:18Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction to Design Patterns==<br /> <br /> *'''What is factory method?'''<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''What is creational pattern?'''<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> ==List of creational patterns==<br /> <br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Class diagram of Factory Method==<br /> <br /> ==When to use Factory Method?==<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ==Example of factory method==<br /> <br /> ===Factory method in '''Java'''===<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ===Factory method in '''Python'''===<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ===Factory method in Ruby===<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ===Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]===<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern&diff=26801 2009-11-14T09:26:52Z

<p>Kal el: </p> <hr /> <div>&quot;Factory method is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. Be sure to emphasize how it is different from the more general Creator pattern. Also give several examples of how it can be used, and where it provides a more elegant solution than other creational patterns.&quot;<br /> <br /> ==Introduction==<br /> <br /> *'''What is factory method?'''<br /> <br /> In object oriented language, factory method pattern is a creational design pattern which deals with the mechanism of creating objects of the classes without specifying the exact class of the object. The Factory Method pattern is a lightweight pattern that achieves independence from application-specific classes. The client programs to the interface and lets the pattern sort out the rest [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6]<br /> <br /> *'''What is creational pattern?'''<br /> <br /> In software engineering creational patterns are used to create objects suitable to the situation. In object oriented design object creation may lead to design problems if they are not controlled according to situations. Creational patterns deals with this mechanism. There are a list of different creational patterns available which solves problem of creating objects in different situations. The list includes factory design pattern as well. Here we'll see how factory design pattern is different from other creational design patterns and where it is mostly used. <br /> <br /> ==List of creational patterns==<br /> <br /> * '''Factory method pattern:''' In object oriented design a factory is a place used for creating objects. Factory pattern provides centralize creation of an object of a specific type choosing one of several implementations. It encapsulates the creation of objects. At run time the decision is made about which object to instantiate depending on the situation. So it creates objects without specifying the class of the objects.<br /> <br /> * '''Abstract factory pattern:''' Abstract factory is the place to take centralize decision of what factory to instantiate. It provides an encapsulation to a group of factories that have common properties. The clients who implement abstract factories doesn't know which concrete object it gets from individual internal factories. The clients only implements the generic interface of these factories. To understand how this pattern is used refer to [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract factory]. This abstraction hides the details of different implementation of objects from their general usage. Factory design pattern is used inherently in this pattern design.<br /> <br /> * '''Prototype pattern:''' Prototype means making clones. This pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. The cost of creating new objects is resource intensive job. This pattern gives solution in this scenario where object cloning saves this cost in terms of resources. This pattern is used to avoid building a class hierarchy of factories that parallels the class hierarchy of products. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Prototype_pattern Prototype pattern].<br /> <br /> * '''Builder pattern:''' It is a creational pattern which abstracts the object creation pattern. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Builder_pattern Builder pattern]. This is much more complex object creation pattern than factory method. There may be cases where design starts with factory method and eventually leads to builder pattern according to the flexibility needed in object creation process.<br /> <br /> * '''Singleton pattern:''' This pattern restricts instantiation of the class to exactly one object. There may be situations where exactly one object of the class is needed. For example server configuration, logger etc where this pattern is used. Other design patterns like builder, prototype or abstract patterns can also use singleton pattern in their implementation. For a detailed understanding of this pattern refer to [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern].<br /> <br /> * '''Object pool:''' In object oriented design object creation and destruction after completing all operations on it is an expensive task. For example socket connection, database connection etc. are repetitive tasks but are resource intensive in terms of time. This pattern avoids this expensive acquisition and release of resources by by maintaining an object pool. The clients of the object pool places request when it needs an object and releases the hold on the object after performing desired tasks. Then the released objects are returned back to the object pool for reuse. Objects in object pool are specific type of [http://en.wikipedia.org/wiki/Factory_object factory object]. It can be used for creating singleton object also. <br /> <br /> * '''Lazy initialization pattern:''' This pattern deals with the mechanism of delaying the creation of an object until the first time the object is needed. The delay in object creation may be required depending on the situations like the calculation of a value or some other expensive process. This pattern can be used together with factory design pattern to design &quot;lazy factory&quot;. To understand how 'lazy factory' works refer to [http://en.wikipedia.org/wiki/Lazy_initialization lazy initialization].<br /> <br /> ==Class diagram of Factory Method==<br /> <br /> ==When to use Factory Method?==<br /> <br /> The Factory patterns can be used in following situations:<br /> <br /> * When flexibility is important.<br /> <br /> * When a class does not know which class of objects it is going to create.<br /> <br /> * When a class gives the freedom to its subclasses to specify which objects to create.<br /> <br /> * Programmers use factory pattern where they have to create an object of any one of sub-classes depending on the data provided. The information about which class object is to create is not known to programmers beforehand and the decision is made at run time depending on the data provided.<br /> <br /> * When there is a specific reason why one subclass would be chosen over another. Basically this logic forms part of the Factory Method.<br /> <br /> * When the clients delegates responsibilities to subclasses in parallel hierarchies [http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm 6].<br /> <br /> * In test driven environment for the classes to be put under test[http://en.wikipedia.org/wiki/Factory_method#cite_note-1 3].<br /> <br /> ==Example of factory method==<br /> <br /> ===Factory method in '''Java'''===<br /> <br /> abstract class Coffee {<br /> public abstract double getPrice();<br /> }<br /> class MochaCoffee extends Coffee {<br /> public double getPrice() {<br /> return 2.65;<br /> }<br /> }<br /> class CafeLate extends Coffee {<br /> public double getPrice() {<br /> return 2.10;<br /> }<br /> }<br /> class DarkRoastCoffee extends Coffee {<br /> public double getPrice() {<br /> return 1.96;<br /> }<br /> }<br /> class CoffeeFactory {<br /> public enum CoffeeType {<br /> Mocha,<br /> CafeLate,<br /> DarkRoast<br /> }<br /> public static Coffee createCoffee(CoffeeType coffeeType) {<br /> switch (coffeeType) {<br /> case Mocha:<br /> return new MochaCoffee();<br /> case CafeLate:<br /> return new CafeLate();<br /> case DarkRoast:<br /> return new DarkRoastCoffee();<br /> }<br /> throw new IllegalArgumentException(coffeeType + &quot; is not an expected coffee type. This &quot; + coffeeType + &quot; is not served.&quot;);<br /> }<br /> }<br /> class coffeeLover {<br /> /*<br /> * Create all available coffees in the coffeeshop and print their prices<br /> */<br /> public static void main (String args[]) {<br /> for (CoffeeFactory.CoffeeType coffeeType : CoffeeFactory.CoffeeType.values()) {<br /> System.out.println(&quot;Price of &quot; + coffeeType + &quot; is &quot; + CoffeeFactory.createCoffee(coffeeType).getPrice());<br /> }<br /> }<br /> }<br /> <br /> ===Factory method in '''Python'''===<br /> <br /> #: <br /> # A simple static factory method.<br /> from __future__ import generators<br /> import random<br /> ##<br /> class Coffee(object):<br /> # Create based on class name:<br /> def factory(type):<br /> #return eval(type + &quot;()&quot;)<br /> if type == &quot;CafeMocha&quot;: return CafeMocha()<br /> if type == &quot;CafeLate&quot;: return CafeLate()<br /> assert 1, &quot;We don't serve this coffee: &quot; + type<br /> factory = staticmethod(factory)<br /> ##<br /> class CafeMocha(Coffee):<br /> def dark(self): print &quot;CafeMocha.dark&quot; <br /> def white(self): print &quot;CafeMocha.white&quot; <br /> ##<br /> class CafeLate(Coffee):<br /> def dark(self): print &quot;CafeLate.dark&quot; <br /> def white(self): print &quot;CafeLate.white&quot; <br /> ##<br /> # Generate coffee name strings:<br /> def caffeeNameGen(n):<br /> types = Coffee.__subclasses__()<br /> for i in range(n):<br /> yield random.choice(types).__name__<br /> ##<br /> coffee_name = \<br /> [ Coffee.factory(i) for i in coffeeNameGen(7)]<br /> ##<br /> for coffee in coffee_name:<br /> coffee.dark()<br /> coffee.white()<br /> #:~<br /> <br /> ===Factory method in Ruby===<br /> <br /> class CoffeeFactory <br /> def initialize(type) <br /> @dark_coffee = self.class.const_get(&quot;#{type}Dark&quot;) <br /> @white_coffee = self.class.const_get(&quot;#{type}White&quot;) <br /> end <br /> //<br /> def new_dark <br /> @dark_coffee.new <br /> end <br /> //<br /> def new_white <br /> @white_coffee.new <br /> end <br /> end <br /> //<br /> cafe_factory = CoffeeFactory.new('CAFE') <br /> cafe_dark = cafe_factory.new_dark <br /> //<br /> late_factory = CoffeeFactory.new('LATE') <br /> late_white = late_factory.new_white<br /> <br /> ===Factory method in [http://sourcemaking.com/design_patterns/factrory_method/c%2523 C#]===<br /> <br /> using System;<br /> using System.Collections;<br /> class MainApp<br /> {<br /> static void Main()<br /> {<br /> // An array of creators <br /> Creator[] creators = new Creator[2];<br /> creators[0] = new ConcreteCreatorA();<br /> creators[1] = new ConcreteCreatorB();<br /> //<br /> // Iterate over creators and create products <br /> foreach(Creator creator in creators)<br /> {<br /> Product product = creator.FactoryMethod();<br /> Console.WriteLine(&quot;Created {0}&quot;, <br /> product.GetType().Name);<br /> }<br /> //<br /> // Wait for user <br /> Console.Read();<br /> }<br /> }<br /> //<br /> // &quot;Product&quot; <br /> abstract class Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductA&quot; <br /> class ConcreteProductA : Product<br /> {<br /> }<br /> //<br /> // &quot;ConcreteProductB&quot; <br /> class ConcreteProductB : Product<br /> {<br /> }<br /> //<br /> // &quot;Creator&quot; <br /> abstract class Creator<br /> {<br /> public abstract Product FactoryMethod();<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorA : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductA();<br /> }<br /> }<br /> //<br /> // &quot;ConcreteCreator&quot; <br /> class ConcreteCreatorB : Creator<br /> {<br /> public override Product FactoryMethod()<br /> {<br /> return new ConcreteProductB();<br /> }<br /> }<br /> //<br /> Created ConcreteProductA<br /> Created ConcreteProductB<br /> <br /> ==Limitations==<br /> <br /> In spite of advantages of factory method there are few limitations of factory method. <br /> * The main limitation is this pattern is very difficult to refactor.<br /> <br /> * Another difficulty is that the subclasses can't be extended as the pattern initializes the constructor as private. Generally the subclasses inherit the superclass constructor but here in this case it can not be done as the superclass constructor is always private.<br /> <br /> * This difficulty can be overcome by changing constructor type from private to protected but the problem is then the subclasses need to re implement all the methods again with same signature.<br /> <br /> ==Conclusion==<br /> <br /> <br /> ==Index==<br /> <br /> ==References==<br /> <br /> [1] http://wapedia.mobi/en/Creational_pattern - Creational pattern<br /> <br /> [2] http://www.artima.com/forums/flat.jsp?forum=17&amp;thread=80613 - Prototype pattern<br /> <br /> [3] http://en.wikipedia.org/wiki/Factory_method - Factory method<br /> <br /> [4] http://www.allapplabs.com/java_design_patterns/factory_pattern.htm - Factory method<br /> <br /> [5] http://sourcemaking.com/design_patterns/factrory_method/c%2523 - Factory method in C#</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=25174 2009-10-10T00:52:13Z

<p>Kal el: /* Summary */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism is a feature that allows Objects of different data types to be handled using a uniform/consistent interface. Basically Polymorphism allows us to treat subclass objects in the same way as parent class objects and gives us the flexibility to add subclass specific behavior.<br /> <br /> ===Abstraction in Object Oriented Programming Languages===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> &lt;code&gt;<br /> <br /> Java Code <br /> <br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> &lt;/code&gt;<br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction: Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation: By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance: Both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism: &quot;Guard&quot; and &quot;Center&quot; player have there own specific roles in the team but there true type is Basketballplayer that is they are forms of BasketballPlayer<br /> <br /> Also, something worth noting here is the way we will use any player whether he is &quot;Guard&quot; or &quot;Centre&quot; is the same as we have provided a common interface for them using Inheritance and Polymorphism.<br /> <br /> ===Summary===<br /> As seen from our discussion Object Model inculcates the principles of Abstraction to enable the developer to create user friendly, consistent and reusable software.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24727 2009-10-09T23:15:55Z

<p>Kal el: /* Conclusion */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism is a feature that allows Objects of different data types to be handled using a uniform/consistent interface. Basically Polymorphism allows us to treat subclass objects in the same way as parent class objects and gives us the flexibility to add subclass specific behavior.<br /> <br /> ===Abstraction in Object Oriented Programming Languages===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> &lt;code&gt;<br /> <br /> Java Code <br /> <br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> &lt;/code&gt;<br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction: Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation: By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance: Both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism: &quot;Guard&quot; and &quot;Center&quot; player have there own specific roles in the team but there true type is Basketballplayer that is they are forms of BasketballPlayer<br /> <br /> Also, something worth noting here is the way we will use any player whether he is &quot;Guard&quot; or &quot;Centre&quot; is the same as we have provided a common interface for them using Inheritance and Polymorphism.<br /> <br /> ===Summary===<br /> As seen from our discussion Object Model inculcates the principles of Abstraction to enable the developer to create user friendly consistent and reusable software.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24718 2009-10-09T23:08:22Z

<p>Kal el: /* Abstraction in Object Oriented Programming Languages */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism is a feature that allows Objects of different data types to be handled using a uniform/consistent interface. Basically Polymorphism allows us to treat subclass objects in the same way as parent class objects and gives us the flexibility to add subclass specific behavior.<br /> <br /> ===Abstraction in Object Oriented Programming Languages===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> &lt;code&gt;<br /> <br /> Java Code <br /> <br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> &lt;/code&gt;<br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction: Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation: By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance: Both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism: &quot;Guard&quot; and &quot;Center&quot; player have there own specific roles in the team but there true type is Basketballplayer that is they are forms of BasketballPlayer<br /> <br /> Also, something worth noting here is the way we will use any player whether he is &quot;Guard&quot; or &quot;Centre&quot; is the same as we have provided a common interface for them using Inheritance and Polymorphism.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24716 2009-10-09T23:07:01Z

<p>Kal el: /* Abstraction in Object Oriented Programming Languages */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism is a feature that allows Objects of different data types to be handled using a uniform/consistent interface. Basically Polymorphism allows us to treat subclass objects in the same way as parent class objects and gives us the flexibility to add subclass specific behavior.<br /> <br /> ===Abstraction in Object Oriented Programming Languages===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> &lt;code&gt;<br /> <br /> Java Code <br /> <br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> &lt;/code&gt;<br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction: Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation: By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance: Both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism: &quot;Guard&quot; and &quot;Center&quot; player have there own specific roles in the team but there true type is Basketballplayer that is they are forms of BasketballPlayer<br /> <br /> Also, something worth noting here is the way we will use any player whether he is &quot;Guard&quot; or &quot;Centre&quot; is the same as we have provided a common interface for them using Inheritance and Polymorphism.<br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24715 2009-10-09T23:05:59Z

<p>Kal el: /* Abstraction in Object Oriented Programming Languages */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism is a feature that allows Objects of different data types to be handled using a uniform/consistent interface. Basically Polymorphism allows us to treat subclass objects in the same way as parent class objects and gives us the flexibility to add subclass specific behavior.<br /> <br /> ===Abstraction in Object Oriented Programming Languages===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> &lt;code&gt;<br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> &lt;/code&gt;<br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction: Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation: By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance: Both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism: &quot;Guard&quot; and &quot;Center&quot; player have there own specific roles in the team but there true type is Basketballplayer that is they are forms of BasketballPlayer<br /> <br /> Also, something worth noting here is the way we will use any player whether he is &quot;Guard&quot; or &quot;Centre&quot; is the same as we have provided a common interface for them using Inheritance and Polymorphism.<br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24700 2009-10-09T22:59:24Z

<p>Kal el: /* Abstraction in Object Oriented Programming */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism is a feature that allows Objects of different data types to be handled using a uniform/consistent interface. Basically Polymorphism allows us to treat subclass objects in the same way as parent class objects and gives us the flexibility to add subclass specific behavior.<br /> <br /> ===Abstraction in Object Oriented Programming Languages===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> &lt;source lang=java&gt;<br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> &lt;/source&gt;<br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction: Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation: By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance: Both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism: &quot;Guard&quot; and &quot;Center&quot; player have there own specific roles in the team but there true type is Basketballplayer that is they are forms of BasketballPlayer<br /> <br /> Also, something worth noting here is the way we will use any player whether he is &quot;Guard&quot; or &quot;Centre&quot; is the same as we have provided a common interface for them using Inheritance and Polymorphism.<br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24694 2009-10-09T22:53:52Z

<p>Kal el: /* Polymorphism */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism is a feature that allows Objects of different data types to be handled using a uniform/consistent interface. Basically Polymorphism allows us to treat subclass objects in the same way as parent class objects and gives us the flexibility to add subclass specific behavior.<br /> <br /> ===Abstraction in Object Oriented Programming===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction: Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation: By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance: Both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism :<br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24676 2009-10-09T22:45:52Z

<p>Kal el: </p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism ia a feature that allows Objects of different data types to be handled using a uniform/consistent interface.<br /> <br /> ===Abstraction in Object Oriented Programming===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction: Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation: By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance: Both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism :<br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24671 2009-10-09T22:44:08Z

<p>Kal el: </p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism ia a feature that allows Objects of different data types to be handled using a uniform/consistent interface.<br /> <br /> ===Abstraction in Object Oriented Programming===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> <br /> In the above example:<br /> <br /> * Basketball Player is an abstract class<br /> * Guard and Center are concrete implementations of abstract class BasketballPlayer<br /> <br /> Now lets see how have we managed to include all the principles of abstraction and Object Modelling that we have discussed so far in this example<br /> <br /> *Data Abstraction <br /> **Our system uses 'jersey number' to identify players but the user will use the abstracted form which will be &quot;Guard&quot; or &quot;Centre&quot; <br /> * Encapsulation<br /> **By making 'jersey number' private we have encapsulated it from user's visibility and we can chose to provide methods for the user to manage the 'jersey number'<br /> * Inheritance <br /> ** both Guard and Centre inherit features like &quot;dribble&quot; and 'jersey number' from BasketballPlayer<br /> * Polymorphism<br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24643 2009-10-09T22:34:00Z

<p>Kal el: /* Abstraction in Object Oriented Programming */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism ia a feature that allows Objects of different data types to be handled using a uniform/consistent interface.<br /> <br /> ===Abstraction in Object Oriented Programming===<br /> In this section we will see how Java which is an Object Oriented Programming Language, supports the object model and abstraction principles. Java offers the key word &quot;abstract&quot; which we can use to create an abstract class. &quot;An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendant subclasses.&quot; Seems complicated but it isn't. What we mean here is you cannot instantiate an object of an abstract class. To use the features of an abstract class we will have to create an instance of an object of a sub class. Lets take an example to understand this in a better way.<br /> <br /> Consider the game of Basketball. Now a Basketball consists of several players that performed specialized tasks. Some of the common positions are &quot;center&quot;, &quot;forward&quot; and &quot;guard&quot; . Though all of them are specialized positions they have several skills in common for instance all of these players must know how to &quot;dribble&quot; and &quot;pass&quot; to name a few.<br /> <br /> Lets see how a Java Class hierarchy will look like for such an example:<br /> <br /> public abstract class BasketballPlayer<br /> {<br /> private int number; //number on jersey<br /> public void dribble(); // abstract method declaration<br /> public void pass();<br /> public void run()<br /> {<br /> // code that can make a player run<br /> } <br /> }<br /> <br /> public class Guard extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and block Center Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and blocking code <br /> }<br /> }<br /> <br /> public class Centre extends BasketballPlayer<br /> {<br /> public void dribble() // abstract method implementation<br /> {<br /> // code that can make my player dribble extraordinarily and trick Gaurd Players<br /> } <br /> public void pass()<br /> {<br /> // excellent pass throwing and Recieving code <br /> }<br /> public void shoot() // method specific to a centre player<br /> {<br /> // shooting code goes here<br /> }<br /> }<br /> <br /> Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of polymorphism in object-oriented programming, which includes the substitution of one type for another in the same or similar role. Although not as generally supported, a configuration or image or package may predetermine a great many of these bindings at compile-time, link-time, or loadtime. This would leave only a minimum of such bindings to change at run-time. <br /> Common Lisp Object System or self, for example, feature less of a class-instance distinction and more use of delegation for polymorphism. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from Lisp. <br /> C++ exemplifies another extreme: it relies heavily on templates and overloading and other static bindings at compile-time, which in turn has certain flexibility problems. <br /> Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes. <br /> Consider for example a sample Java fragment to represent some common farm &quot;animals&quot; to a level of abstraction suitable to model simple aspects of their hunger and feeding.It defines an &lt;code&gt;Animal&lt;/code&gt; class to represent both the state of the animal and its functions:<br /> <br /> &lt;source lang = java&gt;<br /> public abstract class LivingThing<br /> {<br /> boolean isHungry() ;<br /> void eat(Food f);<br /> void moveTo(Location l);<br /> }<br /> &lt;/source&gt;<br /> <br /> &lt;source lang = java&gt;<br /> public class Animal extends LivingThing<br /> {<br /> private Location loc;<br /> private double energyReserves;<br /> <br /> boolean isHungry() {<br /> return energyReserves &lt; 2.5;<br /> }<br /> void eat(Food f) {<br /> // Consume food<br /> energyReserves += f.getCalories();<br /> }<br /> void moveTo(Location l) {<br /> // Move to new location<br /> loc = l;<br /> }<br /> }<br /> &lt;/source&gt;<br /> With the above definition, one could create objects of type &lt;tt&gt;Animal&lt;/tt&gt; and call their methods like this:<br /> <br /> &lt;source lang=java&gt;<br /> thePig = new Animal();<br /> theCow = new Animal();<br /> if (thePig.isHungry()) {<br /> thePig.eat(tableScraps);<br /> }<br /> if (theCow.isHungry()) {<br /> theCow.eat(grass);<br /> }<br /> theCow.moveTo(theBarn);<br /> &lt;/source&gt;<br /> In the above example, the class ''&lt;code&gt;Animal&lt;/code&gt;'' is an abstraction used in place of an actual animal, ''&lt;code&gt;LivingThing&lt;/code&gt;'' is a further abstraction (in this case a generalisation) of &lt;code&gt;Animal&lt;/code&gt;. <br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24513 2009-10-09T21:43:45Z

<p>Kal el: /* Object Model */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles. Also one can see these ideas as the corner stones of any Object Model. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism ia a feature that allows Objects of different data types to be handled using a uniform/consistent interface.<br /> <br /> ===Abstraction in Object Oriented Programming===<br /> Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of polymorphism in object-oriented programming, which includes the substitution of one type for another in the same or similar role. Although not as generally supported, a configuration or image or package may predetermine a great many of these bindings at compile-time, link-time, or loadtime. This would leave only a minimum of such bindings to change at run-time. <br /> Common Lisp Object System or self, for example, feature less of a class-instance distinction and more use of delegation for polymorphism. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from Lisp. <br /> C++ exemplifies another extreme: it relies heavily on templates and overloading and other static bindings at compile-time, which in turn has certain flexibility problems. <br /> Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes. <br /> Consider for example a sample Java fragment to represent some common farm &quot;animals&quot; to a level of abstraction suitable to model simple aspects of their hunger and feeding.It defines an &lt;code&gt;Animal&lt;/code&gt; class to represent both the state of the animal and its functions:<br /> <br /> &lt;source lang = java&gt;<br /> public abstract class LivingThing<br /> {<br /> boolean isHungry() ;<br /> void eat(Food f);<br /> void moveTo(Location l);<br /> }<br /> &lt;/source&gt;<br /> <br /> &lt;source lang = java&gt;<br /> public class Animal extends LivingThing<br /> {<br /> private Location loc;<br /> private double energyReserves;<br /> <br /> boolean isHungry() {<br /> return energyReserves &lt; 2.5;<br /> }<br /> void eat(Food f) {<br /> // Consume food<br /> energyReserves += f.getCalories();<br /> }<br /> void moveTo(Location l) {<br /> // Move to new location<br /> loc = l;<br /> }<br /> }<br /> &lt;/source&gt;<br /> With the above definition, one could create objects of type &lt;tt&gt;Animal&lt;/tt&gt; and call their methods like this:<br /> <br /> &lt;source lang=java&gt;<br /> thePig = new Animal();<br /> theCow = new Animal();<br /> if (thePig.isHungry()) {<br /> thePig.eat(tableScraps);<br /> }<br /> if (theCow.isHungry()) {<br /> theCow.eat(grass);<br /> }<br /> theCow.moveTo(theBarn);<br /> &lt;/source&gt;<br /> In the above example, the class ''&lt;code&gt;Animal&lt;/code&gt;'' is an abstraction used in place of an actual animal, ''&lt;code&gt;LivingThing&lt;/code&gt;'' is a further abstraction (in this case a generalisation) of &lt;code&gt;Animal&lt;/code&gt;. <br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24511 2009-10-09T21:42:22Z

<p>Kal el: /* Object Model */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Object Models make use of following Four concepts or ideas to achieve abstraction principles: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism ia a feature that allows Objects of different data types to be handled using a uniform/consistent interface.<br /> <br /> ===Abstraction in Object Oriented Programming===<br /> Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of polymorphism in object-oriented programming, which includes the substitution of one type for another in the same or similar role. Although not as generally supported, a configuration or image or package may predetermine a great many of these bindings at compile-time, link-time, or loadtime. This would leave only a minimum of such bindings to change at run-time. <br /> Common Lisp Object System or self, for example, feature less of a class-instance distinction and more use of delegation for polymorphism. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from Lisp. <br /> C++ exemplifies another extreme: it relies heavily on templates and overloading and other static bindings at compile-time, which in turn has certain flexibility problems. <br /> Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes. <br /> Consider for example a sample Java fragment to represent some common farm &quot;animals&quot; to a level of abstraction suitable to model simple aspects of their hunger and feeding.It defines an &lt;code&gt;Animal&lt;/code&gt; class to represent both the state of the animal and its functions:<br /> <br /> &lt;source lang = java&gt;<br /> public abstract class LivingThing<br /> {<br /> boolean isHungry() ;<br /> void eat(Food f);<br /> void moveTo(Location l);<br /> }<br /> &lt;/source&gt;<br /> <br /> &lt;source lang = java&gt;<br /> public class Animal extends LivingThing<br /> {<br /> private Location loc;<br /> private double energyReserves;<br /> <br /> boolean isHungry() {<br /> return energyReserves &lt; 2.5;<br /> }<br /> void eat(Food f) {<br /> // Consume food<br /> energyReserves += f.getCalories();<br /> }<br /> void moveTo(Location l) {<br /> // Move to new location<br /> loc = l;<br /> }<br /> }<br /> &lt;/source&gt;<br /> With the above definition, one could create objects of type &lt;tt&gt;Animal&lt;/tt&gt; and call their methods like this:<br /> <br /> &lt;source lang=java&gt;<br /> thePig = new Animal();<br /> theCow = new Animal();<br /> if (thePig.isHungry()) {<br /> thePig.eat(tableScraps);<br /> }<br /> if (theCow.isHungry()) {<br /> theCow.eat(grass);<br /> }<br /> theCow.moveTo(theBarn);<br /> &lt;/source&gt;<br /> In the above example, the class ''&lt;code&gt;Animal&lt;/code&gt;'' is an abstraction used in place of an actual animal, ''&lt;code&gt;LivingThing&lt;/code&gt;'' is a further abstraction (in this case a generalisation) of &lt;code&gt;Animal&lt;/code&gt;. <br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24500 2009-10-09T21:38:14Z

<p>Kal el: /* Abstraction in Object Oriented Programming */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Four concepts are critical to understanding object models. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism ia a feature that allows Objects of different data types to be handled using a uniform/consistent interface.<br /> <br /> ===Abstraction in Object Oriented Programming===<br /> Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of polymorphism in object-oriented programming, which includes the substitution of one type for another in the same or similar role. Although not as generally supported, a configuration or image or package may predetermine a great many of these bindings at compile-time, link-time, or loadtime. This would leave only a minimum of such bindings to change at run-time. <br /> Common Lisp Object System or self, for example, feature less of a class-instance distinction and more use of delegation for polymorphism. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from Lisp. <br /> C++ exemplifies another extreme: it relies heavily on templates and overloading and other static bindings at compile-time, which in turn has certain flexibility problems. <br /> Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes. <br /> Consider for example a sample Java fragment to represent some common farm &quot;animals&quot; to a level of abstraction suitable to model simple aspects of their hunger and feeding.It defines an &lt;code&gt;Animal&lt;/code&gt; class to represent both the state of the animal and its functions:<br /> <br /> &lt;source lang = java&gt;<br /> public abstract class LivingThing<br /> {<br /> boolean isHungry() ;<br /> void eat(Food f);<br /> void moveTo(Location l);<br /> }<br /> &lt;/source&gt;<br /> <br /> &lt;source lang = java&gt;<br /> public class Animal extends LivingThing<br /> {<br /> private Location loc;<br /> private double energyReserves;<br /> <br /> boolean isHungry() {<br /> return energyReserves &lt; 2.5;<br /> }<br /> void eat(Food f) {<br /> // Consume food<br /> energyReserves += f.getCalories();<br /> }<br /> void moveTo(Location l) {<br /> // Move to new location<br /> loc = l;<br /> }<br /> }<br /> &lt;/source&gt;<br /> With the above definition, one could create objects of type &lt;tt&gt;Animal&lt;/tt&gt; and call their methods like this:<br /> <br /> &lt;source lang=java&gt;<br /> thePig = new Animal();<br /> theCow = new Animal();<br /> if (thePig.isHungry()) {<br /> thePig.eat(tableScraps);<br /> }<br /> if (theCow.isHungry()) {<br /> theCow.eat(grass);<br /> }<br /> theCow.moveTo(theBarn);<br /> &lt;/source&gt;<br /> In the above example, the class ''&lt;code&gt;Animal&lt;/code&gt;'' is an abstraction used in place of an actual animal, ''&lt;code&gt;LivingThing&lt;/code&gt;'' is a further abstraction (in this case a generalisation) of &lt;code&gt;Animal&lt;/code&gt;. <br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_15_A%26OM&diff=24492 2009-10-09T21:34:02Z

<p>Kal el: /* Abstraction in object oriented programming */</p> <hr /> <div>==Abstraction and the Object Model==<br /> ===Abstraction===<br /> Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html]. <br /> <br /> Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc.<br /> <br /> In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29]. <br /> <br /> * Control abstraction in involves the use of subprograms and related concepts control flows <br /> * Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype. <br /> <br /> One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.<br /> <br /> ===Object Model===<br /> Four concepts are critical to understanding object models. They are: <br /> * Data Abstraction <br /> * Encapsulation <br /> * Inheritance <br /> * Polymorphism<br /> <br /> ====Encapsulation====<br /> The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.<br /> ====Data Abstraction ====<br /> Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation[http://www.service-architecture.com/database/articles/object_model_concepts.html].<br /> <br /> ====Inheritance ====<br /> Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.<br /> ====Polymorphism====<br /> Literally Polymorphism means the ability to take multiple forms. In case of Object oriented Languages polymorphism ia a feature that allows Objects of different data types to be handled using a uniform/consistent interface.<br /> <br /> ===Abstraction in Object Oriented Programming===<br /> Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of polymorphism in object-oriented programming, which includes the substitution of one type for another in the same or similar role. Although not as generally supported, a configuration or image or package may predetermine a great many of these bindings at compile-time, link-time, or loadtime. This would leave only a minimum of such bindings to change at run-time. <br /> Common Lisp Object System or self, for example, feature less of a class-instance distinction and more use of delegation for polymorphism. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from Lisp. <br /> C++ exemplifies another extreme: it relies heavily on templates and overloading and other static bindings at compile-time, which in turn has certain flexibility problems. <br /> Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes. <br /> Consider for example a sample Java fragment to represent some common farm &quot;animals&quot; to a level of abstraction suitable to model simple aspects of their hunger and feeding.It defines an &lt;code&gt;Animal&lt;/code&gt; class to represent both the state of the animal and its functions:<br /> <br /> &lt;source lang = java&gt;<br /> <br /> class Animal extends LivingThing<br /> {<br /> private Location loc;<br /> private double energyReserves;<br /> <br /> boolean isHungry() {<br /> return energyReserves &lt; 2.5;<br /> }<br /> void eat(Food f) {<br /> // Consume food<br /> energyReserves += f.getCalories();<br /> }<br /> void moveTo(Location l) {<br /> // Move to new location<br /> loc = l;<br /> }<br /> }<br /> &lt;/source&gt;<br /> With the above definition, one could create objects of type &lt;tt&gt;Animal&lt;/tt&gt; and call their methods like this:<br /> <br /> &lt;source lang=java&gt;<br /> thePig = new Animal();<br /> theCow = new Animal();<br /> if (thePig.isHungry()) {<br /> thePig.eat(tableScraps);<br /> }<br /> if (theCow.isHungry()) {<br /> theCow.eat(grass);<br /> }<br /> theCow.moveTo(theBarn);<br /> &lt;/source&gt;<br /> In the above example, the class ''&lt;code&gt;Animal&lt;/code&gt;'' is an abstraction used in place of an actual animal, ''&lt;code&gt;LivingThing&lt;/code&gt;'' is a further abstraction (in this case a generalisation) of &lt;code&gt;Animal&lt;/code&gt;. <br /> <br /> If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. <br /> Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.<br /> <br /> ===Conclusion===<br /> Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. <br /> In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis.<br /> <br /> ===References ===<br /> #http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html <br /> #http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29<br /> #http://www.service-architecture.com/database/articles/object_model_concepts.html <br /> #http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html</div>

Kal el