Abstract Factory Vs Builder

The abstract factory pattern is a software design pattern that provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme. The client does not know (or care) which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage.

An example of this would be an abstract factory class DocumentCreator that provides interfaces to create a number of products (e.g. createLetter() and createResume()). The system would have any number of derived concrete versions of the DocumentCreator class like FancyDocumentCreator or ModernDocumentCreator, each with a different implementation of createLetter() and createResume() that would create a corresponding object like FancyLetter or ModernResume. Each of these products is derived from a simple abstract class like Letter or Resume of which the client is aware. The client code would get an appropriate instance of the DocumentCreator and call its factory methods. Each of the resulting objects would be created from the same DocumentCreator implementation and would share a common theme (they would all be fancy or modern objects). The client would need to know how to handle only the abstract Letter or Resume class, not the specific version that it got from the concrete factory.

In software development, a Factory is the location in the code at which objects are constructed. The intent in employing the pattern is to insulate the creation of objects from their usage. This allows for new derived types to be introduced with no change to the code that uses the base class.

Use of this pattern makes it possible to interchange concrete classes without changing the code that uses them, even at runtime. However, employment of this pattern, as with similar design patterns, may result in unnecessary complexity and extra work in the initial writing of code. Used correctly the "extra work" pays off in the second instance of using the Factory.

 

 

The builder pattern is a software design pattern. The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects. Often, the builder pattern is used to build products in accordance to the composite pattern, a structural pattern.

        Builder

Abstract interface for creating objects (product).

Concrete Builder

Provides implementation for Builder. It is an object able to construct other objects. Constructs and assembles parts to build the objects.

        Director

The Director class is responsible for managing the correct sequence of object creation. It receives a Concrete Builder as a parameter and executes the necessary operations on it.

        Product

The final object that will be created by the Director using Builder.

• Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
• Builder often builds a Composite.
• Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
• Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components are built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

 

 

 

 

Diff b/w Factory & Builder

 

The factor pattern defers the choice of what concrete type of object to 

make until run time. E.g. going to a restaurant to order the special of 
the day.  The waiter is the interface to the factory that takes the 
abstractor generic message "Get me the special of the day!" and returns 
the concrete product (i.e Liver souffle or Chicken caramel) 

The builder pattern encapsulates the logic of how to put together a 
complex object so that the client just requests a configuration and the 
builder directs the logic of building it.   E.g The main contractor 
(builder) in building a house knows, given a floor plan, knows how to 
execute the sequence of operations (i,e. by delegating to subcontractors) 
needed to build the complex object.  If that logic was not encapsulated in 
a builder, then the buyers would have to organize the subcontracting 
themselves ("Dear, shouldn't we have asked for the foundation to be laid 
before the roofers showed up?") 

The factory is concerned with what is made, the builder with how it is 
made.  Design patterns points out that (page 105) Abstract factory is 
similar to builder in that it too may construct complex objects.  The 
primary difference is that the Builder pattern focuses on constructing a 
complex object step by step.  Abstract factor's emphasis is on families of 
product objects(either simple or complex).  Builder returns the product as 
the final step, but as far as the Abstract Factory is concerned, the 
product gets returned immediately