Abstract Factory Design Pattern - C#

Abstract Factory method pattern falls under Creational Pattern of Gang of Four (GOF) Design Patterns in .Net. It is used to create a set of related objects, or dependent objects. Internally, Abstract Factory use Factory design pattern for creating objects. It may also use Builder design pattern and prototype design pattern for creating objects. It completely depends upon your implementation for creating objects. In this article, I would like share what is abstract factory pattern and how is it work?

What is Abstract Factory Pattern?

Abstract Factory patterns acts a super-factory which creates other factories. This pattern is also called as Factory of factories. In Abstract Factory pattern an interface is responsible for creating a set of related objects, or dependent objects without specifying their concrete classes.

Abstract Factory Pattern - UML Diagram & Implementation

The UML class diagram for the implementation of the abstract factory design pattern is given below:

The classes, interfaces and objects in the above UML class diagram are as follows:

1. AbstractFactory

   This is an interface which is used to create abstract product

2. ConcreteFactory

   This is a class which implements the AbstractFactory interface to create concrete products.

3. AbstractProduct

   This is an interface which declares a type of product.

4. ConcreteProduct

   This is a class which implements the AbstractProduct interface to create product.

5. Client

   This is a class which use AbstractFactory and AbstractProduct interfaces to create a family of related objects.

C# - Implementation Code

public interface AbstractFactory
{
 AbstractProductA CreateProductA();
 
 AbstractProductB CreateProductB();
}
 
public class ConcreteFactoryA : AbstractFactory
{
 public AbstractProductA CreateProductA()
 {
 return new ProductA1();
 }
 
 public AbstractProductB CreateProductB()
 {
 return new ProductB1();
 }
}
 
public class ConcreteFactoryB : AbstractFactory
{
 public AbstractProductA CreateProductA()
 {
 return new ProductA2();
 }
 
 public AbstractProductB CreateProductB()
 {
 return new ProductB2();
 }
}
 
public interface AbstractProductA { }
 
public class ProductA1 : AbstractProductA { }
 
public class ProductA2 : AbstractProductA { }
 
public interface AbstractProductB { }
 
public class ProductB1 : AbstractProductB { }
 
public class ProductB2 : AbstractProductB { }
 
public class Client
{
 private AbstractProductA _productA;
 private AbstractProductB _productB;
 
 public Client(AbstractFactory factory)
 {
 _productA = factory.CreateProductA();
 _productB = factory.CreateProductB();
 }
}

Abstract Factory Pattern - Example

 

Who is what?

The classes, interfaces and objects in the above class diagram can be identified as follows:

1. VehicleFactory - AbstractFactory interface
2. HondaFactory & HeroFactory- Concrete Factories
3. Bike & Scooter - AbstractProduct interface
4. Regular Bike, Sports Bike, Regular Scooter & Scooty - Concreate Products
5. VehicleClient - Client

C# - Sample Code

/// <summary>
/// The 'AbstractFactory' interface. 
/// </summary>
interface VehicleFactory
{
 Bike GetBike(string Bike);
 Scooter GetScooter(string Scooter);
}
 
/// <summary>
/// The 'ConcreteFactory1' class.
/// </summary>
class HondaFactory : VehicleFactory
{
 public Bike GetBike(string Bike)
 {
 switch (Bike)
 {
 case "Sports":
 return new SportsBike();
 case "Regular":
 return new RegularBike();
 default:
 throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", Bike));
 }
 
 }
 
 public Scooter GetScooter(string Scooter)
 {
 switch (Scooter)
 {
 case "Sports":
 return new Scooty();
 case "Regular":
 return new RegularScooter();
 default:
 throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", Scooter));
 }
 
 }
}
 
/// <summary>
/// The 'ConcreteFactory2' class.
/// </summary>
class HeroFactory : VehicleFactory
{
 public Bike GetBike(string Bike)
 {
 switch (Bike)
 {
 case "Sports":
 return new SportsBike();
 case "Regular":
 return new RegularBike();
 default:
 throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", Bike));
 }
 
 }
 
 public Scooter GetScooter(string Scooter)
 {
 switch (Scooter)
 {
 case "Sports":
 return new Scooty();
 case "Regular":
 return new RegularScooter();
 default:
 throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", Scooter));
 }
 
 }
}
 
/// <summary>
/// The 'AbstractProductA' interface
/// </summary>
interface Bike
{
 string Name();
}
 
/// <summary>
/// The 'AbstractProductB' interface
/// </summary>
interface Scooter
{
 string Name();
}
 
/// <summary>
/// The 'ProductA1' class
/// </summary>
class RegularBike : Bike
{
 public string Name()
 {
 return "Regular Bike- Name";
 }
}
 
