Scribd
Upload
9 views

Design Pattern Test

The document describes several design patterns: Decorator allows modifying object responsibilities dynamically without subclassing. Flyweight reduces memory usage by sharing extrinsic state between objects. Proxy controls access to another object and can add functionality. Facade provides a simple interface to a complex system.

Uploaded by

Ranjith
Copyright
© © All Rights Reserved
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
9 views

Design Pattern Test

The document describes several design patterns: Decorator allows modifying object responsibilities dynamically without subclassing. Flyweight reduces memory usage by sharing extrinsic state between objects. Proxy controls access to another object and can add functionality. Facade provides a simple interface to a complex system.

Uploaded by

Ranjith
Copyright
© © All Rights Reserved
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Purpose

Allows for the dynamic wrapping of objects in order to modifytheir existing


responsibilities and behaviors.
Use When
n
Object responsibilities and behaviors should be dynamicallymodifiable.
n
Concrete implementations should be decoupled fromresponsibilities and behaviors.
n
Subclassing to achieve modification is impractical or impossible.
n
Specific functionality should not reside high in the object hierarchy.
n
A lot of little objects surrounding a concrete implementation isacceptable.
Example
Many businesses set up their mail systems to take advantage ofdecorators. When
messages are sent from someone in the companyto an external address the mail server
decorates the originalmessage with copyright and confidentiality information. As
longas the message remains internal the information is not attached.This decoration
allows the message itself to remain unchangeduntil a runtime decision is made to
wrap the message withadditional information.
Purpose
Supplies a single interface to a set of interfaces within a system.
Use When
n
A simple interface is needed to provide access to a complexsystem.
n
There are many dependencies between system implementationsand clients.
n
Systems and subsystems should be layered.
Example
By exposing a set of functionalities through a web servicethe client code needs to
only worry about the simple interfacebeing exposed to them and not the complex
relationships thatmay or may not exist behind the web service layer. A singleweb
service call to update a system with new data may actuallyinvolve communication
with a number of databases and systems,however this detail is hidden due to the
implementation of thefaçade pattern.
Purpose
Facilitates the reuse of many fine grained objects, making theutilization of large
numbers of objects more efficient.
Use When
n
Many like objects are used and storage cost is high.
n
The majority of each object’s state can be made extrinsic.
n
A few shared objects can replace many unshared ones.
n
The identity of each object does not matter.
Example
Systems that allow users to define their own application flowsand layouts often have
a need to keep track of large numbers offields, pages, and other items that are
almost identical to eachother. By making these items into flyweights all instances
of eachobject can share the intrinsic state while keeping the extrinsicstate
separate. The intrinsic state would store the shared properties,such as how a
textbox looks, how much data it can hold, andwhat events it exposes. The extrinsic
state would store theunshared properties, such as where the item belongs, how
toreact to a user click, and how to handle events.
Purpose
Allows for object level access control by acting as a pass throughentity or a
placeholder object.
Use When
n
The object being represented is external to the system.
n
Objects need to be created on demand.
n
Access control for the original object is required.
n
Added functionality is required when an object is accessed.
Example
Ledger applications often provide a way for users to reconciletheir bank statements
with their ledger data on demand, automat-ing much of the process. The actual
operation of communicatingwith a third party is a relatively expensive operation
that should belimited. By using a proxy to represent the communications objectwe
can limit the number of times or the intervals the communica-tion is invoked. In
addition, we can wrap the complex instantiationof the communication object inside
the proxy class, decouplingcalling code from the implementation details.

DECORATOR

Object Structural
FLYWEIGHT

Object Structural
PROXY

Object Structural
FACADE

Object Structural
Complex System
ClientFlyweightFactory
+getFlyweight(in key)
◆
ConcreteFlyweight
-intrinsicState+operation(in extrinsicState)
UnsharedConcreteFlyweight
-allState+operation(in extrinsicState)<<interface>>
Flyweight
+operation(in extrinsicState)
Client
<<interface>>
Subject
+request()
represents
RealSubject
+request()
Proxy
+request()
ConcreteComponent
+operation()
ConcreteDecorator
-addedState+operation()+addedBehavior()
Decorator
+operation()<<interface>>
Component
+operation()
Facade

You might also like