Lecture 14 Structural Design Patterns

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Obj

ectiv

esLecture 14

Structural Design Patterns

SWE 316: Software Design and Architecture

To learn the structural design patterns and when to use them.

Ch 8Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.


Introduction

Structural design patterns are design patterns that ease the design by

identifying a simple way to realize relationships between entities.

Introduction Facade Decorator Composite Adapter Flyweight Proxy 2/30


Façade Design Pattern Design Purpose

Provide an interface to a package of classes

Design Pattern Summary Define a singleton which is the sole means for

obtaining functionality from the package.

Notes: the classes need not be organized as a package; more than one class may be used for the façade.

8.2Introduction Facade Decorator Composite Adapter Flyweight Proxy 3/30


Facade

client classes

subsystem classes

Façade

Without Facade With Facade



Applicability To provide simple interface to a complex

subsystem, which is useful for most clients.

To reduce the dependencies between the client and the subsystem, or dependencies between various subsystems.

To simplify the dependencies between the layers of a subsystem by making them communicate solely through their facades.



Consequences It shields the clients from subsystem

components, thereby making the subsystem easier to use.

It promotes weak coupling between subsystem and its clients. Components in a subsystems can change without

affecting the clients. Porting of subsystems is easier.

-- modularizes designs by hiding complexity

KEY CONCEPTFacade Design Pattern



:Client

cMethodOfFacade()

singleton:Facade

:C

myCMethod()

(return if any)

(return if any)

Sequence Diagram for FaçadeIntroduction Facade Decorator Composite Adapter Flyweight Proxy 7/30


Implementation Some classes / objects behind the Facade

may be ones that never should be visible to the client, but are necessary for the operations to take place.

The Facade can completely hide these by making them private inner classes to the Facade class.

Comments on Façade Web services provide functionality at a web site for the benefit of

external software. This is the Façade concept. Servlets are a common Java way of providing server-side Façade

functionality.



Decorator Design Pattern

Design Purpose Add responsibilities to an object at

runtime.

Design Pattern Summary Provide for a linked list of objects, each

encapsulating responsibility.



Applicability To add responsibility to individual

objects dynamically and transparently, that is, without affecting other objects.

For responsibility that can be withdrawn.

-- allows addition to and removal from objects at runtime

KEY CONCEPTKey Concept: Decorator Design Pattern



Client

objDecorated

1

DecorationdoAction()

SubstancedoAction()

Componentadd( Component )

doAction()