/// <summary>
/// The 'ProductA2' class
/// </summary>
class SportsBike : Bike
{
 public string Name()
 {
 return "Sports Bike- Name";
 }
}
 
/// <summary>
/// The 'ProductB1' class
/// </summary>
class RegularScooter : Scooter
{
 public string Name()
 {
 return "Regular Scooter- Name";
 }
}
 
/// <summary>
/// The 'ProductB2' class
/// </summary>
class Scooty : Scooter
{
 public string Name()
 {
 return "Scooty- Name";
 }
}
 
/// <summary>
/// The 'Client' class 
/// </summary>
class VehicleClient
{
 Bike bike;
 Scooter scooter;
 
 public VehicleClient(VehicleFactory factory, string type)
 {
 bike = factory.GetBike(type);
 scooter = factory.GetScooter(type);
 }
 
 public string GetBikeName()
 {
 return bike.Name();
 }
 
 public string GetScooterName()
 {
 return scooter.Name();
 }
 
}
 
/// <summary>
/// Abstract Factory Pattern Demo
/// </summary>
class Program
{
 static void Main(string[] args)
 {
 VehicleFactory honda = new HondaFactory();
 VehicleClient hondaclient = new VehicleClient(honda, "Regular");
 
 Console.WriteLine("******* Honda **********");
 Console.WriteLine(hondaclient.GetBikeName());
 Console.WriteLine(hondaclient.GetScooterName());
 
 hondaclient = new VehicleClient(honda, "Sports");
 Console.WriteLine(hondaclient.GetBikeName());
 Console.WriteLine(hondaclient.GetScooterName());
 
 VehicleFactory hero = new HeroFactory();
 VehicleClient heroclient = new VehicleClient(hero, "Regular");
 
 Console.WriteLine("******* Hero **********");
 Console.WriteLine(heroclient.GetBikeName());
 Console.WriteLine(heroclient.GetScooterName());
 
 heroclient = new VehicleClient(hero, "Sports");
 Console.WriteLine(heroclient.GetBikeName());
 Console.WriteLine(heroclient.GetScooterName());
 
 Console.ReadKey();
 }
}

Abstract Factory Pattern Demo - Output

When to use it?

1. Create a set of related objects, or dependent objects which must be used together.
2. System should be configured to work with multiple families of products.
3. The creation of objects should be independent from the utilizing system.
4. Concrete classes should be decoupled from clients.

Note

1. Internally, Abstract Factory use Factory design pattern for creating objects. But it can also use Builder design pattern and prototype design pattern for creating objects. It completely depends upon your implementation for creating objects.
2. Abstract Factory can be used as an alternative to Facade to hide platform-specific classes.
3. When Abstract Factory, Builder, and Prototype define a factory for creating the objects, we should consider the following points :
   
   1. Abstract Factory use the factory for creating objects of several classes.
   2. Builder use the factory for creating a complex object by using simple objects and a step by step approach.
   3. Prototype use the factory for building a object by copying an existing object.

What do you think?

I hope you will enjoy the Abstract Factory Pattern while designing your software. I would like to have feedback from my blog readers. Your valuable feedback, question, or comments about this article are always welcome.

Factory Method Design Pattern - C#

The factory method design pattern abstract the process of object creation and allows the object to be created at run-time when it is required. Factory method pattern falls under Creational Pattern of Gang of Four (GOF) Design Patterns in .Net. It is used to create objects. People usually use this pattern as the standard way to create objects. In this article, I would like to share what is factory pattern and how it works?

What is Factory Method Pattern?

In Factory pattern, we create the object without exposing the creation logic. In this pattern, an interface is used for creating an object, but let subclass decide which class to instantiate. The creation of object is done when it is required. The Factory method allows a class later instantiation to subclasses.
In short, factory method design pattern abstract the process of object creation and allows the object to be created at run-time when it is required.

Factory Method Pattern - UML Diagram & Implementation

The UML class diagram for the implementation of the factory method design pattern is given below: 

 

The classes, interfaces and objects in the above UML class diagram are as follows:

1. Product

   This is an interface for creating the objects.

2. ConcreteProduct

   This is a class which implements the Product interface.

3. Creator

   This is an abstract class and declares the factory method, which returns an object of type Product.

4. ConcreteCreator

   This is a class which implements the Creator class and overrides the factory method to return an instance of a ConcreteProduct.

C# - Implementation Code

interface Product
{
 
}
 
class ConcreteProductA : Product
{
}
 
class ConcreteProductB : Product
{
}
 
