Chapter 4_Introduction to Patterns.ppt

What is a Pattern & Design Pattern
• Designing object-oriented software is hard, and designing reusable
object-oriented software is even harder.
• You must find pertinent objects, factor them into classes at the right
granularity, define class interfaces and inheritance hierarchies, and
establish key relationships among them.
• Your design should be specific to the problem at hand but also general
enough to address future problems and requirements.
• You also want to avoid redesign, or at least minimize it.
• Experienced object-oriented designers will tell you that a reusable and
flexible design is difficult if not impossible to get "right" the first time.
• Before a design is finished, they usually try to reuse it several times,
modifying it each time.

• Design patterns make it easier to reuse successful designs and
architectures.
• Expressing proven techniques as design patterns makes them more
accessible to developers of new systems.
• Design patterns help you choose design alternatives that make a
system reusable and avoid alternatives that compromise reusability.
• Design patterns can even improve the documentation and
maintenance of existing systems by furnishing an explicit specification
of class and object interactions and their underlying intent.
• Put simply, design patterns help a designer get a design "right" faster.

• In general, a pattern has four essential elements:
1. The pattern name :
• It is a handle we can use to describe a design problem, its solutions, and
consequences in a word or two.
• Naming a pattern immediately increases our design vocabulary. It lets us design
at a higher level of abstraction.
• Having a vocabulary for patterns lets us talk about them with our colleagues, in
our documentation, and even to ourselves.
• It makes it easier to think about designs and to communicate them and their
trade-offs to others.
• Finding good names has been one of the hardest parts of developing our
catalog.

2. The problem
• It describes when to apply the pattern.
• It explains the problem and its context.
• It might describe specific design problems such as how to represent algorithms
as objects.
• It might describe class or object structures that are symptomatic of an inflexible
design.
• Sometimes the problem will include a list of conditions that must be met before
it makes sense to apply the pattern.
3. The solution
• Describes the elements that make up the design, their relationships,
responsibilities, and collaborations.
• The solution doesn't describe a particular concrete design or implementation,
because a pattern is like a template that can be applied in many different
situations.
• Instead, the pattern provides an abstract description of a design problem and
how a general arrangement of elements (classes and objects in our case) solves
it.

4. The consequences
• These are the results and trade-offs of applying the pattern.
• Though consequences are often unvoiced when we describe design decisions,
they are critical for evaluating design alternatives and for understanding the
costs and benefits of applying the pattern.
• The consequences for software often concern space and time trade-offs.
• They may address language and implementation issues as well.
• Since reuse is often a factor in object-oriented design, the consequences of a
pattern include its impact on a system's flexibility, extensibility, or portability.
• Listing these consequences explicitly helps you understand and evaluate them.

Describing Design Patterns
• We describe design patterns using a consistent format.
• Each pattern is divided into sections according to the following
template.
• The template lends a uniform structure to the information, making
design patterns easier to learn, compare, and use.
• Pattern Name and Classification:
• The pattern's name conveys the essence of the pattern succinctly.
• A good name is vital, because it will become part of your design
vocabulary.

• Intent:
• A short statement that answers the following questions: What does the
design pattern do?
• What is its rationale and intent? What particular design issue or problem
does it address?
• Also Known As:
• Other well-known names for the pattern, if any.
• 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:
• What are the situations in which the design pattern can be applied?
• What are examples of poor designs that the pattern can address?
• How can you recognize these situations?
• Structure:
• A graphical representation of the classes in the pattern using a notation
• based on the Object Modeling Technique (OMT) [RBP+91].
• We also use interaction diagrams [JCJO92, Boo94] to illustrate
sequences of requests and collaborations between objects.
• Participants:
• The classes and/or objects participating in the design pattern and their
responsibilities.

• Collaborations:
• How the participants collaborate to carry out their responsibilities.
• 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 Smalltalk.
• Known Uses:
• Examples of the pattern found in real systems.
• Related Patterns:
• What design patterns are closely related to this one?
• What are the important differences?
• With which other patterns should this one be used?

