Skip to content

Category: Design Patterns

Behavioral Design Pattern: Command Pattern

Command Pattern is a Behavioral Design Pattern. Command Pattern encapsulates any request to perform the task into a specific object. These objects later can be used to store them in Queue or Stack as needed by the application. It also enhance the flexibility as client will not bother which command is performed and how they are performed. A single command can be configured to do multiple things that are related to each other.

Behavioral Design Pattern: Chain of Responsibility Pattern

Chain of Responsibility Pattern will be our first Behavioral Design Pattern. Behavioral Design Patterns solves communication problem between different modules. They increase the flexibility in the communication process between Objects. Chain of responsibility pattern is a pretty simple pattern. It requires creation of a chain of processing objects that can process any provided task. Whenever a task needs to be done code does not relay on writing complex if..else… ladder to pass which processor needs to process which task. Task will be passed to a pipeline where each process resides and reads the inputted task one by one. Each processor has a fixed responsibility and as soon as the processor encounters any task that it can handle it will handle it otherwise it will pass the task to the next handler or processor.

Creational Design Pattern: Prototype Pattern

Prototype Pattern is an creation pattern based on cloning a pre-configured object. The idea is that you pick an object that is configured for either the default or in the ballpark of some specific use case and then you clone this and configure to your exact needs. The pattern is useful to remove a bunch of boilerplate code, when the configuration required would be onerous. We can think of Prototypes as a preset object, where you save a bunch of state as a new starting point.

Creational Design Pattern: Builder Pattern

Builder pattern fixes few problems that factory or abstract factory pattern has. In previous examples of Factory Patterns we only checked concrete objects that only required an empty constructor but what if there are too many parameters and many of them are variable. This makes using factory or abstract factory difficult because of the huge constructor declarations and dependencies that must be resolved in the perfect order.