abstract class Creator
{
 public abstract Product FactoryMethod(string type);
}
 
class ConcreteCreator : Creator
{
 public override Product FactoryMethod(string type)
 {
 switch (type)
 {
 case "A": return new ConcreteProductA();
 case "B": return new ConcreteProductB();
 default: throw new ArgumentException("Invalid type", "type");
 }
 }
}

Factory Method Pattern - Example

 

Who is what?

The classes, interfaces and objects in the above class diagram can be identified as follows:

1. IFactory - Interface
2. Scooter & Bike - Concreate Product classes
3. VehicleFactory - Creator
4. ConcreteVehicleFactory - Concreate Creator

C# - Sample Code

using System;
namespace Factory
{
 /// <summary>
 /// The 'Product' interface
 /// </summary>
 public interface IFactory
 {
 void Drive(int miles);
 }
 
 /// <summary>
 /// A 'ConcreteProduct' class
 /// </summary>
 public class Scooter : IFactory
 {
 public void Drive(int miles)
 {
 Console.WriteLine("Drive the Scooter : " + miles.ToString() + "km");
 }
 }
 
 /// <summary>
 /// A 'ConcreteProduct' class
 /// </summary>
 public class Bike : IFactory
 {
 public void Drive(int miles)
 {
 Console.WriteLine("Drive the Bike : " + miles.ToString() + "km");
 }
 }
 
 /// <summary>
 /// The Creator Abstract Class
 /// </summary>
 public abstract class VehicleFactory
 {
 public abstract IFactory GetVehicle(string Vehicle);
 
 }
 
 /// <summary>
 /// A 'ConcreteCreator' class
 /// </summary>
 public class ConcreteVehicleFactory : VehicleFactory
 {
 public override IFactory GetVehicle(string Vehicle)
 {
 switch (Vehicle)
 {
 case "Scooter":
 return new Scooter();
 case "Bike":
 return new Bike();
 default:
 throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", Vehicle));
 }
 }
 
 }
 
 /// <summary>
 /// Factory Pattern Demo
 /// </summary>
 class Program
 {
 static void Main(string[] args)
 {
 VehicleFactory factory = new ConcreteVehicleFactory();
 
 IFactory scooter = factory.GetVehicle("Scooter");
 scooter.Drive(10);
 
 IFactory bike = factory.GetVehicle("Bike");
 bike.Drive(20);
 
 Console.ReadKey();
 
 }
 }
}

Factory Pattern Demo - Output

When to use it?

1. Subclasses figure out what objects should be created.
2. Parent class allows later instantiation to subclasses means the creation of object is done when it is required.
3. The process of objects creation is required to centralize within the application.
4. A class (creator) will not know what classes it will be required to create.

What do you think?

I hope you will enjoy the Factory Method Pattern while designing your software. I would like to have feedback from my blog readers. Your valuable feedback, question, or comments about this article are always welcome.

Gang of Four (GOF) Design Patterns in .NET

In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book (Design Patterns: Elements of Reusable Object-Oriented Software) for explaining the concept of Design Pattern in Software development. These four authors are collectively known as Gang of Four (GOF).

GOF Design Patterns

The 23 Design patterns are defined by the Gang of Four programmers. These 23 patterns are divided into three groups depending on the nature of the design problem they intend to solve.

1. Creational Design Patterns

   These patterns deal with the process of objects creation in such a way that they can be decoupled from their implementing system. This provides more flexibility in deciding which objects need to be created for a given use case/ scenario. There are as follows:
   
   1. Factory Method : Create instances of derived classes
   2. Abstract Factory : Create instances of several classes belonging to different families
   3. Builder : Separates an object construction from its representation
   4. Prototype : Create a duplicate object or clone of the object
   5. Singleton : Ensures that a class can has only one instance

2. Structural Design Patterns

   These patterns deal with the composition of objects structures. The concept of inheritance is used to compose interfaces and define various ways to compose objects for obtaining new functionalities. There are as follows:
   
   1. Adapter : Match interfaces of different classes
   2. Bridge : Separates an object’s abstraction from its implementation
   3. Composite : A tree structure of simple and composite objects
   4. Decorator : Add responsibilities to objects dynamically
   5. Façade : A single class that represents an entire complex system
   6. Flyweight : Minimize memory usage by sharing as much data as possible with similar objects
   7. Proxy : Provides a surrogate object, which references to other object