The Catalog of Design Patterns
• Abstract Factory
• Provide an interface for creating families of related or dependent objects
without specifying their concrete classes.
• Adapter :
• Convert the interface of a class into another interface clients expect.
• Adapter lets classes work together that couldn't otherwise because of
incompatible interfaces.
• Bridge
• Decouple an abstraction from its implementation so that the two can vary
independently.

• Builder
• Separate the construction of a complex object from its representation so that
the same construction process can create different representations.
• Chain of Responsibility
• Avoid coupling the sender of a request to its receiver by giving more than one
object a chance to handle the request.
• Chain the receiving objects and pass the request along the chain until an object
handles it.
• Command
• Encapsulate a request as an object, thereby letting you parameterize clients
with different requests, queue or log requests, and support undoable
operations.

• Composite
• Compose objects into tree structures to represent part-whole hierarchies.
• Composite lets clients treat individual objects and compositions of objects
uniformly.
• Decorator
• Attach additional responsibilities to an object dynamically.
• Decorators provide a flexible alternative to subclassing for extending
functionality.
• Facade
• Provide a unified interface to a set of interfaces in a subsystem.
• Façade defines a higher-level interface that makes the subsystem easier to use.

• Factory Method
• Define an interface for creating an object, but let subclasses decide which class
to instantiate.
• Factory Method lets a class defer instantiation to subclasses.
• Flyweight
• Use sharing to support large numbers of fine-grained objects efficiently.
• Interpreter
• Given a language, define a represention for its grammar along with an
interpreter that uses the representation to interpret sentences in the
language.
• Iterator
• Provide a way to access the elements of an aggregate object sequentially
without exposing its underlying representation.

• Mediator
• Define an object that encapsulates how a set of objects interact.
• Mediator promotes loose coupling by keeping objects from referring to each
other explicitly, and it lets you vary their interaction independently.
• Memento
• Without violating encapsulation, capture and externalize an object's internal
state so that the object can be restored to this state later.
• Observer
• Define a one-to-many dependency between objects so that when one object
changes state, all its dependents are notified and updated automatically.
• Prototype
• Specify the kinds of objects to create using a prototypical instance, and create
new objects by copying this prototype.

• Proxy
• Provide a surrogate or placeholder for another object to control access to it.
• Singleton
• Ensure a class only has one instance, and provide a global point of access to it.
• State
• Allow an object to alter its behavior when its internal state changes.
• The object will appear to change its class.
• Strategy
• Define a family of algorithms, encapsulate each one, and make them
interchangeable.
• Strategy lets the algorithm vary independently from clients that use it.

• Template Method
• Define the skeleton of an algorithm in an operation, deferring some steps to
subclasses.
• Template Method lets subclasses redefine certain steps of an algorithm
without changing the algorithm's structure.
• Visitor
• Represent an operation to be performed on the elements of an object
structure.
• Visitor lets you define a new operation without changing the classes of the
elements on which it operates.

Organizing the Catalog
• 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
• First criterion: Purpose
• It reflects what a pattern does.
• Patterns can have either creational, structural, or behavioral
purpose.
• Creational patterns : The process of object creation.
• Structural patterns : The composition of classes or objects.
• Behavioral patterns : The ways in which classes or objects
interact and distribute responsibility.

Chapter 4_Introduction to Patterns.ppt

• Second criterion: Scope
• It 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.
• Creational object patterns defer it to another object.
• The Structural class patterns use inheritance to compose classes
• 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.

• There are other ways to organize the patterns.
• Some patterns are often used together.
• For example:
• 1. Composite is often used with Iterator or Visitor.
• Some patterns are alternatives:
• 1. Prototype is often an alternative to Abstract Factory.
• Some patterns result in similar designs even though the patterns
have different intents.
• For example:
• 1. The structure diagrams of Composite and Decorator are
similar.

How Design Patterns Solve Design Problems
 Finding Appropriate Objects
• Object-oriented programs are made up of objects.
• An object packages both data and the procedures that operate on that data.
• The procedures are typically called methods or operations.
• An object performs an operation when it receives a request (or message) from a
client.
• Requests are the only way to get an object to execute an operation.
• Operations are the only way to change an object's internal data.
• Because of these restrictions, the object's internal state is said to be
encapsulated; it cannot be accessed directly, and its representation is invisible
from outside the object.

