Introduction to System Design Patterns (Part 3)
This is a continuation of the design patterns we started with in the previous two chapters. Here we will discuss the last group of design patterns which are the behavioral design patterns
Introduction to Design Patterns Part 1
Introduction to Design Patterns Part 2
3. Behavioral Design Patterns
For this section, I will only focus on design patterns that you may meet on your path as a software engineer and leave out the abstract patterns.
The five most common behavioral Design patterns are Observer, State, Strategy, Chain of Responsibility, and Command pattern which are the ones we will talk about in this session. However, there are other more abstract patterns such as Momento, Visitor, Flyweight, Mediator, and Iterator as Object scoped design patterns and Interpreter and Template methods as class Scoped design patterns
A. Observer Design Pattern (Publish-Subscriber Model)
This describes a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. It is also known as the Dependents or Publish-Subscriber Model.
I may Create a separate article on this.
A common example is partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. You don’t want to achieve consistency by making the classes tightly coupled, because that reduces their reusability.
In the above graphics, we see that a set of data can be represented in several forms (as a spreadsheet, bar chart, or pie chart) this means that all three graphics are dependent on the data and therefore should be notified when the data changes. Thus the subject should be able to send/ create data without knowing what the consumers are or how they interact with the data. This is known as loose coupling and is a very important aspect of software development.
Use the Observer pattern in any of the following situations:
- When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.
- When a change to one object requires changing others, you don’t know how many objects need to be changed.
- When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don’t want these objects tightly coupled.
B. State Design Pattern
It allows an object to alter its behavior when its internal state changes. The object will appear to change its class. this is also known as Objects for States.
It achieves this by encapsulating each possible state of the object into a separate class and delegating state-specific behavior to these classes.
The context object, which represents the object whose behavior is influenced by its state, maintains a reference to the current state object. When the state of the context changes, it switches its reference to a different state object, thereby changing its behavior dynamically. This pattern promotes cleaner code by separating concerns related to different states into distinct classes, making it easier to understand, maintain, and extend the behavior of the object. Additionally, it supports the Open/Closed Principle, allowing new states to be added without modifying existing code
Use the State pattern in either of the following cases:
- An object’s behavior depends on its state, and it must change its behavior at run-time depending on that state.
- Operations have large, multipart conditional statements that depend on the object’s state. This state is usually represented by one or more enumerated constants.
C. Strategy Design Pattern (Policy)
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Hard-wiring algorithms into the classes that require them isn’t desirable for several reasons. this can be avoided by defining classes that encapsulate different algorithms. An algorithm that’s encapsulated in this way is called a strategy
Suppose a Composition class is responsible for maintaining and updating the linebreaks of text displayed in a text viewer. Linebreaking strategies aren’t implemented by the class Composition. Instead, they are implemented separately by subclasses of the abstract Compositor class. Compositor subclasses implement different strategies:
SimpleCompositor implements a simple strategy that determines linebreaks one at a time.
TeXCompositor implements the TeX algorithm for finding linebreaks. This strategy tries to optimize linebreaks globally, that is, one paragraph at a time.
ArrayCompositor implements a strategy that selects breaks so that each row has a fixed number of items.
D. Chain of Responsibility Design Pattern
Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it
When a request is sent, it is passed along the chain of handlers until one of them handles the request or until the end of the chain is reached.
This allows for more flexibility and scalability in handling requests, as new handlers can be added or removed without affecting the client code that initiates the request. The Chain of Responsibility pattern promotes loose coupling and simplifies the code by separating the logic for processing requests into smaller, self-contained components. It is commonly used in scenarios where there are multiple objects that can potentially handle a request, and the specific handler is determined dynamically at runtime.
E. Command Design Pattern
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. Also known as the Action/Transaction model
Thank you for reading to the end. Please like and follow
You can get to me directly if you have any questions
Twitter: https://x.com/kdaprov
YouTube: https://youtube.com/@rising_tide
Email: darlingtonkimbi@gmail.com
LinkedIn: https://www.linkedin.com/in/kimbi-darlington-a867691b1/
