The pattern encapsulates the request as an object of its own. Usually, when one object makes a request for a second object to do an action, the first object will call a method of the second object and the second object would complete the task.

Common way:

Visualization of the Command design pattern:

In this way, the Sender doesn’t need to know about the receiver and the methods to call.

The Command pattern has another object that invokes the command object to complete whatever task it is supposed to do, called the invoker.

Continue reading “Command Pattern” →

The State pattern is primarily used when you need to change the behavior on an object based upon the state that it’s in t run-time. For example vending machine has a different sates and can do specific actions based on those states.

Continue reading “State Pattern” →

A chain of objects that are responsible for handling requests. Its a series of objects that are linked together.

When a client object sends a request, the first handler in the chain will try to process it. If a handler can process the request, the request ends at this handler. If a handler cannot deal with the request, the handler will send a request to the next handler nd so on. If any handler can process it, then the request if not satisfied.

Continue reading “Chain of Responsibility Pattern” →

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.

Continue reading “Template Method Pattern” →

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.

Continue reading “Decorator Pattern” →

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).

Continue reading “Proxy Pattern” →

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:

Continue reading “Composite pattern” →

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.

Continue reading “Adapter pattern” →

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.

Continue reading “Facade Pattern” →