Design Patterns
Design patterns are reusable solutions to recurring problems of software design and engineering in the real-world. Patterns makes it easier to reuse proven techniques to resolve design and architectural complications and then communicating and documenting them with better understanding, making them more accessible to developers in an abstract way.
Design patterns enhance the classic techniques of object oriented programming by encouraging the reusability and communication of the solutions of common problems at abstract levels and improves the maintainability of the code as a by-product at implementation levels.
The “Y” in Design Patterns
Apart from the obvious advantage of providing better techniques to map real-world into programming models, a prime objective of OOP is design and code reusability. However, this is easier said than done. In reality, designing reusable classes is hard and takes time. In the real-world, less than few devs write code with long-term reusability in mind. This becomes obvious when dealing with recurring problems in design and implementation. This is where design patterns come in to the picture, when dealing with problems that seems to appear again and again. Any proven technique that provides a solution of a recurring problem in an abstract, reusable way, independent of the implementation barriers like programming language details and data structures, is categorised as design pattern.
The design patterns:
- help analysing common problems in a more abstract way.
- provides proven solutions to those problems.
- help decreasing the overall code time at the implementation level.
- encourages the code reusability by providing common solutions.
- increases code lifetime and maintainability by enhancing the capacity of change.
- Increases the understanding of the solutions of recurring problems.
A pattern will describe a problem, provide its solution at an abstract level, and elaborate the result.
Problem
The problem part of a pattern describes the issue(s) a program/ piece of code is facing along with its context. It might highlight a class structure to be inflexible, or issues related to the usage of an object, particularly at runtime.
Solution
A solution is always defined as a template, an abstract design that will describe its element(s), their relationships, and responsibilities and will detail out how this abstract design will address the problem at hand. A pattern never provides any concrete implementation of the solution, enhancing its reusability and flexibility. The actual implementation of a pattern might vary in different programming languages.
Understanding software design patterns requires respectable knowledge of object oriented programming concepts like abstraction, inheritance, and polymorphic behaviour.
Types of Design Patterns
Design patterns are often divided into three fundamental types.
- Creational – deals with the creation/ instantiation of objects specific to business use cases. Polymorphic concepts, along with inheritance, are the core of these patterns.
- Structural – targets the structure and composition of classes. Heavily relies upon the inheritance and composition concepts of OOP.
- Behavioural – underlines the interaction between classes, separation and delegation of responsibilities.
Creational Patterns
Often the implementation and usage of a class, or a group of classes is tightly coupled with the way objects of those classes are created. This decreases the flexibility of those classes, particularly at runtime. For example, if we have a group of cars providing a functionality of driving. Then the creation of each car will require a piece of code; new constructor in common modern languages. This will infuse the creation of cars with its usage:
Holden car1 = new Holden();
car1.Drive();
Mazda car2 = new Mazda();
car2.Drive();
…
Even if we use base type;
Car car1 = new Holden();
car1.Drive();
Car car2 = new Mazda();
car2.Drive();
…
If you look at the above examples, you will notice that the actual class being instantiated is selected at compile-time. This creates problems when designing common functionality and forces hardwired code into the usage based on concrete types. This also exposes the constructors of the classes which penetrates the encapsulation.
Creational patterns provide the means of creating, and using objects of related classes without having to identify their concrete types or exposing their creational mechanism. This gives move flexibility at the usage of the instantiated objects at runtime without worrying about their types. This also results in less code and eliminates the creational complexity at the usage, allowing the code to focus on what to do then what to create.
CarFactory[] factories = <Create factories>;
foreach (CarFactory factory in factories) {
Car car = factory.CreateCar();
car.Drive();
}
The above code removes the creational logic and dedicates it to subclasses and factories. This gives flexibility on usage of classes independent of its creation and let the runtime dictates the instantiated types while making the code independent of the number of concrete types (cars) to be used. This code will work regardless of the number concrete types, enhancing the reusability and separation of creation from its usage. We will discuss the above example in details in Factory Method pattern.
The two common trades of creational patterns are:
- Encapsulation of concrete types and exposure using common abstractions.
- Encapsulation of instantiation and encouraging polymorphic behaviour.
The system leveraging creational patterns does not need to know, or understand concrete types; it handles abstractions only (interfaces, abstract classes). This gives flexibility in configuring a set of related classes at runtime, based on use cases and requirements without having to alter the code.
There are five fundamental creational patterns:
- Factory method
- Abstract factory
- Prototype
- Singleton
- Builder
Factory Method
This pattern specifies a way of creating instances of related classes but let the subclasses decide which concrete type to instantiate at runtime, also called Virtual Construction. The pattern encourages the use of interfaces and abstract classes over concrete types. The decision is based upon the input supplied by either the client code or configuration.
Reasons
When client code instantiates a class, it knows the concrete type of that class. This breaks through the polymorphic abstraction when dealing with a family of classes. We may use factory method when:
- Client code don’t know the concrete types of subclasses to create.
- The instantiation needs to be deferred to subclasses.
- The job needs to be delegated to subclasses and client code does not need to know which subclass is doing the job.
Components
Abstract <Product> (Car)
The interface/ abstraction the client code understands. This describes the family of subclasses to be instantiated.
<Product> (Holden, Mazda, …)
This implements the abstract <product>. The subclass(es) that needs to be created.
Abstract Factory (CarFactory)
This provides the interface/ abstraction for the creation of abstract product, called factory method. This might also use configuration for creating a default product.
ConcreteFactory (HoldenFactory, MazdaFactory, …)
This provides the instantiation of the concrete subclass/ product by implementing the factory method.
Sample code
Going back to our example of cars earlier, we will provide detail implementation of the factory method.
public abstract class Car //could be an interface instead, if no default behaviour is required
{
public virtual void Drive()
{
Console.Write(“Driving a car”);
}
}
public class Holden : Car
{
public override void Drive()
{
Console.Write(“Driving Holder”);
}
}
public class Mazda : Car
{
public override void Drive()
{
Console.Write(“Driving Mazda”);
}
}
public interface ICarFactory //This will be a class/ abstract if there is a default factory implementation.
{
Car CreateCar();
}
public class HoldenFactory : CarFactory
{
public Car CreateCar()
{
return new Holden();
}
}
public class MazdaFactory : CarFactory
{
public Car CreateCar()
{
return new Mazda();
}
}
Now the client code could be:
var factories = new CarFactory[2];
factories[0] = new HoldenFactory();
factories[1] = new MazdaFactory();
foreach (var factory in factories)
{
var car = factory.CreateCar();
car.Drive();
}
Now we can keep introducing new Car types and the client code will behave the same way for this use case. The creation of factories could further be abstracted by using parametrised factory method. This will modify the CarFactory interface.
public class CarFactory
{
public virtual Car CreateCar(string type) //any configuration or input from client code.
{
/////switches based on the configuration or input from client code
if (type == “holden”)
return new Holden();
else if (type == “mazda”)
return new Mazda();
//…
else ////default instantiation/ fault condition etc.
return null; //default/ throw etc.
}
}
Which will change the client code:
CarFactory factory = new CarFactory();
Car car1 = factory.CreateCar(“holdern”); //Configuration/ input etc.
Car car2 = factory.CreateCar(“mazda”); //Configuration/ input etc.
The above code shows the flexibility of the factory method, particularly the Factory class.
Advantages
Factory method is the simplest of the creational patterns that targets the creation of a family of classes.
- It separates the client code and a family of classes by weakening the coupling and abstracting the concrete subclasses.
- It reduces the changes in client code due to changes in concrete types.
- Provides configuration mechanism for subclasses by removing their instantiation from the client code and into the factory method(s).
- The default constructors of the subclasses could be marked protected/ private to shield direct creation.
Drawbacks
There are some disadvantages that should be considered before applying factory method:
- Factory demands individual implementations of a factory method for every subclass in the family. This might introduce unnecessary complexity.
- Concrete parametrised factory leverages the switch conditions to identify the concrete type to be instantiated. This introduces cluttered and hardwired code in the factory. Any changes in the configuration/ client code input or implementation changes of the concrete types demands a review of the factory method.
- The subtypes must be of the same base type. Factory method cannot handle subtypes of different base types. That will require complex creational patterns.
Conclusion
Factory method is simple to understand and implement in a variety of languages. The most important consideration is to look for many subclasses of the same base type/ interface and being handled at that abstract level in a system. Conditions like below could warrant a factory method implementation.
Car car1 = new Holder();
car1.GetDiscount();
Car car2 = new Mazda();
car2.GetDiscount();
. . .
On the other hand, if you have some concrete usage of subclasses like.
if (car.GetType() == typeof(Holden))
((Holden)car).GetHoldenDiscount();
Then factory method might not be the answer and, perhaps reconsider the class hierarchy.
In part 2, we will discuss the next Creational Pattern, that is considered a superset of factory method, Abstract Factory.
Further Reading
https://msdn.microsoft.com/en-us/library/orm-9780596527730-01-05.aspx
http://www.oodesign.com/abstract-factory-pattern.html
http://www.dofactory.com/net/factory-method-design-pattern