Introduction to Description of Patterns

Software patterns are reusable solutions to recurring problems that occur during
software development.
In general, a pattern has four essential elements:

The pattern name 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.

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.

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.

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. 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.

I. Organizing the Catalog

Design patterns vary in their granularity and level of abstraction. Because there
are many design patterns, we need away to organize them. This section classifies
design patterns so that we can refer to families of related patterns. The
classification helps you learn the patterns in the catalog faster, and it can direct
efforts to find new patterns as well.
We classify design patterns by two criteria.

The first criterion, called purpose, reflects what a pattern does. Patterns can have
either creational, structural, or behavioural 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

II. How Design Patterns Solve Design Problems

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 from a client.

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.

2.Determining Object Granularity Objects

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 objector 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

4.Specifying Object Implementations

So far, we've said little about how we actually define an object. 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.

III.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 un familiar 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 helpguide your search for the
right pattern.

2. Scan Intent sections.

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. You can use the
classification scheme to narrow your search.

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.

The catalog has three chapters, one for creational patterns, another for structural
patterns, and a third for behavioural 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 re design 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 designs’ patterns

IV.How to Use a Design Pattern

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.
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’s name into the name that appears in the application. That helps
make the pattern more explicit in the implementation. For example, if youuse the
Strategy pattern for a text compositing algorithm, then you might have classes
Simple Layout Strategy or TeXt Layout Strategy.
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 patternwillaffect,
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.
V.Software Design Pattern

Software Design Pattern in software engineering, a design pattern is a general

reusable solution to a commonly occurring problem within a given context in
software design. A design pattern is not a finished design that can be transformed
 directly into code. It is a description or template for how to solve a problem that
can be used in many different situations. So, patterns are formalized best practices
that you must implement yourself in your application.

Object-oriented design patterns typically show relationships and interactions

between classes or objects, without specifying the final application classes or
objects that are involved. Many patterns imply object-orientation or more
generally mutable state, and so may not be as applicable in functional
programming languages, in which data is immutable or treated as such.

Design patterns reside in the domain of modules and interconnections. At a higher

level there are architectural patterns that are larger in scope, usually describing
an overall pattern followed by an entire system.

There are many types of design patterns, like

• Algorithm Strategy Patterns addressing concerns related to high-level

strategies describing how to exploit application characteristics on a computing
platform.
• Computational Design Patterns addressing concerns related to key
computation identification.
• Execution Patterns that address concerns related to supporting application
execution, including strategies in executing streams of tasks and building blocks
to support task synchronization.
• Implementation strategy patterns addressing concerns related to
implementing source code to support
• program organization, and
• the common data structures specific to parallel programming.
• Structural Design Patterns addressing concerns related to high-level
structures of applications being developed.

VI. Creational pattern

In software engineering, creational design patterns are design patterns that deal
with object creation mechanisms, trying to create objects in a manner suitable
to the situation. The basic form of object creation could result in design
problems or added complexity to the design. Creational design patterns solve
this problem by somehow controlling this object creation.

Creational design patterns are composed of two dominant ideas. One is

encapsulating knowledge about which concrete classes the system use. Another
is hiding how instances of these concrete classes are created and combined.

Creational design patterns are further categorized into Object-creational

patterns and Class creational patterns, where Object-creational patterns deal
with Object creation and Class-creational patterns deal with Class-instantiation.
In greater details, Object-creational patterns defer part of its object creation to
another object, while Class-creational patterns defer its objection creation to
subclasses.
Five well-known design patterns that are parts creational patterns are:
 Abstract factory pattern, which provides an interface for creating related or
dependent objects without specifying the objects' concrete classes.
 Factory method pattern, which allows a class to defer instantiation to
subclasses.
 Builder pattern, which separates the construction of a complex object from
its representation so that the same construction process can create different
representation.
 Prototype pattern, which specifies the kind of object to create using a
prototypical instance, and creates new objects by cloning this prototype.
 Singleton pattern. which ensures a class only has one instance, and provides
a global point of access to it.

The abstract factory pattern is a software design pattern that provides a way to
encapsulate a group of individual factories that have a common theme. In normal
usage, the client software creates a concrete implementation of the abstract
factory and then uses the generic interfaces to create the concrete objects that
are part of the theme. The client does not know (or care) which concrete objects
it gets from each of these internal factories, since it uses only the generic
interfaces of their products. This pattern separates the details of implementation
of a set of objects from their general usage.

The factory method pattern is an object-oriented design pattern to implement

the concept of factories. Like othercreational patterns, it deals with the problem
of creating objects (products) without specifying the exact class of object that
will be created. The essence of the Factory method Pattern is to "Define an
interface for creating an object, but let the classes that implement the interface
decide which class to instantiate. The Factory method lets a class defer
instantiation to subclasses.

The builder pattern is an object creation software design pattern. The intention
is to abstract steps of construction of objects so that different implementations of
these steps can construct different representations of objects. Often, the builder
pattern is used to build products in accordance with the composite pattern.

The prototype pattern is a creational design pattern used in software

development when the type of objects to create is determined by a prototypical
instance, which is cloned to produce new objects. This pattern is used to:
 avoid subclasses of an object creator in the client application, like the abstract
