Chapter 5: Structural Design Patterns

Objectives
S. No Topic PPT Slides

To introduce structural design patterns

1. Decorator 2. Faade L1 L2 3 20 21 27

3. Proxy
4. Flyweight 5. Repeated key points for Structural Patterns

L3
L4 L5

28 40
41 47 48 52

6. (Intent, Motivation, Also Known As )

7. Review Unit-V

L6
L7

53 57
58 58

L1

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.

L1

Decorator: Class Model

Decorator creates an aggregated linked list of Decoration objects ending with the basic Substance object.

L1

Pattern: Decorator
objects that wrap around other objects to add useful features

L1

Decorator pattern
decorator: an object that modifies behavior of, or adds features to, another object
decorator must maintain the common interface of the object it wraps up

used so that we can add features to an existing simple object without needing to disrupt the interface that client code expects when using the simple object examples in Java:
multilayered input streams adding useful I/O methods adding designs, scroll bars and borders to GUI controls

Decorator example: I/O

L1

normal InputStream class has only public int read() method to read one letter at a time decorators such as BufferedReader or Scanner add additional functionality to read the stream more easily
// InputStreamReader/BufferedReader decorate InputStream InputStream in = new FileInputStream("hardcode.txt"); InputStreamReader isr = new InputStreamReader(in);

BufferedReader br = new BufferedReader(isr);

// because of decorator streams, I can read an // entire line from the file in one call // (InputStream only provides public int read() ) String wholeLine = br.readLine();

L1

Decorator example: GUI

normal GUI components don't have scroll bars JScrollPane is a container with scroll bars to which you can add any component to make it scrollable
// JScrollPane decorates GUI components JTextArea area = new JTextArea(20, 30); JScrollPane scrollPane = new JScrollPane(area); contentPane.add(scrollPane);

L1

An example: Decorator
Intent: Allow to attach responsibilities to objects, extend their functionality, dynamically Motivation: Consider a WYSIWYG editor The basic textWindow needs various decorations: borders, tool bars, scroll bars,

L1

An obvious solution: sub-classing A sub-class for every option

Disadvantages: Sub-classing is static compile-time # of sub-classes = # of combinations exponential

L1

The preferred solution: Use decorator objects

Each decorator adds one decoration property, behavior Linear Can add more than one, to obtain combinations of properties And, do it dynamically

L1

Structure, participants, collaborations: Component an interface, describes the operations of a (GUI) component
ConcreteComponent (extends Component)

class of objects to which decorations can be added (e.g. the original TextWindow)
Decorator (extends Component) a class of

decorator objects (there are several such classes)

L1

Implementation:
Each decorator has a (private) reference to a Component object (CC or D) For each operation, the decorator performs its decoration job, & delegates Component operations to the Component object it contains
Decorator extends Component (can accept
Component requests)

L1

Decorators can perform all the operations of Component, often more

Decorators can be combined :
D3 D2 D1 CC

(but some combinations may hide some functionalities)

L1

The decorator pattern

<<Interface>> Component

Decorator

ConcreteComponent

Various decorators

L1

Consequences : Decoration can be done dynamically, at run-time When it makes sense, a decoration can be added several times The # of decorators is smaller than the # of sub-classes in original solution; avoids lots of feature-heavy classes in the inheritance hierarchy

L1

Issues to remember : A decorator and the Component object it contains are not identical Many small objects; one has to learn their roles, the legal connections, etc.
(but, still much better than sub-classing)

L1

Decorators in a java library: Stream decorators

A byte stream r or w bytes Decorators add: Buffering (does not add services) r or w primitive types, objects, (adds
services)

L1

Lessons from Decorator

More dynamic, flexible, less expensive Composition is (often) superior to sub-classing

Program to interfaces, not to concrete classes

L1

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

L2

Faade (2)
Example: graph interface to a simulation engine

SchematicEditor Graph
2

Director

Relation

Port

0..*

Entity
CompositeEntity

BufferedRelation

AtomicEntity Actor

Token

Facade: Encapsulating Subsystems

Name: Facade design pattern Problem description: Reduce coupling between a set of related classes and the rest of the system.

L2

Solution:
A single Facade class implements a high-level interface for a subsystem by invoking the methods of the lower-level classes.

Example. A Compiler is composed of several classes: LexicalAnalyzer, Parser, CodeGenerator, etc. A caller, invokes only the Compiler (Facade) class, which invokes the contained classes.

Facade: Class Diagram

Facade

L2

Facade
service()

Class1 service1()

Class2 service2()

Class3 service3()

Facade: Consequences
Consequences:

L2

Shields a client from the low-level classes of a subsystem.

Simplifies the use of a subsystem by providing higher-level methods.

Enables lower-level classes to be restructured without changes to clients.

Note. The repeated use of Facade patterns yields a layered system.

L2

Facade: Motivation

Clients communicate with the package (subsystem ) by sending requests to Facade, which forwards them to the appropriate package object(s).

L2

Facade: Applicability
To provide simple interface to a complex package, which is useful for most clients. To reduce the dependencies between the client and the package, or dependencies between various packages.

L2

