EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES

LECTURE NOTES–
UNIT I
INTRODUCTION

EID 453
DESIGN PATTERNS
4/4 B.Tech [ CSE B3 ]

C.SWATHI
DEPARTMENT OF
CSE,GIT,GU

1
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES

Module I Lecture Notes

Syllabus
Introduction: What Is a Design Pattern?, Design Patterns in Smalltalk MVC, Describing Design
Patterns, How Design Patterns Solve Design Problems, How to Select a Design Pattern, How to
Use a 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.
Yet experienced object-oriented designers do make good designs. Meanwhile new designers are
overwhelmed by the options available and tend to fall back on non-object-oriented techniques
they've used before. It takes a long time for novices to learn what good object-oriented design is all
about. Recurring patterns of classes and communicating objects in many object-oriented systems.
These patterns solve specific design problems and make object-oriented designs more flexible,
elegant, and ultimately reusable. They help designers reuse successful designs by basing new
designs on prior experience.
A designer who is familiar with such patterns can apply them immediately to design
problems without having to rediscover them. Design patterns make it easier to reuse successful
designs and architectures. Expressing proven techniques as design patterns makes them more

2
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES
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.

1.1 What is Design Pattern?

Christopher Alexander says, "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".
What he says is true about object-oriented design patterns. Our solutions are expressed in terms of
objects and interfaces, but at the core of both kinds of patterns is a solution to a problem in a
context.
A pattern has four essential elements:
1. The pattern name is a handle we can use to describe a design problem. Naming a pattern
immediately increases our design vocabulary. It lets us design at a higher level of abstraction. 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 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.

3
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES
4. The consequences 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. The consequences of a pattern include its impact on a
system's flexibility, extensibility, or portability.

1.2 Design patterns in SmallTalk MVC

The Model/View/Controller (MVC) triad of classes is used to build user interfaces in

Smalltalk-80. MVC consists of three kinds of objects. The Model is the application object; the
View is its screen presentation, and the Controller defines the way the user interface reacts to user
input. MVC decouples them to increase flexibility and reuse. MVC decouples views and models
by establishing a subscribe/notify protocol between them. A view must ensure that its appearance
reflects the state of the model. Whenever the model's data changes, the model notifies views that
depend on it. In response, each view gets an opportunity to update itself. This approach lets you
attach multiple views to a model to provide different presentations. You can also create new views
for a model without rewriting it. The following diagram shows a model and three views. The
model contains some data values, and the views defining a spreadsheet, histogram, and pie chart
display these data in various ways. The model communicates with its views when its values
change, and the views communicate with the model to access these values.

4
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES

1.3 Describing the design patterns

How do we describe design patterns? Graphical notations, while important and useful, aren't
sufficient. They simply capture the end product of the design process as relationships between
classes and objects. To reuse the design, we must also record the decisions, alternatives, and
tradeoffs that led to it. 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. The pattern's classification reflects the scheme we
used.
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.

5
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES
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). We also use interaction diagrams 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 trades-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. We include at least two examples from different
domains.
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?

1.4 How Design Patterns Solve Design Problems

6
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES
Design patterns solve many of the day-to-day problems object-oriented designers face, and in
many different ways. Here are several of these problems and how design patterns solve them.
1. 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. Object-oriented design methodologies favor many different approaches. You can
write a problem statement, single out the nouns and verbs, and create corresponding
classes and operations. Or you can focus on the collaborations and responsibilities in your
system. Or you can model the real world and translate the objects found during analysis
into design. There will always be disagreement on which approach is best.
2. Determining Object Granularity
Objects can vary tremendously in size and number. 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.
3. 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 objectoriented 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

7
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES
nothing about its implementation—different objects are free to implement requests
differently. That means two objects having completely different implementations can
have identical interfaces.
4. 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:

Return types and instance variable types are optional, since we don't assume a statically
typed implementation language. 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 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. When
a subclass inherits from a parent class, it includes the definitions of all the data and
operations that the parent class defines. Objects that are instances of the subclass will
contain all data defined by the subclass and its parent classes, and they'll be able to
perform all operations defined by this subclass and its parents. We indicate the subclass
relationship with a vertical line and a triangle: An abstract class is one whose main

8
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES
purpose is to define a common interface for its subclasses. An abstract class will defer
some or all of its implementation to operations defined in subclasses; hence an abstract
class cannot be instantiated. The operations that an abstract class declares but doesn't
implement are called abstract operations. Classes that aren't abstract are called concrete
classes. Subclasses can refine and redefine behaviors of their parent classes. More
specifically, a class may override an operation defined by its parent class.

1.5 How to Select a Design Pattern

With more than 20 design patterns in the catalog to choose from, it might be hard to find the
one that addresses a particular design problem, especially if the catalog is new and
unfamiliar to you. Here are several different approaches to finding the design pattern that's
right for your problem:

1. Consider how design patterns solve design problems.

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.

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.

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.

9
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES
The catalog has three chapters, one for creational patterns, another for structural
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, 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.

1.6 HOW TO USE DESING PATTERNS

Once you've picked a design pattern, how do you use it? 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.

10
EID 453 DESIGN PATTERNS (ELECTIVE) LECTURE NOTES
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.

11