ROLLNO:11471A0577

PAGENO:

DESIGN PATTERNS
1. Aim:- Using UML design Abstract factory Design pattern.
Pattern Name:- ABSTRACT FACTORY
Intent:- Provide an interface for creating families of related or dependent
objects without specifying their concrete classes.
Also Known As:- Kit
Motivation:- Consider a user interface toolkit that supports multiple lookand-feel standards , such as Motif and Presentation Manager.Different lookand-feels define different appearances for user interface widgets like scroll
bars,windows and buttons.Instantiating look-and-feel-specific classes of
widgets throughout the application makes it hard to change the look and feel
later.
We can solve this problem b defining an abstract Widget Factory class
that declares an interface for creating each such basic kind of widget.
Theres also an abstract class for each kind of widget,and concrete sub
classes implement widgets for specific look-and-feel standards.Widget
factorys interface has an operation that returns a new widget object or each
abstract widget class.Clients call these operations to obtain widget instances,
but clients arent aware of the concrete classes theyre using.Thus clients
stay independent of the prevailing look and feel.

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

Widget Factory
create scrollbar
create window

window

motif widget factory

create scroll bar
create window

pmwindow

motif window

pm widget factory
create scroll bar
create window
scroll bar

pm scroll bar

motif scroll bar

Applicability:Use the Abstract Factory pattern when

A system should be independent of how its products are, created,
composed,and represented.
A system should be configured with one of multiple families of
products.
A family of related product objects is designed to be used together,
and you need to enforce this constraint.
You want to provide a class library of products, and you want to
reveal just their interfaces, not their implementations.
Structure:-

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

AbstrractFactory
createProductA()
createProductB()

clie
AbstractProductA

productA2
ConcreteFactory1
createProductA()
createProductB()

ConcreteFactory2
createProductA()
createProductB()

productA1

AbstractProductB

productB2

productB1

Participants: Abstract Factory

Concrete Factory
Abstract Product
Concrete Product
Client
Collaborations: Normally a single instance of a Concrete Factory class is created at
run-time.This concrete factory creates product objects having a particular
implementation. To create different product objects, clients should use a
different concrete factory.
Abstract Factory defers creation of product objects to its Concrete
Factory subclass.
Consequences:The Abstract Factory pattern has he following benefits and liabilities:
It isolates concrete classes.
It males exchanging product families easy.
It promotes consistency among products.

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

Supporting new kinds of product is difficult.

Known Uses: Inter Views uses the kit suffix to denote abstract factory classes.it
defines widgetkit and dialogkit abstract factories for generating look-andfeel-specific user interface objects
ET++ uses the abstract factory pattern to achieve portability across
different windows systems(X windows and Sun View).
Related Patterns: Factory Method
Prototype
Singleton

2.Aim:- Using UML design Builder Design pattern.

Pattern Name:- BUILDER
Intent:- Separate the construction of a complex object from its
representation so that the same construction process can create different
representations.
Motivation:- A reader for the RTF(Rich Text Format) document exchange
Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

format should be able to concert RTF to many text formats. The reader
might convert RTF documents into plain ASCII text or into a text widget that
can be edited interactively. The problem, however , is that the number of
possible conversions is open-ended. So it should be easy to add a new
conversion without modifying the reader.
A solution is to configure the RTF reader class with a TextConverter
object that converts RTF to another textual reprsentation.
As the RTFReader recognizes an RTF token , it issues a request to the
TextConverter to convert the token. TextConverter objects are responsible
both for performing the data conversion and for representing the token in a
particular format.
Texconverter
convertcharacter(char)
converter Fontchange(font)
convert paragraph
GetTexText

RTFReader
parseRTF()

TextWidgetconverter
convertcharacter
convertfontchange(font)
convert paragraph
GetTextwidget

TextConverter
convertCharacter
convertFontChange(font)
convertParagraph
GetTextext

ASCIIConverter
convertCharacter
getASCIIText

ASCII Text

TexText
Textwidget

Applicability:Use the Builder pattern when

An algorithm for creating a complex object should be independent of
the parts that make up the object and how theyre assembled.
The construction process must allow different representations for the

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

object constructed.
Structure:Director
construct()

Buiider

forallobjectsinstructure{
builder->BuilderPart()
}

Buiider
BuildPart()

ConcreteBuilder
BuildPart()
GetResult()

Product

