1. Creational Pattern: Abstract Factory

Note about Creational patterns

This group of design patterns deals with creation of Objects in different scenarios.

The Name

This word “factory” indicates that this creates/manufactures something. Yes, it creates Objects. The word “abstract” indicates that something is abstract. Is it the object?  No. Concrete objects are created, but the reference to this concrete object is abstract.

Explanation: Usage and Structure

This design pattern deals with creating a ‘family’ of related objects (hence a factory). Thus, the responsibility of creating objects is given to the ‘factory’ and the client only has to specify the abstract type. The complexity or the specifics of object creation is hidden from the client. Since the concrete class is not specified by the client, the decision of choosing the concrete type is also lies with the ‘factory’ class.

Let’s go through steps for using this pattern with an example:

• The factory creates a product(s). To be more generic, an abstract factory creates abstract product(s). This abstraction helps to define many factories where each factory creates several products. The abstract factory(abstract class or interface) defines a factory method per product(also an abstract class or interface) required

        The below figure shows this relation:

• The abstract factory cannot directly create the abstract product because,…well, it is abstract. It is not supposed to create a product. The factory provides a provision to create a product (through the product’s abstraction). In order to create a product we first need a concrete factory. So, for this CarFactory lets implement 3 concrete factories: Porsche Factory, Ferrari factory, Mercedes factory

Abstract factory with concrete factories:

• Each factory produces a product. Let’s take the case of the Porsche factory. This factory creates a Porsche car. It can not only create a single Porsche car but can create several different models of the Porsche car (say, 911, Boxster and Cayman models). These are the different products that the Porsche factory is capable of creating. We had defined earlier that the factory can produce some kind of product (abstract product). Hence, the actual product (911) will conform to the kind of product (A car that can start, accelerate, brake and stop which is the abstract product definition) apart from adding its own specific details such as Electronic traction control

Phew. That’s a mouthful (or eyeful) of info. Let me add on to the picture above to sum up what I said above.

• Similarly, the Ferrari car factory creates Ferrari car models and the Mercedes factory creates Mercedes car models.
• All this complexity of having several factories and each factory producing several products is hidden by the Abstract Factory and the Abstract product interfaces. The concrete type also need not be specified by the client. The concrete product gets returned through the abstract product reference.The complexity of creating the actual product gets hidden.
• The complete picture for this example that depicts Abstract factory patter is shown:

• Note that the client is only interacting with the interfaces
• Thus, a product can be easily added/removed/changed without affecting the Client

Advantages

Addition/deletion of a concrete type can be done with no impact to the client as the client holds an abstract reference only. If on the other hand, objects were created by the client itself then any change to this part of the logic, affects every place the ‘new’ keyword is used. So I can conclude that the ‘new’ keyword is harmful. By using this pattern the ‘new’ keyword is used only inside the Factory class minimizing its harmful effects.

If it is required to replace the entire family of related objects (entire factory), this can be done by simply instantiating a different instance of the factory.

Implementation

All factory objects are accessed through a singleton object (class that can have a single object/instance is singleton). The client uses the singleton for creating object and changing factories is just choosing a different singleton object.

Conclusion

Abstract factory pattern thus helps to reduce the usage of the ‘new’ keyword improving the maintainability of the code and separate the creation of objects from the usage of the objects.

My first attempt at capturing the design pattern specifics turned out to be very long. I will try and keep it shorter next time.

Any comments about this explanation is welcome.

The story begins…

DESIGN PATTERNS, a term that is very common among designers and enlightening for budding designers in the software field. This topics has scores of articles in the Internet and of course there are many well known books. Then why I am I writing this again ? Well, I thought of researching design patterns to understand it to a level where it is more easier to identify where design patterns can be applied.

This series that I am starting today is not about how design patterns started(past), but to explore its present nature.

What is it ?

A design pattern is guideline to solving a design problem. The complete definition can be found in wikipedia of course, so let me try to approach this with a little more layman-ish definition. So what’s a design problem ? There is a problem to be solved and the solution  required is at the design stage. Why? Problems that are correctly designed are more robust and are ‘elegantly’ solved i.e. the final implementation is more easier to accomplish. A pattern is like a blueprint to this design problem. This can be very much related to architectural designs ( In fact the term “design pattern” originated from an architect). This blueprint/guideline/template can then be used to solve a problem. 

Why is it needed ?

Over the years of solving problems, experience has taught the better way to solve a problem. Note that I using better  instead of best because getting the best possible solution has always been challenged by the future. Today’s best solution to a problem might be still be solved in a better way tomorrow. Coming back to answer the why question, software design is plagued by commonly occurring problems. If they are so common then somebody else must have solved it right ? Of course they have. Then we can just just “re-use” the solution to these commonly occurring problems. Voila! That’s the exact reason for why design patterns are needed.

Conclusion

Now that we know what are software design patterns and why they are needed we can now explore each design pattern in detail.

Every week I will explore one design pattern giving more insights about where a design pattern can be used/ how it can be used / how it solves the problem, etc.

Comments are most welcome as I am also learning in the process.

P.S: This is my first attempt to write something serious, forgive my English or stating the obvious. My intention for starting this blog series is to give my first hand understanding of Design Patterns to a beginner in the Computer Science field.