5 minutes guide to some commonly used Design Patterns

After a few messages to my LI profile regarding the commonly used Design Patterns, and how to identify the problem, I have collated a very quick 10 minute write up based on my experience for using various Design Patterns in your programs.

1. Strategy Design Pattern: - Used for replicating various subsets of similar functionality that implement a same interface (contract), so that the concrete child objects can be interchangeably plugged into the same code at run time. Makes it easier to create new child classes without affecting the plumbing code using those classes, as long as all the classes are following the same interface/abstract class/contract.

Ex. Different Types of Buttons in windows/web, Different types of birds, Different types of soldiers in a game, Different types of tires.

2. Abstract Factory : - This is used in conjunction with other design patterns to separate the logic of creation of similar objects/object families. For example if Strategy is used to implement the logic for different soldiers, the abstract factory/factory method will be responsible for creating the concrete instances of each type of soldier based on the condition passed to the factory. Each object family will have its own Factory. 

Ex. SoldierFactory, TireFactory

3. Template Method: All abstract classes or interfaces make it mandatory for child classes to implement the concrete methods/functionality. 

Similarly the Template Method pattern is implemented using an abstract class or an interface to ensure that all the child classes follow a set of pre-defined steps in a sequential manner (an algorithm) using abstract or concrete methods. The concrete implementation of the abstract methods will then be defered to the child classes implementing the Template interface or abstract class.

This is especially important when you want some generic plumbing code to be implemented for various different programs/classes in the same order but want to defer the concrete implementation to the child/concrete classes. This also makes sure that any new developer in the team follows the same sequence while writing some code for same family of classes.

Ex. If you follow a generic standard to read write to Database/Files or implement a New API. You might want to enforce a few things in the logic.

4. Composite Pattern: This design pattern is used when you want to implement a hierarchical structure. Each Object of the Composite structure behaves (treated) same. 

Ex. Tree View/ Menu Implementation. Some times you want to implement a configurable Menu where either the Sub Menu or the Menu Items are made visible based on the authorization of the user. We can use the Composite Design Pattern to implement this.

5. Observer Pattern : A way to implement the notification mechanism in an object. Different Objects can subscribe to your object and can get notified when the state of the object changes. To Implement this, ALL the subscribers need to implement the same interface which must have the same method to get the notification, so that your Object can maintain a generic list of all the subscribers (using the Interface List) and then call the notification method of each subscriber whenever its state changes.

Ex. Used in all the event based objects, like Button Click, Sockets etc.

6. Adaptor Pattern : This is an intermediary Object to plug two different objects with different interfaces/contracts. This object will basically know the implementation of both the objects and hack a way to convert the inputs of Object 1 to comply with the inputs of Object 2 and then the same for the output of Object 2 to comply with Object 1, so that the two Objects can start communicating with each other.

It behaves the same way as an electric adapter where we convert the inputs of a socket to comply with the needs of a device.

7. Decorator Pattern: Add more functionality to an object without changing its implementation. When we dont change the code of an object we make sure that the existing child classes and their implementation does not get disturbed. We do so by creating a new decorator class and encapsulating the object that we want to add functionality to.

8. Dependency Injection : To implement Inversion of control. One step further to Abstract Factory. Some programmers feel that having an Abstract Factory is still a code smell as we are still creating the concrete instances of a type within the called code. It should be the responsibility of the calling code to initialize the type.

More on IoC and DI :https://www.dhirubhai.net/pulse/inversion-control-ioc-dependency-injection-di-amritpal-singh/