This is behavioral design pattern, which means it focus on ways that individual objects collaborate to achieve a common goal.

The Template Method can be helpful if you have 2 classes with similar functionality, which apply generalization principle.

This UML diagram has the essential components: a public template method and abstract methods in the superclass. These abstract methods are implemented in the subclasses. There is also one step common to all: reachDestination. It is private because only the method in the superclass needs to access it.

Using the decorator pattern you can build functionality by stacking objects, which allows objects to dynamically add behaviors to others.

The next diagram is helpful to understand the Decorator pattern:

This is how aggregation stack looks like. The Object A is a base object because it doesn’t contain another object. It will have its own set of behaviors. Object B aggregates Object A allowing Object B augment the behaviors of Object A. We can continue add objects to stack where Object C aggregates Object B and augment behaviors of Object B. The relation is always 1 to 1 in decorator design pattern in order to build up the stack so that one object is on top of another.

To achieve an overall combination of behavior for the stacked objects, you would call upon the top element which is object C, then C -> B -> A. Object A responds with its behavior, then object B adds its incremental behavior and object C adds its incremented behavior.

Proxy acts as a simplified or lightweight version of the original object where the proxy object is still able to accomplish the same tasks, but may delegate requests to the original object to achieve them. The proxy object itself can hide sensitive information of the original object when interacting with another objects.

3 main reasons to use proxy design pattern:

1. To act as a virtual proxy – where the proxy class is used in place of a real subject class that is resource intensive to instantiate (this is commonly used on images and web pages, because a single high definition image can be extremely large).
2. To act as a protection proxy – in order to control access to the real subject class (role management system).
3. To act as a remote proxy – where the proxy class is local and the real subject class exists remotely (like a Google documents where web browser has all the objects it needs locally, which also exists on Google servers).

The pattern achieves 2 goals:

1. To compose nested structures of objects.
2. To deal with the classes for these objects uniformly.

Visualization of the composite:

Problem: the output of one system my not conform to the expected input of another system.

The Adapter design pattern will help to facilitate communication between two existing systems by providing a compatible interface.

The Adapter essentially encapsulates the adaptee and presents a new interface, or appearance, to the client class. It does this by wrapping the adaptee’s interface and exposing a new target interface that makes sense to the client.

Larger system => more complex system, which potentially confusing for the client classes in your system to use. System complexity is not always a sign for poor design, though.

The Facade design pattern provides a single simplified interface for client classes to interact with the subsystem. It doesn’t add any functionality, it simply acts as a point of entry into your subsystem. It’s wrapper class that encapsulates a subsystem in order to hide the complexity.

A Facade class can be used to wrap all the interfaces and classes for a subsystem.

Factory creates objects. The clients who use the factory can focus on other behavior. So the object creation delegated to another object.

Factory Object

Benefits: if there are multiple clients that want to instantiate the same set of classes, then by using a Factory object, you have cut out redundant code and made software easier to modify. Means if need a change of object creation, then have to modify just a factory instead of every client and it’s calling coding to an interface, not an implementation.

Factory:

public class CarFactory(){
    public Car createCar(string carType) {
        Car car;
        
        if(carType.Equals("sport")){
            car = new SportCar();
        }
        else if(carType.Equals("city")){
            car = new CityCar();
        }        

        return car;
    }
}

The singleton pattern refers to having only one object of a class. Again, enforces one and only one object of a Singleton class which globally accessible within a program.

Code example:

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

The design patterns will help you to make flexible, reusable, and maintainable software.

Creational

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

Structural

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Behavioral

• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

How to make sure the system that you’ve created is correct?

For example, you can run tests and see if the actual behavior matches what you expect. But there is another technique called model checking.

Model Checking is a systematic check of your systems state model in all its possible states, can help to find laws. Its done after code has been written and before deployment.

How to model check software? Model checkers generate a State Model from your code.

State Model is an abstract state machine that can be in one of various states. The model checker then checks that the state model conforms to certain behavioral properties.

There are 3 different phases to performing model checking:

1. The Modeling phase – this is where you enter the model description and describe the desired properties.
2. The Running phase – can see how your model conforms to the desired properties that has been wrote in the modeling phase.
3. The Analysis phase – checks if all the desired properties are satisfied and if any are violated. Violations are called Counterexamples. Also you can analyze how you got this state using the information from the model checker with advice where to fix. And then run the phases again until eliminate the issues.