Behavioral Design Patterns

In these design patterns, identify common communication patterns between objects and realize these patterns. These patterns are also concerned with algorithms and the assignment of responsibilities between objects.

• Iterator Pattern [Sequentially access the elements of a collection]

This pattern lets you traverse elements of a collection without exposing its underlying representation. Example: list, stack, tree, etc.

The main idea of the Iterator pattern is to extract the traversal behavior of a collection into a separate object called an iterator.

• State Pattern [Alter an object’s behavior when its state changes]

In this pattern, we create objects that represent various states and a context object whose behavior varies as its state object changes. This type of design pattern comes under a behavior pattern.

• Command Pattern [Encapsulate a command request as an object]

This pattern is a data-driven design pattern and falls under the behavioral pattern category. A request is wrapped under an object as a command and passed to the invoker object.

The invoker object looks for the appropriate object that can handle this command and passes the command to the corresponding object which executes the command.

• Chain of Responsibility Pattern [A way of passing a request between a chain of objects]

As the name suggests, the chain of responsibility pattern creates a chain of receiver objects for a request. This pattern decouples the sender and receiver of a request based on the type of request.

Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.

In this pattern, normally each receiver contains a reference to another receiver. If one object cannot handle the request, then it passes the same to the next receiver, and so on.

• Template Pattern [Defer the exact steps of an algorithm to a subclass]

In this design pattern, an abstract class exposes defined way(s)/template(s) to execute its methods. Its subclasses can override the method implementation as per need, but the invocation is to be in the same way as defined by an abstract class.

Defines the skeleton of an algorithm in the parent class, but lets child classes override specific steps of the algorithm without changing its structure.

• Observer Pattern [A way of notifying change to several classes]

This design pattern is used when there is a one-to-many relationship between objects, such as if one object is modified, its dependent objects are to be notified automatically.

In simple words, lets you define a subscription mechanism to notify multiple objects about any events that happen to the object they are observing.

• Strategy Pattern [Encapsulates an algorithm inside a class]

This pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.

In simple words, a class behavior or its algorithm can be changed at run time.

We create objects that represent various strategies and a context object whose behavior varies as per its strategy object.

The strategy object changes the executing algorithm of the context object.

Cheers!