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 patterns are concerned with algorithms and the assignment of responsibilities between objects.
describe the patterns of communication between the objects. These patterns characterize complex control flow that is challenging to follow at run-time.
- Behavioral patterns shift your focus away from flow of control to let you concentrate just on the way objects are interconnected.
- Behavioral class patterns use inheritance to distribute behavior between classes.
- 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, to teach new designers how to design well, and to
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
- occur in a design,
- how to resolve them, and
- how to evaluate design.
But they have not been able to capture the experience of expert designers.
We believe the GoF 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 objects, inheritance, and 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 way to describe more of the "why" of a design and not just record the results of your decisions.
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.