factory pattern does.
 avoid the inherent cost of creating a new object in the standard way (e.g.,
using the 'new' keyword) when it is prohibitively expensive for a given
application.
In software engineering, the singleton pattern is a design pattern that restricts
the instantiation of a class to one object. This is useful when exactly one object
is needed to coordinate actions across the system. The concept is sometimes
generalized to systems that operate more efficiently when only one object
exists, or that restrict the instantiation to a certain number of objects. The terms
Creational patterns comes from the mathematical concept of a singleton.
 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III
UNIT-III:
Patterns: Pattern Description, Organizing catalogs, role in solving design problems, Selection
and usage. Creational Patterns: Abstract factory, Builder, Factory method, Prototype, Singleton

1. Introduction to design patterns or what is a design pattern (DP)?

Design patterns are repeatable / reusable solutions to commonly occurring problems in a certain
context in software design. There are four essential elements of a pattern,
 Pattern name
 Problem
 Solution
 Consequences
Need for design patterns
 Designing reusable object-oriented software (API’s) is hard.
 Experienced designers Vs novice designers.
 Patterns make object-oriented software flexible, elegant and reusable.
 Solved a problem previously but don’t remember when or how?
Use of design patterns
 Make it easier to reuse successful designs and architectures.
 Make it easy for the new developers to design software.
 Allows choosing different design alternatives to make the software reusable
 Helps in documenting and maintaining the software
Why should we use DP’s?
 These are already tested and proven solutions used by many experienced designers.
MVC Architecture
Model View Controller or MVC as it is popularly called, is a software design pattern for
developing web applications. A Model View Controller pattern is made up of the following three
parts.

Model − the lowest level of the pattern which is responsible for maintaining data
View − this is responsible for displaying all or a portion of the data to the user
Controller − Software Code that controls the interactions between the Model and View

MVC is popular as it isolates the application logic from the user interface layer and supports
separation of concerns. Here the Controller receives all requests for the application and then
works with the Model to prepare any data needed by the View. The View then uses the data
prepared by the Controller to generate a final presentable response. The MVC abstraction can be
graphically represented as follows.

IV B. Tech I Semester (R16) 2019-20 1

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III

Describing design patterns

1. Pattern name and classification 8. Collaborations

2. Intent 9. Consequences
3. Also known as 10. Implementation
4. Motivation 11. Sample code
5. Applicability 12. Known uses
6. Structure 13. Related patterns
7. Participants

Organizing catalogs

IV B. Tech I Semester (R16) 2019-20 2

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III
2. ABSTRACT FACTORY: Provides an interface to create a family of related objects, without
explicitly specifying their concrete class.
Pattern name and classification
Intent: Provide an interface for creating families of related or dependent objects without
specifying their concrete classes.
Also known as: Kit
Motivation: Creating interface components for different look and feels.

Applicability
We should use Abstract Factory design pattern when:
 The system needs to be independent of the products it works with are created.
 The system should be configured to work with multiple families of products.
 A family of products is designed to be used together and this constraint is needed to be
enforced.
 A library of products is to be provided and only their interfaces are to be revealed but not
their implementations.
Structure

Participants: The classes that participate in the Abstract Factory are: AbstractFactory,
ConcreteFactory, AbstractProduct, Product, Client

IV B. Tech I Semester (R16) 2019-20 3

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III
Collaborations
 The ConcreteFactory class creates products objects having a particular implementation.
To create different product, the client should use a different concrete factory.
 AbstractFactory defers creation of product objects to its ConcreteFactory subclass.

Consequences
 It isolates concrete classes.
 It makes exchanging product families easy.
 It creates consistency among products.

Implementation
abstract class AbstractProductA
{
public abstract void operationA1();
public abstract void operationA2();
}

Sample code
public interface Window
{
public void setTitle(String text);
public void repaint();
}

Known uses
ET++ [WGM88] uses the Abstract Factory pattern to achieve portability across different window
systems (X Windows and SunView, for example).

Related patterns
 AbstractFactory classes are often implemented with factory methods but they can also be
implemented using Prototype.
 A concrete factory is often a Singleton.

IV B. Tech I Semester (R16) 2019-20 4

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III

3. BUILDER
Pattern name and classification: Builder and Creational
Intent: Separate the construction of a complex object from its representation so that the same
construction process can create different representations.
Also known as
Motivation: Text Converter

Applicability
 The algorithm for creating a complex object should be independent of the parts that make
up the object and how they are assembled.
 The construction process must allow different representations for the object that is
constructed.
Structure

Participants: Builder, ConcreteBuilder, Director, Product

Collaborations
 The client creates the Director Object and configures it with the desired Builder object.
 Director notifies the builder whenever a part o f the product should be built.
 Builder handles requests from the director and adds parts to the product.
 The client retrieves the product from the builder.

IV B. Tech I Semester (R16) 2019-20 5

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III

Consequences: The benefits and pitfalls of Builder pattern are:

 It lets you vary the product’s internal representation.
 It isolates code for construction and representation.
 It gives you finer control over the construction process.