Facade: Consequences
It shields clients from package components, thereby reducing the number of objects that clients deal with and making the package easier to use.

It promotes weak coupling between the package and its clients and other packages, thereby promoting package independence and portability.

L3

Proxy
You want to
delay expensive computations, use memory only when needed, or check access before loading an object into memory

Proxy
has same interface as Real object stores subset of attributes does lazy evaluation

Proxy Design Pattern

Design Purpose
Avoid the unnecessary execution of expensive functionality in a manner transparent to clients.

L3

Design Pattern Summary

Interpose a substitute class which accesses the expensive functionality only when required.

L3

Proxy: Class Model

L3

Proxy: Class Model

L3

Telephone Record Example

Telephone Record Example

(Contd)

L3

Proxy: Consequences
Proxy promotes:

L3

Efficiency: avoids time-consuming operations when necessary. Correctness: separates 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: isolates parts that check for the validity of retrieved data.

Proxy: Encapsulating Expensive Objects

Name: Proxy design pattern Problem description: Improve performance or security of a system by delaying expensive computations, using memory only when needed, or checking access before loading an object into memory. Solution: The ProxyObject class acts on behalf of a RealObject class. Both implement the same interface. ProxyObject stores a subset of the attributes of RealObject. ProxyObject handles certain requests, whereas others are delegated to RealObject. After delegation, the RealObject is created and loaded into memory.

L3

Proxy: Class Diagram

Client

L3

Object filename op1() op2()

ProxyObject filename op1() op2()

0..1

RealObject data:byte[] op1() op2()

L3

Proxy: Consequences
Consequences:

Adds a level of indirection between Client and RealObject.

The Client is shielded from any optimization for creating RealObjects.

L3

Pattern Hatching
Proxy Pattern
Subject request() realSubject->request();

RealSubject request()

realSubject

Proxy request()

L3

Pattern Hatching
Proxy Pattern
We need to find a common structure for the proxy pattern with our composite pattern As we recognize, our common interface that we still want to use for the file-system is Node And because the Composite structure uses a common interface already, we can combine the Proxy Subject Interface into our Node Interface

L3

Pattern Hatching
Node

Proxy Pattern
subject

Link streamIn(istream) streamOut(ostream) getSubject()

File streamIn(istream) streamOut(ostream)

Directory streamIn(istream) streamOut(ostream) getChild(int) adopt(Node) orphan(Node)

children

getName() streamIn(istream) streamOut(ostream) getChild(int) adopt(Node) orphan(Node)

Composite Pattern

L4

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.

L4

Flyweight: Class Model

L4

Flyweight: Sequence Diagram

L4

Text Magnifier Example

L4

Text Magnifier Example (Contd)

L4

Text Magnifier Example (Contd)

L4

Flyweight: Consequences
Space savings increase as more flyweights are shared.

L5

An example: Decorator
Intent: Allow to attach responsibilities to objects, extend their functionality, dynamically Motivation: Consider a WYSIWYG editor The basic textWindow needs various decorations: borders, tool bars, scroll bars,
UNIT-V 48

L5

An obvious solution: sub-classing A sub-class for every option

Disadvantages: Sub-classing is static compile-time # of sub-classes = # of combinations exponential

UNIT-V

49

L5

The preferred solution: Use decorator objects

Each decorator adds one decoration property, behavior Linear Can add more than one, to obtain combinations of properties And, do it dynamically

UNIT-V

50

L5

Structure, participants, collaborations: Component an interface, describes the operations of a (GUI) component
ConcreteComponent (extends Component)

class of objects to which decorations can be added (e.g. the original TextWindow)
Decorator (extends Component) a class of

decorator objects (there are several such classes)

UNIT-V

51

L5

Implementation:
Each decorator has a (private) reference to a Component object (CC or D) For each operation, the decorator performs its decoration job, & delegates Component operations to the Component object it contains
Decorator extends Component (can accept
Component requests)

UNIT-V

52

L6

Facade 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. UNIT-V 53

L6

Faade (2)
Example: graph interface to a simulation engine

SchematicEditor Graph
2

Director

Relation

Port

0..*

Entity
CompositeEntity

BufferedRelation

AtomicEntity Actor
UNIT-V

Token

54

Facade: Encapsulating Subsystems

Name: Facade design pattern Problem description: Reduce coupling between a set of related classes and the rest of the system.

L6

Solution:
A single Facade class implements a high-level interface for a subsystem by invoking the methods of the lower-level classes.

Example. A Compiler is composed of several classes: LexicalAnalyzer, Parser, CodeGenerator, etc. A caller, invokes only the Compiler (Facade) class, which invokes the contained classes. UNIT-V 55

Facade: Class Diagram

Facade

L6

Facade
service()

Class1 service1()

Class2 service2()

Class3 service3()

UNIT-V

56

Facade: Consequences
Consequences:

L6

Shields a client from the low-level classes of a subsystem.

Simplifies the use of a subsystem by providing higher-level methods.

Enables lower-level classes to be restructured without changes to clients.

Note. The repeated use of Facade patterns yields a layered system.

UNIT-V

57

Summary of Structural Design 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

L7