Sanjeetosphere : Software Design

Creational - Factory Pattern

Sanjeet — Sun, 02 Sep 2007 16:22:40 GMT

In continuation to my previous post, I am presenting you a sample code that implements Factory Pattern.

The overview:
- We are using the Person, Gift and Letter classes as we did in the Abstract Factory Pattern implementation. This is just to show how you can use the same scenario against different patterns.
- The abstract Person class is the Creator. Gift and Letter are Products.
- The concrete creator classes are Employee and Colleague. The concrete Product classes are: Email, Postal for Letter; Flowers, Perfume for Gift.
- The Creator has 2 abstract functions that create Products. the Concrete Classes override them to create different Products.
- You can create an Array of Concrete objects for the Creator class.

Takeaways:
- This pattern is particularly helpful in designing frameworks.
- The Creator relies on its subclasses to define the factory method to return the appropriate ConcreteProduct.
- There is no Client class.

The Creator Class:

   1: public abstract class Person   2:     {   3:         public abstract Gift CreateGift();   4:         public abstract Letter CreateLetter();   5:     }

The Concrete Classes:

   1: public class Employee: Person   2:     {   3:         public override Gift CreateGift()   4:         {   5:             return new Flowers();   6:         }   7:         public override Letter CreateLetter()   8:         {   9:             return new Email();  10:         }  11:     }  12:       13:     public class Colleague: Person  14:     {  15:         public override Gift CreateGift()  16:         {  17:             //throw new NotImplementedException();  18:             return new Perfume();  19:         }  20:    21:         public override Letter CreateLetter()  22:         {  23:             //throw new NotImplementedException();  24:             return new Postal();  25:         }  26:     }

The Products - Letter and Gift; Concrete Products Email, Postal, Flowers, and Perfume

   1: public abstract class Letter   2:     {   3:     }   4:        5:     public class Email: Letter   6:     {   7:         public Email()   8:         {   9:             Console.WriteLine("Email Created");  10:         }  11:     }  12:       13:     public class Postal: Letter  14:     {  15:         public Postal()  16:         {  17:             Console.WriteLine("Postal Created");  18:         }  19:     }  20:       21:     public abstract class Gift  22:     {          23:     }  24:       25:     public class Flowers: Gift  26:     {  27:         public Flowers()  28:         {  29:             Console.WriteLine("Flowers Created");  30:         }  31:     }  32:       33:     public class Perfume: Gift  34:     {  35:         public Perfume()  36:         {  37:             Console.WriteLine("Perfume Created");  38:         }  39:     }

The usage from within application:

   1: static void Main(string[] args)   2:         {   3:             Person[] people = new Person[2];   4:             people[0] = new Employee();   5:             people[1] = new Colleague();   6:                7:             foreach(Person person in people)   8:             {   9:                 Console.WriteLine(person.CreateGift());  10:                 person.CreateLetter();  11:             }  12:             Console.Read();  13:         }

Hope it helps. Do write to me in case of any question/suggestions.

Software Design Patterns - Creational Patterns

Sanjeet — Sun, 02 Sep 2007 15:07:55 GMT

This happens to be the first of my articles on Software Design Patterns. I will present some basics followed by implementation of the pattern.

These patterns help make a system independent of how its objects are created, composed and represented.
A class creational pattern uses inheritance to vary the class that’s instantiated, whereas the object creational pattern will delegate instantiation to another object.

In creational patterns emphasis shifts away from hard coding a fixed set of behaviors towards defining a smaller set of fundamental behaviors that can be composed into any number of more complex ones. Thus object composition becomes more important than class inheritance.
Some widely used patterns in this category are:

Abstract Factory
- The main purpose is to create objects for the product class.

- The break-up of classes involved is as follows:
> You need an abstract factory class which acts as a base to some concrete classes.
> You need an abstract product/entity class which will act as a base class for some fixed number of concrete product classes.
> A client, which always uses the interfaces declared by the abstract factory and product classes.
> The factory class is not abstract; it in fact uses the Singleton pattern to create only 1 instance. It is used by the product classes to create new instances.

- You can use this pattern in the following cases:
> A system is independent in terms of how its products are created, composed and represented.
> You want to provide a class library of things, and you don’t want to reveal the implementations but interfaces.
> The number of products is defined.

- Advantages:
> Concrete classes are isolated. Product class names are isolated in the implementation of the concrete factory.
> Product families can be changed easily.
> Promotes consistency among products.

- Disadvantages:
> Supporting new kinds of products is difficult. It requires you to change the abstract and concrete factory classes at number of places.

Factory
- This pattern defines an interface for creating an object, but let subclasses decide which class to instantiate.

- The break-up of the classes involved is as follows:
> You need a Product and a Creator
> Concrete classes for Product and Creator.
> Creator relies on its subclasses to define factory method so that it returns an instance of the appropriate Concrete Product.

- The following happens:
> You may create multiple Creator classes, and multiple Product classes.
> Each Creator has something like a Create() function that creates one/more Products.
> From a client, you create an array of Creator base abstract class. This array can have objects from any of the inherited Creator classes.
> The inherited Creator classes then create one/more Products for the client.

Builder
- This pattern is useful when you want to separate the construction of a complex object from its representation. This enables the same construction process to create different representations.
- It involves a Builder and a Director.
- Use this pattern if:
> You need to keep the algorithm of creating a complex object separate from the parts that make it up.
> The construction process must allow different representations for the object that’s constructed.

- The break-up of the classes involved are as follows:
> There is an abstract builder class for creating parts of a product object.
> You need a Concrete Builder class to construct and assemble parts of the product by implementing Builder.
> A Director class that constructs an object by using the Builder.
> The Product classes that represent the complex object under construction. They do not require an Abstract base class as their implementations have to be very different.

- The following happens:
> A client creates the Director object and configures it with the desired Builder object.
> Director notifies the Builder to build a Product. Builder then adds parts to the Product.
> The client retrieves the Product from the builder.

- Advantages:
> Director has no direct interaction with the Product so you can easily change/modify them.
> It isolates the code for construction and representation.
> This pattern constructs products step by step under Director’s control.

Creational - Abstract factory Pattern

Sanjeet — Sun, 02 Sep 2007 14:47:31 GMT

In continuation to my previous post, I am presenting you a sample code that implements Abstract Factory Pattern.

The overview:
- This implementation contains a factory called Person.
- The Product/Entity class is represented by 2 abstract classes called Gift and Letter.
- The client class is called Client.
- Employee and Colleague inherits from Person.
- Email inherits Letter and Flowers inherit Gift.
- Client creates/receives an instance of Person class which creates objects for Gift and Letter.

Takeaways:
- As discussed earlier, Creational Patterns focus on creating objects of Product.
- The complexity of this pattern increases as the number of Product increases. You have to add more virtual functions at the Person(Factory) level. Then override those functions at the Concrete classes of the Factory(eg., Employee, Colleague)

The Person class(Factory), this implementation uses the Singleton pattern with Lazy Initialization to make sure that there is only 1 instance in the application.

   1: public class Person   2:     {   3:         /// <summary>   4:         /// Static variable of the class to see if its already instantiated   5:         /// </summary>   6:         private static Person _p;         7:     8:         /// <summary>   9:         /// The virual functions to create a Gift Product  10:         /// </summary>  11:         /// <returns></returns>  12:         public virtual Gift CreateGift()  13:         {  14:             return new Flowers();  15:         }  16:           17:         /// <summary>  18:         /// The virual functions to create a Letter Product  19:         /// </summary>  20:         /// <returns></returns>  21:         public virtual Letter CreateLetter()  22:         {  23:             return new Email();  24:         }  25:           26:         /// <summary>  27:         /// This static method gets you the single instance of this class  28:         /// </summary>  29:         /// <returns></returns>  30:         public static Person GetInstance()  31:         {  32:             if (_p == null)  33:             {  34:                 _p = new Person();  35:             }  36:             return _p;  37:         }  38:           39:         /// <summary>  40:         /// Constructor with restricted access  41:         /// </summary>  42:         protected Person(){  43:         }          44:     }

The Employee Concrete Class:

   1: /// <summary>   2:     /// This is one of the Concrete classes which isolated from the client   3:     /// </summary>   4:     public class Employee: Person   5:     {   6:         /// <summary>   7:         /// Constructor to the class   8:         /// </summary>   9:         public Employee():base()  10:         {  11:               12:         }  13:    14:         /// <summary>  15:         /// Override the virtual declared in the base class.  16:         /// This function creates and returns one of the products - Flowers  17:         /// </summary>  18:         /// <returns></returns>  19:         public override Gift CreateGift()  20:         {  21:             return new Flowers();  22:         }  23:    24:         /// <summary>  25:         /// Override the virtual declared in the base class.  26:         /// This function creates and returns one of the products - Email  27:         /// </summary>  28:         /// <returns></returns>  29:         public override Letter CreateLetter()  30:         {  31:             return new Email();  32:         }  33:     }

The Colleague Concrete Class:

   1: /// <summary>   2:     /// This is one of the Concrete classes which isolated from the client   3:     /// </summary>   4:     public class Colleague: Person   5:     {   6:         /// <summary>   7:         /// Constructor to the class   8:         /// </summary>   9:         public Colleague():base()  10:         {  11:         }  12:    13:         /// <summary>  14:         /// Override the virtual declared in the base class.  15:         /// This function creates and returns one of the products - Flowers  16:         /// </summary>  17:         /// <returns></returns>  18:         public override Gift CreateGift()  19:         {  20:             return new Flowers();  21:         }  22:    23:         /// <summary>  24:         /// Override the virtual declared in the base class.  25:         /// This function creates and returns one of the products - Email  26:         /// </summary>  27:         /// <returns></returns>  28:         public override Letter CreateLetter()  29:         {  30:             return new Email();  31:         }  32:     }

The Gift and Letter Abstract Product Classes:

   1: /// <summary>   2:     /// This is the Product type #1   3:     /// </summary>   4:     public abstract class Gift   5:     {    6:         protected string _name;   7:            8:         public virtual string Name   9:         {  10:             get;set;  11:         }  12:                13:         public Gift()  14:         {  15:             _name = "Gift Constructor";          16:         }          17:     }   18:    19: /// <summary>  20:     /// This is the Product type #2  21:     /// </summary>  22:     public abstract class Letter  23:     {  24:         protected string _purpose;  25:                   26:         public Letter()  27:         {  28:             _purpose = "Letter Constructor";  29:         }  30:    31:         public virtual string Purpose  32:         {  33:             get;  34:             set;  35:         }  36:     }

The Products - Email and Flowers:

   1: /// <summary>   2:     /// This is product #1 of product type #1   3:     /// </summary>   4:     public class Flowers: Gift   5:     {   6:         public Flowers()   7:         {   8:             _name = "Flowers Constructor";   9:         }  10:           11:         public override string Name  12:         {  13:             get  14:             {  15:                 return _name;  16:             }  17:             set  18:             {  19:                 _name = value;  20:             }  21:         }        22:     }  23:    24: /// <summary>  25:     /// This is product #1 of product type #2  26:     /// </summary>  27:     public class Email: Letter  28:     {  29:       30:         public Email()  31:         {  32:             _purpose = "Email Constructor";  33:         }  34:         public override string Purpose  35:         {  36:             get  37:             {  38:                 return _purpose;  39:             }  40:             set  41:             {  42:                 _purpose = value;  43:             }  44:         }  45:     }

Please write to me if you have any questions/suggestions.