3. Behavioral Design Patterns

   These patterns deal with the process of communication, managing relationships, and responsibilities between objects. There are as follows:
   
   1. Chain of Responsibility: Passes a request among a list or chain of objects.
   2. Command: Wraps a request under an object as a command and passed to invoker object.
   3. Interpreter: Implements an expression interface to interpret a particular context.
   4. Iterator: Provides a way to access the elements of a collection object in sequential manner without knowing its underlying structure.
   5. Mediator: Allows multiple objects to communicate with each other’s without knowing each other’s structure.
   6. Memento: Capture the current state of an object and store it in such a manner that it can be restored at a later time without breaking the rules of encapsulation.
   7. Observer: Allows an object (subject) to publish changes to its state and other objects (observer) that depend upon that object are automatically notified of any changes to the subject's state.
   8. State: Alters the behavior of an object when it’s internal state changes.
   9. Strategy: Allows a client to choose an algorithm from a family of algorithms at run-time and gives it a simple way to access it.
   10. Visitor: Creates and performs new operations onto a set of objects without changing the object structure or classes.
   11. Template Method: Defines the basic steps of an algorithm and allow the implementation of the individual steps to be changed.

What do you think?

I hope you will enjoy the GOF design patterns while designing your software. I would like to have feedback from my blog readers. Your valuable feedback, question, or comments about this article are always welcome.

Different Types of Design Patterns

Design patterns provide solutions to common problems which occur in software design. Design patterns are about reusable designs and interactions of objects.

Types of Design Patterns

These can be organized in 4 separate pattern groups depending on the nature of the design problem they intend to solve.

1. Gang of Four Patterns
2. Enterprise Patterns
3. SOA and Messaging Patterns
4. Model-View Patterns

Advantages of Design Patterns

Design Patterns have following main advantages in software development.

1. Provide solutions to common problems which occur in software design.
2. Provide common platform for developers means developer can implement these in any language.
3. Provide a standard terminology and are specific to particular scenario.

What do you think?

I hope you will enjoy the design patterns while designing your software. I would like to have feedback from my blog readers. Your valuable feedback, question, or comments about this article are always welcome.

Different Types of Software Design Principles

Software design principles are a set of guidelines that helps developers to make a good system design. The most important principle is SOLID principle. The key software design principles are as:

1. SOILD

   It is combination of five basic designing principles.
   

   1. Single Responsibility Principle (SRP)

      This principle states that there should never be more than one reason for a class to change. This means that you should design your classes in such a way that each class should have a single purpose.
      Example - An Account class is responsible for managing Current and Saving Account but a CurrentAccount and a SavingAccount classes would be responsible for managing current and saving accounts respectively. Hence both are responsible for single purpose only. Hence we are moving towards specialization.
      

   2. Open/Closed Principle (OCP)

      This principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. The "closed" part of the rule states that once a module has been developed and tested, the code should only be changed to correct bugs. The "open" part says that you should be able to extend existing code in order to introduce new functionality.
      Example – A PaymentGateway base class contains all basic payment related properties and methods. This class can be extended by different PaymentGateway classes for different payment gateway vendors to achieve theirs functionalities. Hence it is open for extension but closed for modification.
      

   3. Liscov Substitution Principle (LSP)

      This principle states that functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
      Example - Assume that you have an inheritance hierarchy with Person and Student. Wherever you can use Person, you should also be able to use a Student, because Student is a subclass of Person.
      

   4. Interface Segregation Principle (ISP)

      This principle states that Clients should not be forced to depend upon interfaces that they don’t use. This means the number of members in the interface that is visible to the dependent class should be minimized.
      Example - The service interface that is exposed to the client should contains only client related methods not all.
      

   5. Dependency Inversion Principle (DIP)

      The Dependency Inversion Principle states that:
      
      1. High level modules should not depend upon low level modules. Both should depend upon abstractions.
      2. Abstractions should not depend upon details. Details should depend upon abstractions.
      It helps us to develop loosely couple code by ensuring that high-level modules depend on abstractions rather than concrete implementations of lower-level modules. The Dependency Injection pattern is an implementation of this principle
      Example - The Dependency Injection pattern is an implementation of this principle
      

2. DRY (Don’t Repeat Yourself)

   This principle states that each small pieces of knowledge (code) may only occur exactly once in the entire system. This helps us to write scalable, maintainable and reusable code.
   Example – Asp.Net MVC framework works on this principle.
   

3. KISS (Keep it simple, Stupid!)

   This principle states that try to keep each small piece of software simple and unnecessary complexity should be avoided. This helps us to write easy maintainable code.
   

4. YAGNI (You ain't gonna need it)

   This principle states that always implement things when you actually need them never implements things before you need them.
   

What do you think?

I hope you will enjoy the design principles while designing your application. I would like to have feedback from my blog readers. Your valuable feedback, question, or comments about this article are always welcome.