Participants: Builder
ConcreteBuilder
Director
Product
Collaborations: The clients creates the Director object and configures it with the
desired Builder object.
Director notifies the builder whenever a part of the product should be
built.
Builder handles requests from the director and adds parts to the
product.
The client retrieves the product fro the builder.
Consequences:Here are key consequences of the Builder pattern,
It lets you vary a products internal representation.
It isolates cod construction and representation.
It gives you finer control over the construction process.
Known Uses: The parser class in the compiler subsystem is a Director that takes
program Node Builder object as an argument.
Class Builder is a builder that Classes use to create subclasses for
themselves.
ByteCodeStream is a builder that creates a compiled method as a
byte array.
Related Patterns:-

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

Abstract Factory
Composite

3.Aim:- Using UML design Facade Design pattern.

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

Pattern Name:- FACADE

Intent:- Provide a unified interface to a set of interfaces in a subsystem.
Facade defines a higher-level interface that makes the subsystem easier to
use.
Motivation:- Structuring a system into subsystem helps to reduce
complexity. A common design goal is to minimize the communication and
dependencies between subsystems. One way to achieve this goal is to
introduce a facade object that provides a single,simplified interface to the
more general facilities to the more general facilities of a subsystem.
Consider for example a programming environment that gives
application access to its compiler subsystem. This subsystem contains
classes such as Scanner, Parser, ProgramNode,ByteCodeStream, and
ProgramNodeBuilder that implement the compiler. Some specialized
applications might need to access these classes directly. But most clients of a
compiler generally dont care about details like parsing and code generation;
they merely want to compile some code.

compiler
compile()

Stream

NewClass7

NewClass8

NewClass9

NewClass10

NewClass11

NewClass12

BytecodeStream

CodeGenerator
NewClass13
StateMachineCodeGenerator

RISCCodeGenerator

Applicability:Narasaraopeta Engineering College

UML&DP

NewClass14

New

ROLLNO:11471A0577

PAGENO:

Use the Facade pattern when

You want to provide a simple interface to a complex subsystem.
There are many dependencies between clients and implementation
classe of an abstraction.
You want to layer your subsystems.
Structure:Facade

Participants: Facade
Subsystem classes
Collaborations: Clients communicative with the subsystem by spending request to
Facade, which forwards them to the appropriate subsystem objects.
Clients that use the facade dont have to access its subsystem objects
directly.
Consequences:the facade pattern offers the following benefits,
It shields clients from subsystem components, there by reducing the
number of objects deal with and making the subsystem easier to use.
It promotes weak coupling between the subsystems and its clients.
It doesnt prevent applications from using subsystem classes if they
need to.
Known Uses: The compiler was inspired by the ObjectWorks\SmallTalk compiler
system.
In the ET++ application framework , an application can have built in

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

10

browsing tools for inspecting its objects at run-time.

The choices operating system uses facades to compose many frame
works into one.
Related Patterns: Abstract Factory
Mediator
Singletons
4.Aim:- Using UML design Bridge Design pattern.
Pattern Name:- BRIDGE
Intent:- Decouple an abstraction from its implementation so that the two can
vary independently.
Also Known As:- Handle/Body
Motivation:- When an abstraction can have one of several possible
implementations, the usual way to accommodate them is inheritance. An
abstract class defines the interface to the abstraction, and concrete sub
classes to implement it in different ways. But this approach isnt always
flexible enough. Inheritance binds an implementation to the abstraction
permanently, which makes it difficult to modify, extend, and reuse
abstractions and implementations independently.
But , this approach has two drawbacks:
Its inconvenient to extend the window abstraction to cover different
kinds of windows or new platforms.
It makes client code platform-dependent.
The bridge pattern addresses these problems by putting the window
abstraction and its implementation in separate class hierarchies.
WindowImp
DevDrawText()
DevDrawLine()

window
DrawText()
DrawRect()

iconWindow
DrawBorder()

DrawRect()
DrawText()

TransientWindow
DrawCloseBox()

imp->DevDrawLine()
imp->DevDrawLine()
imp->DevDrawLine()
imp->DevDrawLine()

XWindowimp
DevDrawText()
DevDrawLine()

PMWin
DevDr
DevDr

DrawRect()

Narasaraopeta Engineering College

XDrawLine()

UML&DP

XDrawString
)

ROLLNO:11471A0577

PAGENO:

11

Applicability:- Use the Bridge pattern when

You want to avoid a permanent binding between an abstraction and
implementation.
Bot the abstractions and their implementations should be extensible
by sub classing.
Changes in the implementation of an abstraction should have no
impact on clients; that is, their code should not have to be recompiled.
You want to share an implementation among multiple objects and
this fact should be hidden from the client.
Structure:client

imp

Abstraction
operation()

implementor
OperationImp()

imp->Operati
onimp()
RefinedAbstraction

ConcreteImplementorA
operationImp()

Participants: Abstraction
RefinedAbstraction
Implementor
ConcreteImplementor
Collaborations: Abstraction forwards client requests to its implementor object.
Consequences:The bridge pattern has the following consequences:
Decoupling interface and implementation.
Improved extensibility.