• The hard part about object-oriented design is decomposing a system into
objects.
• The task is difficult because many factors come into play: encapsulation,
granularity, dependency, flexibility, performance, evolution, reusability, and on
and on.
• They all influence the decomposition, often in conflicting ways.
• Design patterns help you identify less-obvious abstractions and the objects that
• can capture them.
• For example, objects that represent a process or algorithm don't occur in
nature, yet they are a crucial part of flexible designs.
• The Strategy pattern describes how to implement interchangeable families of
algorithms.
• The State pattern represents each state of an entity as an object.
• These objects are seldom found during analysis or even the early stages of
design; they're discovered later in the course of making a design more flexible
and reusable

 Determining Object Granularity
• Objects can vary tremendously in size and number.
• They can represent everything down to the hardware or all the way up to entire
applications.
• How do we decide what should be an object?
• Design patterns address this issue as well. The Facade pattern describes how to
represent complete subsystems as objects, and the Flyweight pattern describes
how to support huge numbers of objects at the finest granularities.
• Other design patterns describe specific ways of decomposing an object into
smaller objects.
• Abstract Factory and Builder yield objects whose only responsibilities are
creating other objects.
• Visitor and Command yield objects whose only responsibilities are to
implement a request on another object or group of objects.

 Specifying Object Interfaces
• Every operation declared by an object specifies the operation's name, the
objects it takes as parameters, and the operation's return value.
• This is known as the operation's signature.
• The set of all signatures defined by an object's operations is called the interface
to the object.
• An object's interface characterizes the complete set of requests that can be sent
to the object.
• Any request that matches a signature in the object's interface may be sent to
the object.
• Interfaces are fundamental in object-oriented systems.
• Objects are known only through their interfaces.
• There is no way to know anything about an object or to ask it to do anything
without going through its interface.
• An object's interface says nothing about its implementation—different objects
are free to implement requests differently.
• That means two objects having completely different implementations can have
identical interfaces.

• Design patterns help you define interfaces by identifying their key elements and
the kinds of data that get sent across an interface.
• A design pattern might also tell you what not to put in the interface.
• The Memento pattern is a good example.
• It describes how to encapsulate and save the internal state of an object so that
the object can be restored to that state later.
• The pattern stipulates that Memento objects must define two interfaces: a
restricted one that lets clients hold and copy mementos, and a privileged one
that only the original object can use to store and retrieve state in the memento.
• Design patterns also specify relationships between interfaces.
• In particular, they often require some classes to have similar interfaces, or they
place constraints on the interfaces of some classes.
• For example, both Decorator and Proxy require the interfaces of Decorator and
Proxy objects to be identical to the decorated and proxied objects.
• In Visitor , the Visitor interface must reflect all classes of objects that visitors can
visit.

 Specifying Object Implementations
• An object's implementation is defined by its class.
• The class specifies the object's internal data and representation and defines the
operations the object can perform.
• Our OMT-based notation depicts a class as a rectangle with the class name in
bold. Operations appear in normal type below the class name.
• Any data that the class defines comes after the operations.
• Lines separate the class name from the operations and the operations from the
data:

• Objects are created by instantiating a class.
• The object is said to be an instance of the class.
• The process of instantiating a class allocates storage for the object's internal
data (made up of instance variables) and associates the operations with these
data.
• Many similar instances of an object can be created by instantiating a class.
• A dashed arrowhead line indicates a class that instantiates objects of another
class. The arrow points to the class of the instantiated objects.

• New classes can be defined in terms of existing classes using class inheritance
• An abstract class is one whose main purpose is to define a common interface for
its subclasses.
• Classes that aren't abstract are called concrete classes

References
• Design Patterns – Elements of Reusable
Object-oriented Software By E. Gamma,
Richard Helm, Ralph Johnson , John Vlissides
(GoF)

Chapter 4_Introduction to Patterns.ppt

Recommended

More Related Content

Similar to Chapter 4_Introduction to Patterns.ppt (20)

Recently uploaded (20)

Chapter 4_Introduction to Patterns.ppt