Lesson 14

This module discussed behavioral design patterns, the patterns that describe the ways objects and classes interact. Most behavioral patterns allow the behavior of objects or classes to vary by encapsulating the changing parts. In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.

In the tapestry of software engineering, Behavioral Design Patterns emerge as the unsung heroes that quietly influence the interactions and responsibilities among objects and classes. They are the behind-the-scenes directors, coordinating the myriad players on the stage of a software application. The narrative arc of software design is incomplete without acknowledging their role in facilitating clean, maintainable, and scalable code.
As in a great novel where characters evolve, make choices, and interact in complex ways to move the plot forward, Behavioral Design Patterns guide the interactions among objects to craft a coherent storyline within a software application. Whether it's the Observer Pattern, which could be likened to a town crier disseminating news to the villagers, or the Strategy Pattern, comparable to a hero choosing different weapons for different battles, each of these patterns tells a story of efficient and effective interaction.
However, just as a narrative can be marred by plot holes or inconsistencies, the misuse or overuse of Behavioral Design Patterns can introduce unnecessary complexity or inefficiency. The key is to employ them judiciously, knowing well the contours of the story one wishes to tell. Failing to do so could create a narrative overrun with subplots and tangents, confusing those who later read or modify the code, much like a story with too many twists and turns can lose its audience.
If we were to draw a conclusion, it would be this: Behavioral Design Patterns serve as a crucial narrative device in the story of software architecture. They can either make the plot cohesive and engaging or muddle it into obscurity. Thus, understanding their roles, advantages, and pitfalls is not just an academic exercise but a practical necessity. They are the quills with which developers write the unfolding chapters of software’s ever-evolving narrative, and how well that story is told depends largely on the skillful application of these time-tested patterns.

Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects. Behavioral patterns describe the patterns of communication between the objects. These patterns characterize complex control flow that is challenging to follow at run-time.

1. Behavioral patterns shift your focus away from flow of control to let you concentrate just on the way objects are interconnected.
2. Behavioral class patterns use inheritance to distribute behavior between classes.
3. Behavioral object patterns use object composition rather than inheritance.

Some patterns describe how a group of peer objects cooperate to perform a task that no single object can carry out by itself. An important issue here is how peer objects know about each other. Peers could maintain explicit references to each other, but that would increase their coupling.

Object-oriented design methods should promote good design and standardize the way designs are developed. A design method typically defines a set of notations (such as UML diagrams) for modeling various aspects of a design, along with a set of rules that govern how and when to use each notation. Design methods usually describe problems that

1. occur in a design,
2. how to resolve them, and
3. how to evaluate design.

Object moderles have not been able to capture the experience of experienced designers. We believe the Gang of Four Patterns are an important component that has been missing from object-oriented design methods. The design patterns show how to use primitive techniques such as

1. objects,
2. inheritance, and
3. polymorphism.

They show how to parameterize a system with an algorithm, a behavior, a state, or the kind of objects it's supposed to create. Design patterns provide a technique to describe the "theory" behind design and not just display the outcome of the software engineering process.
Design patterns are especially useful in turning an analysis model into an implementation model. Despite many claims that promise a smooth transition from object-oriented analysis to design, in practice the transition is anything but smooth. A flexible and reusable design will contain objects that are not in the analysis model. The programming language and class libraries you use affect the design. Analysis models often must be redesigned to make them reusable. Many of the design patterns described on this website address these issues, which is why we call them design patterns.
A complete design method requires more kinds of patterns than just design patterns. There can also be 1) analysis patterns, 2) user interface design patterns, or 3) performance-tuning patterns. But the design patterns are an essential part, one that's been missing until now.

In the next module, we will discuss some larger issues involved in designing software with patterns.
You will learn how to choose a design pattern that fits your need, explore some general rules for working with patterns, and consider the idea of programs as groups of design patterns.

[1]Analysis models: