In programming, we are usually need to queue requests, or decouple implementation of requests from its caller. And this is reason Command pattern was given birth. The Command pattern, basically, allows us encapsulate commands into objects. Thereby, it provides some useful options, such as:
- Queue or dequeue requests
- Parameterize client with different requests
- Support redo/undo functionality
The implementation of Command pattern is quite simple with four major terms: Receiver, Invoker, Command, ConcreteCommand and Client. Let take a look at bellow diagram: Continue reading
Sometimes existing classes already provide functionalities required by client, but its interface is not what the client expects. So that we need a bridge to convert existing interface to what the client expects. And the bridge is called an Adapter. In real world, an adapter is very popular such as adapters for supplies, adapters for memory cards, so on. In software programming, the features of adapter are provided by Adapter pattern. We are going into its details in this article.
Adapter pattern helps us with two main jobs:
- Convert the interface of a class into another interface what client expects.
- Adapter lets classes work together, that couldn’t be able because of incompatible interfaces.
Sometimes we need to extend an object functionality, a normal way we can do it statically by inheritance mechanism. This is not wrong, but in some situations it makes source code more complex as well. That is reason Decorator pattern, a way of extending functionality dynamically, was born.
According to GoF, Decorator pattern is one of the widely used structure patterns. This pattern dynamically changes the functionality of an existed object at runtime without impacting on the existing functionality of the other objects. Continue reading
Before to be continue, I suggest that you should know about OOP Design Principles. If you do not any more, please take a look at this link before keep on reading this articles.
One of the design principles is “Dependency Inversion Principle”, it says that:
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
Builder pattern is an object creation design pattern, after the ealier one – Singleton. This pattern allows the client side create a complex object by specifing only its type and its content. In fact, we see builder pattern in something likes that:
Sometimes we need only one instance of a class in whole system, and “Singleton” was born.
Singleton is the simplest pattern in the design pattern world. It invokes only one class which is responsible to instantite itself, to make sure no more than one instance of it was created. This class is used for centralized management of resources and provides global access point to itself. Continue reading