Implementation
//Abstract Builder
class abstract class TextConverter
{
abstract void convertCharacter(char c);
abstract void convertParagraph();
}

// Product
class ASCIIText
{
public void append(char c)
{ //Implement the code here }
}
Sample code
abstract class AbstractProduct implements Cloneable
{
public static AbstractProduct thePrototype;
public static AbstractProduct makeProduct()
{
try
{
return (AbstractProduct) thePrototype.clone();
}
catch(CloneNotSupportedException e)
{
return null;
}
}
}
Known uses
The RTF converter application is from ET++ [WGM88]. Its text building block uses a builder to
process text stored in the RTF format.
Related patterns
 Abstract Factory (87) is similar to Builder in that it too may construct complex objects.
The primary difference is that the Builder pattern focuses on constructing a complex
object step by step.
 A Composite (1 i6s3) what the builder often builds.

IV B. Tech I Semester (R16) 2019-20 6

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III

4. FACTORY METHOD

Pattern name and classification: Factory method and Creational

Intent: Define an interface for creating an object, but let subclasses decide which
Also known as: Virtual Constructor
Motivation: Frameworks use abstract classes to define and maintain relationships between
objects. A framework is often responsible for creating these objects as well.

Applicability: Use the Factory Method pattern when

 A class can't anticipate the class of objects it must create.
 A class wants its subclasses to specify the objects it creates.
 Classes delegate responsibility to one of several helper subclasses, and you want to
localize the knowledge of which helper subclass is the delegate.
Structure

Participants: Product, ConcreteProduct, Creator, ConcreteCreator

Collaborations: Creator relies on its subclasses to define the factory method so that it returns an
instance of the appropriate ConcreteProduct.
Consequences: Here are two additional consequences of the Factory Method pattern
 Provides hooks for subclasses
 Connects parallel class hierarchies
Implementation
abstract class AbstractProduct implements Cloneable
{
public static AbstractProduct thePrototype;
public static AbstractProduct makeProduct()

IV B. Tech I Semester (R16) 2019-20 7

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III
{
try
{
return (AbstractProduct) thePrototype.clone();
}
catch(CloneNotSupportedException e)
{
return null;
}
}
}
Sample code
class MazeGame { public:
Maze* CreateMaze();
// factory methods:
virtual Maze* MakeMaze() const
{ return new Maze; }
virtual Room* MakeRoom(int n) const
{ return new Room(n); }
virtual Wall* MakeWall() const
{ return n ew Wall; }
virtual Door* MakeDoor(Room* rl, Room* r2) const
{ return new Door(rl, r2); } };
Known uses
Factory methods pervade toolkits and framework s.The preceding document example is a typical
use in MacApp and ET++. The manipulator example is from Unidraw.

Related patterns
 Abstract Factory is often implemented with factory methods. as well.
 Factory methods are usually called within Template Methods
 Prototypes don't require subclassing Creator.

IV B. Tech I Semester (R16) 2019-20 8

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III

5. PROTOTYPE

Pattern name and classification: Prototype and Creational

Intent: Specify the kinds of objects to create using a prototypical instance, and create new
objects by copying this prototype.
Also known as:
Motivation: You could build an editor for music scores by customizing a general framework for
graphical editors and adding new objects that represent notes, rests, and staves.

Applicability: Use the Prototype pattern when a system should be independent of how its
products are created, composed, and represented; and
 when the classes to instantiate are specified at run-time, for example, by dynamic loading
; or
 to avoid building a class hierarchy of factories that parallels the class hierarchy of
products; or
 When instances of a class can have one of only a few different combinations of state. It
may be more convenient to install a corresponding number of prototypes and clone them
rather than instantiating the class manually, each time with the appropriate state.
Structure

IV B. Tech I Semester (R16) 2019-20 9

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III

Participants: Prototype, ConcretePrototype, Client

Collaborations: A client asks a prototype to clone itself
Consequences: Additional benefits of the Prototype pattern are listed below.
 Adding and removing products at run-time
 Specifying new objects by varying values
 Specifying new objects by varying structure
 Reduced sub classing
 Configuring an application with classes dynamically
Implementation: Configuring an application with classes dynamically
 Using a prototype manager
 Implementing the Clone operation
 Initializing clones
Sample code
class MazePrototypeFactory : public MazeFactory
{
public:
MazePrototypeFactory (Maze*, Wall*, Room*, Door*),-

virtual Maze* MakeMaze() const;

virtual Room* MakeRoom(int) const;
virtual Wall* MakeWall() const;
virtual Door* MakeDoor(Room*, Room*) const;
private:
Maze* _prototypeMaze;
Room* _prototypeRoom;
Wall* _prototypeWall;
Door* _prototypeDoor;
};
Known uses
 The first widely known application o f the pattern in an objectoriented language was in
ThingLab, where users could form a composite object and then promote it to a prototype
by installing it in a library of reusable objects
Related patterns

IV B. Tech I Semester (R16) 2019-20 10

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-III
 Prototype and Abstract Factory are competing patterns in some ways
 Designs that make heavy use of the Composite and Decorator patterns often can benefit
from Prototype as well.

IV B. Tech I Semester (R16) 2019-20 11