void doAction(){ ….. // do actions special to this decoration objDecorated.doAction(); // pass along}

Decorator Class Model (Fig 8.9)Introduction Facade Decorator Composite Adapter Flyweight Proxy 11/30


:Client

doAction()

decoration1:Decoration

doAction()

Decoration1.objDecorated:Decoration

:Substance

doAction()

Sequence Diagram for DecoratorIntroduction Facade Decorator Composite Adapter Flyweight Proxy 12/30


Comments on Decorator Replace the Component interface with an

abstract class (if it contains useful base functionality)

Decorator can be thought of as an object version of linked list.

Why use Decorator when a simple Vector or component object seems to suffice? This will make the code less flexible The client will have to know about the

subclasses If the subclasses are replaced then the client

code would have to change.



Composite Design Purpose

Represent a Tree of Objects Design Pattern Summary

Use a Recursive Form in which the tree class aggregates and inherits from the base class for the objects.

Applicability Allows the creation of a new object from existing objects. The client will see the new composite object as equivalent

to the other objects.

8.4

-- used to represent trees of objects.

KEY CONCEPTKey Concept: Composite Design Pattern



NonLeafNode

“every object involvedis a Component object”

“non-leaf nodes have one or more

components”

leaf nodenon-leaf node

Objects

Classes Component 1..n

Basis for Composite Class ModelIntroduction Facade Decorator Composite Adapter Flyweight Proxy 15/30


etc.

NonLeafNodedoIt() component

Componentadd( Component )

doIt()

LeafNodedoIt()

TypeANonLeafNodedoIt()

TypeBNonLeafNodedoIt()

1..nClient

FOR ALL elements e in component e.doIt()

Composite Class ModelIntroduction Facade Decorator Composite Adapter Flyweight Proxy 16/30


Employee HierarchyPete

:President

Able:Manage

r

Becky:Manage

rLonn

y:Teller

Cal:Cler

k

Tina:Telle

r

Thelma

:Teller

We need to add and remove employees at runtime and execute operations on all of them.

KEY CONCEPTDesign Goal : Flexibility, Correctness



reports

1..n

Setup

EmployeestateName()

ClerkstateName()

PresidentstateName()

Supervisoradd(Employee)

TellerstateName()

ManagerstateName()

Client

Bank/Teller ExampleIntroduction Facade Decorator Composite Adapter Flyweight Proxy 18/30


Component

Container

Window … . .

component

1..n

Canvas

Composite in java.awt (Fig 8.24)

Comments on Composite Decorator is a special case of Composite Decorator intention is different: add

responsibilities at runtime.



Adapter Design Pattern Design Purpose

Allow an application to use external functionality in a retargetable manner.

Design Pattern Summary Write the application against an abstract version

of the external class; introduce a subclass that aggregates the external class.

8.5

-- to interface flexibly with external functionality.

KEY CONCEPTAdapter Design Pattern



Adapter ExampleIntroduction Facade Decorator Composite Adapter Flyweight Proxy 21/30


Financialamount()

PrinciplecomputeValue()

Client

Legacy systemAdaptationApplication

We want to separate the application as a whole from financial calculations which will be performed externally.

KEY CONCEPTDesign Goal : Flexibility and Robustness

Adapter Design Pattern (Fig 8.29)

FinantialAdapteramount()



Flyweight Design Pattern Design Purpose

Manage a large number of objects without constructing them all.

Design Pattern Summary Share representatives for the objects; use

context to obtain the effect of multiple instances.

8.6

Flyweight

FlyweightdoAction(Context)

ConcreteFlyweightdoAction(Context)

FlyweightFactorygetFlyweight(Characteristic)

Client

1..n

(Figure 8.33)



Comments on Flyweight Flyweight is to some extent a retreat from

full object-orientation: by not treating every instance as a truly separate object, we can bring “less” object-oriented, and we do thus lose some benefits.

-- to obtain the benefits of a large set of individual objects without efficiency penalties.

KEY CONCEPTFlyweight Design Pattern



Proxy Design Pattern

Design Purpose Avoid the unnecessary execution of expensive

functionality in a manner transparent to clients.

Design Pattern Summary Interpose a substitute class which accesses the

expensive functionality only when required.



AdaptationBaseActiveClassexpensiveMethod()anotherMethod()

RealActiveClassexpensiveMethod()anotherMethod()

Client

realActiveObject

. . . // One way to check if really needed:if ( realActiveObject == null ) // never referenced{ realActiveObject = getRealActiveObject(); realActiveObject.expensiveMethod(); }else // try to avoid calling the real expensiveMethod()

ProxyexpensiveMethod()anotherMethod()

Instantiate withProxy object

Proxy Design PatternIntroduction Facade Decorator Composite Adapter Flyweight Proxy 26/30


realExpensiveMethod()

:Client

expensiveMethod()

:Proxy :RealActiveClass

( if needed: )

Sequence Diagram for Proxy

-- Avoid unnecessary data downloads.-- to call expensive or remote methods.

KEY CONCEPTDesign Goal : Efficiency and Reuse



TelNumsvalue: Vector

getTelNums(): VectorshowMiddleRecord()

RemoteTelNumsgetTelNums()

TelephoneAppdisplay( TelNums )

display MiddleRecord()

remoteTelNums

. . . // One way to check if really needed:if ( value == null ) // never referenced

remoteTelNums.getTelNums(); else // no need to call ‘getTelNums()’

TelNumsProxygetTelNums()

static

1

Setup

Ensures that TelephoneApp makes calls with TelNumsProxy instance

Proxy Example (Figure 8.44)Introduction Facade Decorator Composite Adapter Flyweight Proxy 28/30


Comments on Proxy Proxy promotes efficiency:

Avoids time-consuming operations when necessary

The penalties we pay can sometimes be too high: If the proxy forces us to keep very large amount of data in

the memory and its use is infrequent.

Proxy promotes: Correctness: separate design and code that are

independent of retrieval/efficiency from parts concerned with this issue.

Reusability: design and code that are independent of retrieval efficiency are most likely to be reusable.

Flexibility: we can replace one module concerned with retrieval with another

Robustness: proxy isolates parts that check for the validity of retrieved data.



Summary of Structural Patterns Structural Design Patterns relate objects

(as trees, lists etc.) Facade provides an interface to collections of

objects Decorator adds to objects at runtime Composite represents trees of objects Adapter simplifies the use of external

functionality Flyweight gains the advantages of using

multiple instances while minimizing space penalties

Proxy avoids calling expensive operations unnecessarily


Lecture 14 Structural Design Patterns

Documents

Transcript of Lecture 14 Structural Design Patterns