Regulator / FlowControlManager Pattern

Regulator is the object which holds the responsibility of managing the control flow between group of related objects by handling the state change of the objects and passing messages between them.

Components

Regulator / FowControlManager : Holds the instances of related objects (Colleagues) and observes the Colleagues for change in their state.
 Colleague : Ability to notify the change in its state and focuses on its core responsibility. Wont hold reference to any of related objects or Regulator.

Scenario

Consideration : Silverlight application following MVVM.
Generally in Silverlight applications we use to separate the application into individual modules in order to create seperate XAP files and download to use it as and when needed. Let us imagine such a small module which has a landing page displaying some details along with few links(Detail1,Detail2). Upon clicking the links, the respective views(DetailView1, DetailView2) need to be displayed on the desiered location on the landing page itself. Also different messages need to be sent to different views based on the behavior and actions performed in other views and landing page.

Simply we can handle this by hand over the entire responsibility to the ViewModel of the landing page. If we do so, the landing ViewModel need to hold this control flow management and message passing mechanism in addition to its functionality.

Instead if we have an object that manages the flow control and message passing, then the respective ViewModels can just concentrate on their functionality without bothering about flow of control and message passing.

If Detail1 link is clicked on the landing page, Regulator takes this responsibility by observing Detail1 link got clicked on landing page, pass required details to the DetailView1.ViewModel and passes the DetailView1 to the LandingPage.

Component Responsibility

Colleagues just notifies about change of state which need to be observed.Regulator observes the state changes of the Colleagues as it holds their instances, passes the needed messages to respective instances and controls the flow.
State change can be notified through effective use of events and NotifyPropertyChanged mechanism we use in Silverlight.

Related patterns

Most of you might have already smelled the flavour of Mediator, Observer and Facade pattern.
Its true but the notion differs.
Unlike Mediator pattern, Colleagues in Regulator pattern won't hold reference to Regulator instance. Regulator itself subscribes to required state change notification of Colleagues.

Edit
10JAN2011
My friend upon having a glimpse at the title asked me where did I got the title from? Actually I should have specified about this at time of writing the article itself. I just named it based on the functionality and nature of implementation. Just thinking whether I've done anything unlawful.

Factory Method - Pattern

INTRO

Factory pattern - Here comes the most commonly quoted pattern Factory method (next to Singleton Pattern). Factory method is frequntly used in lot of real time scenarios especially in the framework libraries. While developing a reusable library which contains core/base implementation, there are times where we need to work with or maintain the relationship between objects which will be created later during the implentation of those libraries. I've discussed one such case below under the Implementation in .Net.

Ultimate aim is to create a Product object and work on it which will be available some time later (as specified above). The name Factory resembles the real-world factory since it holds the responsibility of creating the objects (Products). Simply speaking the Client uses the Factory method to create a specific type of Product.

PLOT

Creator is the one who provides the interface for creating an object by holding the Factory method with him.
Factory method in the Creator returns a specific type of object Product.
Creator delegates the responsibility of "which class to be instantiated" to its subclass ConcreteCreator.
ConcreteCreator overrides the Factory method and it is responsible for creating the ConcreteProduct that adheres to the Product type. 

 GOF STRUCTURE

IMPLEMENTATION IN .NET

IEnumerable interface in .Net exposes a Factory method GetEnumerator(). The collection classes in .Net implements this IEnumerable interface to incur enumerator for a collection. Since foreach statement evaluates the type that implements IEnumerable, most of the collection classes will make use of this IEnumerable. ArrayList, HashTable, List,Dictionary are some of the examples.

IEnumerable needs to work on object of type IEnumerator, for iterating over the collection. Object of type IEnumerator knows how to iterate over the collection object of type IEnumerable.

ArrayList implements the IEnumerable and overrides the GetEnumerator method to create the object of ArrayListEnumeratorSimple which implements the IEnumerator.

Participants mapping

Creator : IEnumerable
ConcreteCreator : ArrayList
ConcreteProduct : ArrayListEnumeratorSimple
Product : IEnumerator

SUMMARY

I've just focussed on the case of delegating the responsibility of creating the instances to the subclass. There are also cases where the factory method in the ConcreteCreator defines the default instantiation and parameterized Factory methods used to identify and create specific ConcreteProduct.

REFERENCE

For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software
http://msdn.microsoft.com/en-us/magazine/cc188707.aspx#S5
http://ondotnet.com/pub/a/dotnet/2003/08/11/factorypattern.html
http://msdn.microsoft.com/en-us/library/ee817667.aspx

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