Designing Software  «Prev  Next»
Lesson 3General rules for working with patterns
ObjectiveExplore how to use a Pattern

How To Apply Design Patterns when Designing Software

Once you have identified a design pattern that helps solve your problem, this Slideshow illustrates the steps to take to use the pattern effectively: The following series of images explore how to use a pattern.

1) The first thing you should do is study the pattern so that you are sure you understand it
1) The first thing you should do is study the pattern so that you are sure you understand it, that it does what you want it to do, and that you can implement it in code.

2) Map the generic pattern into your specific problem. This involves renaming the participants in the pattern to things that make sense in the context of your application.
2) Map the generic pattern into your specific problem. This involves renaming the participants in the pattern to things that make sense in the context of your application.

3) Adopting a pattern often requires you to add, remove and reorganize the classes and objects in your system. If you are using UML, CRC cards, or any other technique to document your design, you will want to update these to reflect the pattern's use.
3) Adopting a pattern often requires you to add, remove and reorganize the classes and objects in your system. If you are using UML, CRC cards[1], or any other technique to document your design, you will want to update these to reflect the pattern's use.

4) You will need to implement the pattern in code. This is often the easiest part of programming with patterns. It is much easier to write code when you have a clear model of how your objects and classes interact and relate to each other, and this is exactly what patterns provide.
4) You will need to implement the pattern in code. This is often the easiest part of programming with patterns. It is much easier to write code when you have a clear model of how your objects and classes interact and relate to each other, and this is exactly what patterns provide.

  1. The first thing you should do is study the pattern so that you are sure you understand it
  2. Map the generic pattern into your specific problem
  3. Adopting a pattern often requires you to add, remove and reorganize the classes and objects in your system
  4. You will need to implement the pattern in code. This is often the easiest part of programming with patterns.

Describing Design Patterns

What constitutes an effective articulation of design patterns? It is clear that reliance on graphical representations alone is inadequate. Such diagrams merely delineate the final form of the design as a network of relationships among classes and objects. For the design to be truly reusable, it is imperative to document the rationale, the various alternatives considered, and the compromises that shaped the final design. Additionally, the utilization of tangible examples is crucial; they illuminate the application of the design, bringing it to life. We articulate design patterns through a standardized approach, systematically organizing each pattern into segments based on a predetermined framework. This uniformity in structure enhances the digestibility, comparison, and practical application of design patterns.

Pattern Name and Classification

The pattern's name conveys the essence of the pattern in a nutshell. A good name is vital, because it will become part of your design vocabulary.

Intent

A short statement that answers the following questions:
  1. What does the design pattern do?
  2. What is its rationale and intent?
  3. What particular design issue or problem does it address?

Motivation

A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you understand the more abstract description of the pattern that follows.

Applicability

  1. What are the situations in which the design pattern can be applied?
  2. What are examples of poor designs that the pattern can address?
  3. How can you recognize these situations?

  1. Participants: The classes and/or objects participating in the design pattern and their responsibilities.
  2. Collaborations: How the participants collaborate to carry out their responsibilities.
  3. Consequences: How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?

Implementation

What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues?

Sample Code

Code fragments that illustrate how you might implement the pattern in C++ or Java.

Known Uses

Examples of the pattern found in real systems. We include at least two examples from different domains.


Analysis Phase

In the analysis phase, a partial understanding of the problem is transformed into a precise description of the tasks that the software system needs to execute. The result of the analysis phase is a detailed textual description, commonly called a functional specification[2], that has the following characteristics:
  1. It completely defines the tasks to be performed.
  2. It is free from internal contradictions.
  3. It is readable both by experts in the problem domain and by software developers.
  4. It is reviewable by diverse interested parties.
  5. It can be tested against reality.

Consider the task of writing a word-processing program. The analysis phase must define terms, such as fonts, footnotes, multiple columns, and document sections, and the interaction of those features, such as how footnotes in multiple-column text should look on the screen and the printed page. The user interface must be documented, explaining, for example, how the user is to enter and move a footnote or specify the font for footnote numbers. One possible format for an analysis document is a user manual, very precisely worded to remove as much ambiguity as possible. Another common format for describing the behavior of a system is a set of use cases.
A use case is a description of a sequence of actions that yields a benefit for a user of a system. At least in principle, it should be possible to list all benefits that a system can communicate to its users and supply use cases that show how they can be obtained. The analysis phase concerns itself with the description of what needs to be done, not how it should be done. The selection of specific algorithms, such as those that insert page breaks or sort the index, will be handled in the implementation phase. It is possible to use object-oriented techniques in the 1) analysis phase as well as 2)the design phase. An advantage of that approach is that the object model of the analysis phase can be carried forward to the design phase. A potential pitfall is that customers of a software product are generally not familiar with the terminology of object orientation. Clients may not find it easy to tell whether the analysis will lead to a product that satisfies their needs.

Using Design Patterns - Quiz

Now it is time for a quiz on using design patterns.
Using Design Patterns - Quiz

[1]CRC cards: (Class, Responsibilities, Collaborators) are an activity bridging the worlds of role-playing games and object-oriented design.
[2]functional specification: A functional specification (FS) in software development is a document that describes the features and functionality of a software product. It is a key component of the software development process, and it is used to communicate the requirements of the product to the developers.