Builder Pattern

Builder Pattern

RAVAGE

I had a good discussion over the Builder pattern with my friend. Always he tries to map the pattern with a real case scenario and alters the example so as to fit it. So the problem is while discussing with him we need to think more than once before answering him. Also the important part I like with his discussion is that he tries to map the pattern as a pluggable element. That is he tries to identify the extensible part (reusable part for specific abstraction or mode) in order to scale-up the implementation. Actually that extensible part will be the core use of the pattern.

PLOT

A Product that need to be built step by step plays one of core role of this pattern. The ConcreteBuilder holds the functionalities for creating each part and accumulate them into a specific Product. The AbstractBuilder should provide common behaviors that supports different ConcreteBuilders. Director is the one who constructs the Product with the help of the operations specified by the Builder.
In the GOF structure client is not specified explicitly but the client plays an important role which specifies how the internal relationship will be executed. Client takes the responsibility for selecting the particular ConcreteBuilder and sends it to the Director. So the Client knows the ConcreteBuilder, Product and the Director.

GOF STRUCTURE

Please view the GOF structure in dofactory.

MATCHING SCENARIO

To understand simply we can take the common House example specified for this pattern. House is the product that we need to build. The ConcreteBuilder holds the operation for creating part of the object. One such operation is the method for creating room (CreateRoom()). As you know the AbstractBuilder holds the abstract description (simply abstract CreateRoom() here) that mimics the ConcreteBuilder. Now comes the Director which actually constructs the object for House using the AbstractBuilder. Let us consider the Director is going to create 2 bedroom flat, then it calls the CreateRoom() method in the AbstractBuilder (builder.CreateRoom()) twice.
Ok now we concentrate on how this will be implemented. As specified earlier, Client creates an instance for the specific ConcreteBuilder. Usually that ConcreteBuilder instance will be passed as an argument to the method call to the Director which holds the construction process.

EXTENSIONS

It is clear that Client is the one who decides which ConcreteBuilder need to be called. Hence the Client obviously knows which Product will get created. So he calls the construction operation in the Director passing the ConcreteBuilder instance.
Here comes the rival. My friend wants to explain the extension of this pattern by specifying an additional point in the above scenario. In our scenario we discussed about a 2 bedroom flat. He meant to extend it with 3 bedroom flat.
I just tried to extend with builder pattern but then inferred that the 3 bedroom scenario (in addition to 2 bedroom) partially won't suit the intent.
Actually as per the Intent specified by GOF for Builder pattern, the construction of complex object need to be separated from its representation so that the same construction process can be used for different representations. In our case the construction process is meant for a 2 bedroom flat and so in order to extend that, we need to identify a scenario that fits the different representation for the same 2 bed room construction. Hence we decided to go with two different representations of the 2 bedroom flat,
1) ordinary flat - whose CreateRoom() will create wall of thickness 200mm with ceiling height 10ft 2) secured flat - whose CreateRoom() will create wall of thickness 500mm with ceiling height 16ft.
For this we simply need to add a new ConcreteBuilder for the secured flat which uses the same AbstractBuilder as before.
Fine, now let us shift our focus to the 3 bedroom flat. Whether this can't be done with builder pattern? Not like that, it can be. So only previously in this post I specified it as "partially won't suit". Just introduce a separate construction process in the Director for the 3 bedroom flat (CreateRoom() need to be called 3 times). Since the Client is the one who is going to call the Director and also he has the knowledge on ConcreteBuilder and the Product, he'll take care of it and have control over it.

SUMMARY

• Need to identify the parts for building the complex object and ConcreteBuilder should provide the basic operations for creating parts for a specific Product. 
• AbstractBuilder should be common so as to accommodate different ConcreteBuilders.
• Director will construct the object by calling the basic operations for creating the parts.
• Client will decide which ConcreteBuilder instance to be used and pass it as parameter to the operation in the Director. Also Client have the knowledge of which Product to be created.

REFERENCE

For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software
http://www.dofactory.com/Patterns/PatternBuilder.aspx

Abstract Factory Pattern

Abstract Factory Pattern

PLOT
Available are products AbstractProductA, AbstractProductB,….
 Each of the products encompasses different varieties such as ProductA1, ProductA2… for AbstractProductA and ProductB1, ProductB2… for AbstractProductB. These ProductA1, ProductA2 are referred to as related items.


AbstractFactory simply ensures the creation of products. ConcreteFactory decides which type of product instance need to be created. That is ConcreteFactory1 creates ProductA1 and ProductB1, similarly ConcreteFactory2 creates ProductA2 and ProductB2.


So the core is the client creates an instance of the ConcreteFactory (i.e., ConcreteFactory1 / ConcreteFactory2) which is responsible for the creation of product object from the related varieties of Products.


Thus the client is independent of the product got created. Also note that the Concrete subclass (ConcreteProduct) for the Product is not specified.

GOF STRUCTURE

IMPLEMENTATION IN .NET
While exploring about this pattern, though I understood the concepts clearly with some good examples, I expected a better scenario to stick determined on this pattern. At that time I came across an article that describes Abstract Factory with ADO.Net 2.0.
Namespace: System.Data.Common

Participants mapping
AbstractFactory : DbProviderFactory
ConcreteFactory : SqlClientFactory, OracleClientFactory, OleDbFactory,...
AbstractProduct : DbConnection, DbCommand, DbParameter,...
ConcreteProduct : SqlConnection, OracleConnection, SqlCommand,...

Snippet

    1     Dim factory As DbProviderFactory = DbProviderFactories.GetFactory("System.Data.SqlClient")

    2     Dim connection As DbConnection = Nothing

    3 

    4     connection = factory.CreateConnection()

Line 1 - Creates an instance for SqlClientFactory (ConcreteFactory) for "factory" object. Factory pattern is made use over there which we will discuss later.
Line 2 - Defines "connection" as DbConnection (AbstractProduct).
Line 4 - factory.CreateConnection() returns a new instance SqlConnection{System.Data.SqlClient.SqlConnection} for the specific provider SqlClient.

SUMMARY
Simply without specifying the ConcreteProduct - SqlConnection, the instance got created.

REFERENCE
For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software

Design Pattern

All my posts related to design pattern will follow the GOF ideologies. I'm just going to make a note on the things that got raised during my observation and discussion. Also here I want to make note of the scenarios specified in the sites other than GOF. I'm not going to explain the patterns as most of the things will seem to be the replica as described by the GOF.
To be aware of Design Patterns, I tried lot of articles / books though I'm aware of GOF. As I'm passionate about C#, I tried to read books / Articles that explains well about the GOF patterns with C#. DoFactory site fulfilled that partially. But later one of my friend strongly argued with me and presented me with the native GOF "Design Patterns - Elements of Reusable Object-Oriented Software" book and asked me to get into that.
Really that helps me a lot and the approach of the book wins. Each and every pattern is explained by means of:

• Intent
• Also Known As
• Motivation
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns

 

The key items that describes the core ideology of the pattern are the Intent and Structure. Motivation is specified before the Structure which will help us to understand the Structure.

Finally I agree with my friend that to understand about the GOF Design Patterns, definitely we should first need to go through "Design Patterns - Elements of Reusable Object-Oriented Software". Then we can refer other books, articles or blogs in order to fine-tune the knowledge we acquired and to become strong in that.