Narasaraopeta Engineering College

UML&DP

ConcreteImplemento
operationImp()

ROLLNO:11471A0577

PAGENO:

12

Hiding implementation details from clients.

Known Uses: The ET++ Window/WindowPort design extends the /bridge pattern in
that the WindowPort also keeps a reference back to the window.
Libg++ defines classes that implement common data structures, such as
set,Linked set,Hash set,Linked list and Hash table.
NeXTs AppKit uses the Bridge pattern in the implementation and
display of graphical images.
Related Patterns: Abstract Factory
Adapter

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

13

5:-Aim:- Using UML design Decorator Design pattern.

Pattern Name:- DECORATOR
Intent:- Attach additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to sub classing for extending
functionality.
Also Known As:- Wrapper
Motivation:- Some times we want to add responsibilities to individual
objects, not to an entire class. A graphical user interface toolkit, for example,
should let you add properties like borders or behaviors like scrolling to any
user interface component.
One way to add responsibilities is with inheritance. Inheriting a
border from another class puts a border around every subclass instance. This
is inflexible, however, because the choice of border is called a
DECORATOR. The decorator conforms to the interface of the component it
decorates so that its presence is transparent to the components clients.

Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

14

visualcom
ponent
draw()

TextView
draw()

Decorator
draw()

ScrollDecorator
draw()
ScrollTo()

component-->draw()

BorderDecorator
draw()
drawBorder()

Applicability:- Use Decorator,

To add responsibilities to individual objects dynamically and
transparently, that is, with out affecting other objects.
For responsibilities that can be withdrawn.
When extension by sub-classing is impractical.
Structure:-

Narasaraopeta Engineering College

UML&DP

Decorato::Draw
();
DrawBorder();

ROLLNO:11471A0577

PAGENO:

15

component
operation()

concreteComponent
operation()

component->operati
on()

Decorator
operation()

concreteDecoratorA
operation()
addedState()

concreteDecoratorB
operation()
addedBehaviour()

Decorator::operation(
)
AddedBehaviour();

Participants: Component
ConcreteComponent
Decorator
ConcreteDecorator
Collaborations: Decorator forwards request to its Component object. It may optionally
perform additional operations before and after forwarding the request.
Consequences:The Decorator pattern has at lest two key benefits and two liabilities:
More flexibility that static inheritance.
Avoids feature-laden classes high up in the hierarchy.
A decorator and its component arent identical.
Lots of little objects.
Known Uses: Many object oriented user interface tool kits use decorators to add
graphical embellishments to widgets.
The decorator pattern gives us an elegant way to add responsibilities to
streams.
Related Patterns: Adapter
Composite
Strategy
Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

16

6:-Aim:- User gives a print command from a word document.

Design to represent this chain of responsibility design pattern.

Pattern Name:- Chain of Responsibility
Intent:- 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.
Motivation:- Consider a content sensitive help for a graphical user interface.
The user can obtain help information on any part of the interface thats
selected and and its context; for example, a button widget in a dialog box
might have different help information than a similar button in main window.
The problem heres that the object that ultimately provides the help
isnt known explicitly to the object that initiates the help request.what we
need is a way to decouple the button that initiates the help request from the
objects that might provide help information. The chain of responsibility
pattern defines how that happens.
HelpHandler
HandlerHelp()

Application

handler->Han
dlerHelp()

Widget

Button
HandleHelp()
ShowHelp()

Dialog

Applicability:- Use Chain of Responsibility when

More than one object may handle a request, and the handler isnt known
a priori. The handler should be ascertained automatically.
You want to issue a request to one of several objects without specifying
the receiver explicitly.
Narasaraopeta Engineering College

UML&DP

ROLLNO:11471A0577

PAGENO:

17

The set of objects that can handle a request should be specified

dynamically.
Structure:-

Handler
HandleRequest()

client

ConcreteHandler1
HamdleRequest()

ConcreteHandler2
HandleRequest()

Participants: Handler
ConcreteHandler
Client
Collaborations: When a client issues a request, the request propagates along the chain
until a ConcreteHandler object takes responsibility for handling it.
Consequences:Chain of Responsibility has the following benefits and liabilities:
Reduced coupling
Added flexibility in assigning responsibilities to objects.
Receipt isnt guaranteed.
Known Uses: Several class libraries use the chain of responsibility pattern to handle
user events.
The uni-draw framework for graphical editors defines command objects
that encapsulate request to component and component-view objects.
ET++ uses chain of responsibility to handle graphical update.
Related Patterns: Composite

Narasaraopeta Engineering College

UML&DP