"Each pattern describes a problem which occurs over and over again in our environment,

and then describes the core of the solution to that problem, in such a way that you can use

this solution a million times over, without ever doing it the same way twice"

Here are several different approaches to finding the design pattern that's right for your

problem:

1. Consider how design patterns solve design problems.

It discusses how design patterns help you find appropriate objects, determine object
granularity, specify object interfaces, and several other ways in which design patterns solve
design problems. Referring to these discussions can help guide your search for the right
pattern.

2. Scan Intent sections

It lists the Intent sections from all the patterns in the catalog. Read through each pattern's
intent to find one or more that sound relevant to your problem.

3. Study how patterns interrelate.

Shows relationships between design patterns graphically. Studying these relationships can
help direct you to the right pattern or group of patterns.

4. Study patterns of like purpose.

The catalog has three chapters, one for creational patterns, and another for patterns, and a
third for behavioral patterns. Each chapter starts off with introductory comments on the
patterns and concludes with a section that compares and contrasts them. These sections
give you insight into the similarities and differences between patterns of like purpose.
5. Examine a cause of redesign.

Look at the causes of redesign starting to see if your problem involves one or more of them.
Then look at the patterns that help you avoid the causes of redesign.

6.Consider what should be variable in your design. This approach is the opposite of

focusing on the causes of redesign. Instead of considering what might force a change
to a design, consider what you want to be able to change without redesign. The focus

here is on encapsulating the concept that varies a theme of many design patterns.

Here's a step-by-step approach to

applying a design pattern effectively:

1. Read the pattern once through for an overview.

Pay particular attention to the Applicability and Consequences sections to ensure the
pattern is right for your problem.

2. Go back and study the Structure, Participants, and Collaborations sections.

Make sure you understand the classes and objects in the pattern and how they relate to one
another.

3. Look at the Sample Code section to see a concrete example of the pattern in code.

Studying the code helps you learn how to implement the pattern.

4. Choose names for pattern participants that are meaningful in the application context.

The names for participants in design patterns are usually too abstract to appear directly in

an application. Nevertheless, it's useful to incorporate the participant name into the name

that appears in the application. That helps make the pattern more explicit in the

implementation. For example, if you use the Strategy pattern for a text compositing

algorithm, then you might have classes SimpleLayoutStrategy or TeXLayoutStrategy.

5. Define the classes.

Declare their interfaces, establish their inheritance relationships, and

define the instance variables that represent data and object references. Identify existing

classes in your application that the pattern will affect, and modify them accordingly.

6. Define application-specific names for operations in the pattern.

Here again, the names generally depend on the application. Use the responsibilities and
collaborations associated with each operation as a guide. Also, be consistent in your naming
conventions.

For example, you might use the "Create-" prefix consistently to denote a factory method.

7. Implement the operations to carry out the responsibilities and collaborations in the

pattern.

The Implementation section offers hints to guide you in the implementation. The

examples in the Sample Code section can help as well.

Organizing the catalog-7M

Differences:3M

Design patterns vary in their granularity and level of abstraction. Because there are

many design patterns, we need a way to organize them. We classify design patterns

by two criteria (Table 1.1).

The first criterion, called purpose, reflects what a pattern does. Patterns can be

creational, structural, or behavioral purpose. Creational patterns concern the

process of object creation. Structural patterns deal with the composition of classes

or objects. Behavioral patterns characterize the ways in which classes or objects

interact and distribute responsibility.

The second criterion, called scope, specifies whether the pattern applies primarily

to classes or to objects. Class patterns deal with relationships between classes and

their subclasses. These relationships are established through inheritance, so they are

static—fixed at compile-time.

Object patterns deal with object relationships, which can be changed at run-time

and are more dynamic. Almost all patterns use inheritance to some extent. So the

only patterns labeled "class patterns" are those that focus on class relationships.

Note that most patterns are in the Object scope.

Creational class patterns defer some part of object creation to subclasses, while

Creational object patterns defer it to another object. The Structural class patterns

use inheritance to compose classes, while the Structural object patterns describe

ways to assemble objects.

The Behavioral class patterns use inheritance to describe algorithms and flow of

control, whereas the Behavioral object patterns describe how a group of objects

cooperate to perform a task that no single object can carry out alone.

Yet another way to organize design patterns is according to how they reference each other

in their "Related Patterns" sections. Figure 1.1 depicts these relationships graphically.
.Design patterns are more abstract than frameworks. Frameworks can be embodied in

code, but only examples of patterns can be embodied in code. A strength of frameworks is

that they can be written down in programming languages and not only studied but

executed and reused directly. In contrast, the design patterns in this book have to be

implemented each time they're used. Design patterns also explain the intent, trade-offs, and

consequences of a design

2. Design patterns are smaller architectural elements than frameworks. A typical

framework contains several design patterns, but the reverse is never true.

3. Design patterns are less specialized than frameworks. Frameworks always have a

particular application domain. A graphical editor framework might be used in a factory

simulation, but it won't be mistaken for a simulation framework. In contrast, the design

patterns in this catalog can be used in nearly any kind of application. While more

specialized design patterns than ours are certainly possible (say, design patterns for

distributed systems or concurrent programming), even these wouldn't dictate an application

architecture like a framework would.

Use case analysis is a case-based way of describing the uses of the system with the goal of
defining and documenting the system requirements. It is essentially a narrative describing
the sequence of events (actions) of an external agent (actor) using the system to complete
a process. It is a powerful technique that describes the kind of functionality that a user
expects from the system. Use cases have two or more parties: agents who interact with the
system and the system itself.
Structural patterns are concerned with how classes and objects are composed to form

larger structures. Structural class patterns use inheritance to compose interfaces or

implementations.

Applicability

Use the Adapter pattern when

• you want to use an existing class, and its interface does not match the one you need.

• you want to create a reusable class that cooperates with unrelated or unforeseen

classes, that is, classes that don't necessarily have compatible interfaces.

• (object adapter only) you need to use several existing subclasses, but it's unpractical to

adapt their interface by subclassing every one. An object adapter can adapt the interface of its

parent class

Structure

Participants

• Target (Shape)

- defines the domain-specific interface that Client uses.

• Client (DrawingEditor)

- collaborates with objects conforming to the Target interface.

• Adaptec (TextView)

- defines an existing interface that needs adapting.

• Adapter (TextShape)
Applicability:

Use the Composite pattern when

• you want to represent part-whole hierarchies of objects.

• you want clients to be able to ignore the difference between compositions of objects and

individual objects. Clients will treat all objects in the composite structure uniformly.

There are many issues to consider when implementing the Composite pattern:4M

1. Explicit parent references.

Maintaining references from child components to their parent

can simplify the traversal and management of a composite structure. The parent reference

simplifies moving up the structure and deleting a component. Parent references also help

support the Chain of Responsibility pattern.

2. Sharing components.

It's often useful to share components, for example, to reduce storage requirements. But when
a component can have no more than one parent, sharing components becomes difficult.

3. Maximizing the Component interface.

One of the goals of the Composite pattern is to make clients unaware of the specific Leaf or
Thus you can choose between ease of use and generality.