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.

Behavioral design patterns focus on the interaction and responsibilities between objects and classes, emphasizing how they communicate and collaborate to achieve a common goal. These patterns deal with the delegation of responsibilities, communication, and control flow in object-oriented systems.

1. Enhanced Collaboration Among Objects:
   • Behavioral patterns promote effective communication and coordination between objects, ensuring that responsibilities are distributed efficiently without tightly coupling the objects.
2. Increased Flexibility and Reusability:
   • These patterns decouple the interaction logic from the objects involved, making the system more flexible to changes. Objects and classes can be reused in different contexts without significant modification.
3. Improved Maintainability:
   • By clearly defining interaction protocols, behavioral patterns simplify the understanding and maintenance of the system. They provide clear guidelines on how objects should work together, reducing complexity.
4. Focus on Behavior over Structure:
   • Unlike structural patterns, which emphasize the composition of classes and objects, behavioral patterns focus on how objects interact over time, addressing dynamic and runtime concerns.
5. Better Encapsulation:
   • These patterns often encapsulate complex behavior in a single object or method, reducing the need for other objects to understand and manage the details.
6. Encourage Loose Coupling:
   • By defining clear interaction contracts, behavioral patterns reduce dependencies between objects. This results in systems that are easier to extend and adapt to new requirements.
7. Solve Common Interaction Problems:
   • Many challenges, such as managing state, implementing algorithms, or handling object requests, are addressed systematically by behavioral patterns, making them effective solutions for common design problems.
8. Support for Diverse Communication Mechanisms:
   • Behavioral patterns enable different communication paradigms, such as request-response, event-driven, and observer-based interactions, allowing systems to cater to a variety of requirements.
9. Key to Effective Design:
   • Understanding and applying behavioral patterns is critical to creating systems that are robust, scalable, and aligned with principles of good software design.

Examples of Behavioral Patterns:

• Strategy: Encapsulates algorithms so that they can be selected at runtime.
• Observer: Enables a one-to-many dependency so that changes in one object notify all dependents.
• Command: Encapsulates a request as an object, allowing parameterization of requests and queuing them.
• Mediator: Simplifies communication between objects by centralizing it in a mediator.
• State: Allows an object to alter its behavior when its internal state changes.

Behavioral patterns provide a blueprint for managing the complexity of object interactions, making them indispensable tools for designing robust, maintainable, and scalable software systems.

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: