Factory Method Design Pattern

[Suyay Escarsega]

FactoryMethod is a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created.

Great news, right? But how about the code? At present, most of your code is coupled to the Truck class. Adding Ships into the app would require making changes to the entire codebase. Moreover, if later you decide to add another type of transportation to the app, you will probably need to make all of these changes again.

At first glance, this change may look pointless: we just moved the constructor call from one part of the program to another. However, consider this: now you can override the factory method in a subclass and change the class of products being created by the method.

For example, both Truck and Ship classes should implement the Transport interface, which declares a method called deliver. Each class implements this method differently: trucks deliver cargo by land, ships deliver cargo by sea. The factory method in the RoadLogistics class returns truck objects, whereas the factory method in the SeaLogistics class returns ships.

Note, despite its name, product creation is not the primary responsibility of the creator. Usually, the creator class already has some core business logic related to products. The factory method helps to decouple this logic from the concrete product classes. Here is an analogy: a large software development company can have a training department for programmers. However, the primary function of the company as a whole is still writing code, not producing programmers.

The base Dialog class uses different UI elements to render its window. Under various operating systems, these elements may look a little bit different, but they should still behave consistently. A button in Windows is still a button in Linux.

For this pattern to work, the base Dialog class must work with abstract buttons: a base class or an interface that all concrete buttons follow. This way the code within Dialog remains functional, whichever type of buttons it works with.

Inheritance is probably the easiest way to extend the default behavior of a library or framework. But how would the framework recognize that your subclass should be used instead of a standard component?

Now, create a set of creator subclasses for each type of product listed in the factory method. Override the factory method in the subclasses and extract the appropriate bits of construction code from the base method.

Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate. The Factory method lets a class defer instantiation it uses to subclasses." (Gang Of Four)

There are no "Factory" nor "Simple Factory" nor "Virtual Factory" definitions in the book. Usually when people are talking about "Factory" pattern they may be talking about something that creates a particular object of a class (but not the "builder" pattern); they may or may not refer to the "Factory Method" or "Abstract Factory" patterns. Anyone can implement "Factory" as he won't because it's not a formal term (bear in mind that some people\companies\communities can have their own vocabulary).

Source of Confusion: Often, one can call a class that used in "Factory Method" pattern as "Factory". This class is abstract by definition. That's why it easy to call this class "Abstract Factory". But it's just the name of the class; you shouldn't confuse it with "Abstract Factory" pattern (class name != pattern name). The "Abstract Factory" pattern is different - it does not use an abstract class; it defines an interface (not necessarily a programming language interface) for creating parts of a bigger object or objects that are related to each other or must be created in a particular way.

Every design pattern strives to help ensure that written, working code is not touched. We all know that once we touch working code, there are defects in existing working flows, and a lot more testing needs to get done to ensure that we did not break anything.

A good example of this is a travel website. A travel website can only provide travel (flight, train, bus) or / and provide hotels or / and provide tourist attraction packages. Now, when a user selects next, the website needs to decide what objects it needs to create. Should it only create the travel or hotel object too.

Now, if you envision adding another website to your portfolio, and you believe that the same core be used, for example, a carpooling website, which now searches for cab's and makes payments online, you can use a abstract factory at your core. This way you can just snap in one more factory of cabs and carpools.

But Abstract Factory having more than 1 factory method ( ex: 2 factory methods), using those factory methods it will create the set of objects/ related objects.Using Abstract Factory, user can able to create A1, B1 objects of AbstractProductA, AbstractProductB

There are two common ways to parameterize a system by the classes of objects it creates. One way is to subclass the class that creates the objects; this corresponds to using the Factory Method (107) pattern. The main drawback of this approach is that it can require a new subclass just to change the class of the product. Such changes can cascade. For example, when the product creator is itself created by a factory method, then you have to override its creator as well.

You have a system, which interfaces with another system. I will use the example given in Design Patterns Explained by Shalloway and Trott, P194, because this situation is so rare I can't think of a better one. In their book, they give the example of having different combinations of local hardware resources. They use, as examples:

There are 2 options for one variable thing (print driver, display driver), and 2 options for the other variable thing (high resolution, low resolution). We want to couple these together in such a way that we have a HighResolutionFactory and a LowResolutionFactory which produce for us both a print driver and display driver of the correct type.

My opinion on this pattern is that it isn't actually very useful. It couples together some things which need not be coupled together. The point of design patterns is usally to reduce coupling, not increase it, therefore in some ways this pattern is really an anti-pattern, but it might be useful in some contexts.

If you get to a stage where you are seriously considering implementing this, you might consider some alternative designs. Perhaps you could write a factory which returns factories, which themselves return the objects you eventually want. I imagine this would be more flexible, and would not have the same coupling issues.

Addendum: The example from Gang of Four is similarly coupled. They have a MotifFactory and a PMFactory. These then produce PMWindow, PMScrollBar and MotifWindow, MotifScrollBar respectively. This is a somewhat dated text now and so it might be hard to understand the context. I recall reading this chapter and the I understood little from the example beyond having two implementations of a factory base class which return different families of objects.

In object oriented programming, the factory method pattern is a design pattern that uses factory methods to deal with the problem of creating objects without having to specify their exact class. Rather than by calling a constructor, this is done by calling a factory method to create an object. Factory methods can either be specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes. It is one of the 23 classic design patterns described in the book Design Patterns (often referred to as the "Gang of Four" or simply "GoF") and is sub-categorized as a creational pattern.[1]

Creating an object often requires complex processes not appropriate to include within a composing object. The object's creation may lead to a significant duplication of code, may require information not accessible to the composing object, may not provide a sufficient level of abstraction, or may otherwise not be part of the composing object's concerns. The factory method design pattern handles these problems by defining a separate method for creating the objects, which subclasses can then override to specify the derived type of product that will be created.

The factory method pattern relies on inheritance, as object creation is delegated to subclasses that implement the factory method to create objects.[2]As shown in the C# example below, the factory method pattern can also rely on an Interface - in this case IPerson - to be implemented.

In the above UML class diagram, the Creator class that requires a Product object does not instantiate the Product1 class directly.Instead, the Creator refers to a separate factoryMethod() to create a product object,which makes the Creator independent of which concrete class is instantiated.Subclasses of Creator can redefine which class to instantiate. In this example, the Creator1 subclass implements the abstract factoryMethod() by instantiating the Product1 class.

Room is the base class for a final product (MagicRoom or OrdinaryRoom). MazeGame declares the abstract factory method to produce such a base product. MagicRoom and OrdinaryRoom are subclasses of the base product implementing the final product. MagicMazeGame and OrdinaryMazeGame are subclasses of MazeGame implementing the factory method producing the final products. Thus factory methods decouple callers (MazeGame) from the implementation of the concrete classes. This makes the "new" Operator redundant, allows adherence to the Open/closed principle and makes the final product more flexible in the event of change.

In the above code you can see the creation of one interface called IPerson and two implementations called Villager and CityPerson. Based on the type passed into the PersonFactory object, we are returning the original concrete object as the interface IPerson.

3a8082e126