5-Structural Design Patterns.ppt

Design Pattern 6Object oriented adapters Your Existing System Vendor Class Adapter The adapter implements the interface your classes expect Your Existing System Vendor Class Adapter No c

Design Pattern 1

Structural design patterns

Design Pattern 3

The Adapter Pattern

Putting a Square Peg in a Round Hole!

Design Pattern 4

What is Adapters

 Real world is full of them!

Design Pattern 5

Object oriented adapters

 Scenario: you have an existing software system that you need to work a new vendor library into, but the new vendor designed their interfaces

differently than the last vendor.

 What to do? Write a class that adapts the new vendor interface into the one you’re expecting.

Your Existing System

Vendor Class

Their interface doesn’t match the one you’ve written your code against Not going to work!

Design Pattern 6

Object oriented adapters

Your Existing System

Vendor Class Adapter

The adapter implements the interface your classes expect

Your Existing System

Vendor Class Adapter

No code changes New code No codechanges

And talks to the vendor interface to service your requests

Design Pattern 7

The Adapter Pattern - Intent

The client sees only the

target interface

All requests get delegated to the Adaptee

Adapter is composed with the Adaptee

Full of good OO design principles:

- Use of object composition

- Pattern binds the client to an interface and not an implementation

Full of good OO design principles:

- Use of object composition

- Pattern binds the client to an interface and not an implementation

 The Adapter Pattern converts the interface of a class into

another interface the clients expect Adapter lets classes

work together that couldn’t otherwise because of

incompatible interfaces

Object Adapter

Design Pattern 8

Object and Class Adapters

 Object Adapter : use composition to adaptive the adaptee

 Class Adapter : use inheritance.

Class Adapter

Design Pattern 9

Applicability

 Use the Adapter pattern when

 want to use an existing class, and its interface does not match the one you need

 want to create a reusable class that cooperates with

unrelated or unforeseen classes that don't necessarily have compatible interfaces

 Class and object adapters have different

trade-offs

 A class adapter won't work when we want to adapt a class and all its subclasses

 An object adapter lets a single Adapter work with the

Adaptee itself and all of its subclasses (if any)

Design Pattern 10

Example

Turkey has a incompatible interface with Duck We’d like to use some Turkey

as Duck

Design Pattern 11

Write Adapter

implements the interface of the Target, and get a reference to adaptee

Design Pattern 12

Using two-way adapters to provide transparency

Design Pattern 13

Example: Adapting an Enumeration to

an Iterator

Target interface Adaptee interface

We are making the Enumeration in your old code look like Iterator for your new code.

Design Pattern 15

Summary

 When you need to use an existing class and its interface is not the one you need, use an adapter.

 An adapter changes an interface into one a client expects.

great deal of work depending on the size and complexity of the target interface.

adapters Class adapters require multiple inheritance.

 An adapter wraps an object to change its interface, a

decorator wraps an object to add new behaviors and

responsibilities

Design Pattern 16

The Façade Pattern

Simplify, simplify, simplify!

Design Pattern 17

The Facade Pattern – Key Features

 Problem

 Need to use only a subset of a complex system

 Or you need to interact with the system in a particular way

 Façade Pattern 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

 implement subsystem functionality

 handle work assigned by the Facade object

 have no knowledge of the façade

Design Pattern 20

The Facade Pattern – Applicability

Use the Facade pattern when

 want to provide a simple interface to a complex subsystem

 decouple the subsystem from the dependencies of clients and other subsystems, thereby promoting subsystem independence and portability

 want to layer your subsystems Use a facade to define an entry point to each subsystem level

Design Pattern 21

Example - Home Sweet Home Theater

That’s a lot of classes, a lot of interactions, and

a big set of interfaces to learn and use.

Design Pattern 22

Watching a Movie the Hard Way!

1 Turn on the popcorn popper

2 Start the popper popping

3 Dim the lights

4 Put the screen down

5 Turn the projector on

6 Set the projector input to DVD

7 Put the projector on wide-screen mode

8 Turn the sound amplifier on

9 Set the amplifier to DVD input

10 Set the amplifier to surround sound

11 Set the amplifier volume to medium (5)

12 Turn the DVD player on

13 Start the DVD player playing.

14 Whew!

But there’s more!

When the movie is done,

- how do you turn everything off?

- Do you reverse all the steps?

Façade to the Rescue!!

Design Pattern 24

Example explain

subsystem, and calls on the subsystem to implement its

components for the client It keeps the client simple and flexible.

Design Pattern 25

Summary

complex set of interfaces, use a façade.

façade with its subsystem and use delegation to perform the work of the façade.

 A façade "wraps" a set of objects to simplify!

Design Pattern 26

Bridge Pattern

Design Pattern 27

Motivating Example

Write a program that

DP1 or DP2

program to use.

differences are presented in the following table

program

to draw a circle draw_a_circle(x, y, r) draw_circle(x, y, r)

to draw a line draw_a_line(x1, y1, x2, y2) draw_line(x1, x2, y1, y2)

Design Pattern 28

Motivating Example

 First idea for design: since the type of drawing program is told at the time of instantiating rectangles, we could have two types of rectangles, one that uses DP1 and other that uses DP2

A straightforward design using

inheritance, solves the

problem

… but requirements change

– Also Circles must be

supported

Design Pattern 30

The Motivating Example

 redundancy, low cohesion, things are tightly coupled

 would you want to maintain the code?

(drawing programs) are tightly coupled

 each type of shape must know what type of drawing program it is

using

 two variabilities inside different commonalities are coupled via

inheritance

from variations in implementation so that the number of classes only grow linearly

Design Pattern 31

Let’s apply commonality/variability thinking:

 Shapes encapsulates

the concept for knowing

how to draw themselves

 Drawing programs are

responsible for drawing

lines and circles

 for Shape, there are rectangles and circles

 for drawing programs, there are V1Drawing (based on DP1) and V2Drawing (based on DP2)

The Motivating Example

Design Pattern 32

The Motivating Example

 By representing the variability with derived classes we get

Design Pattern 33

The Motivating Example

implementation in a way that the two can vary

independently

 Abstractions and their implementations should be

independently extensible by subclassing

 Hide the implementation of an abstraction completely from clients

Design Pattern 35

Structure

defines the abstraction's interface maintains a

reference to an object of type Implementor

Design Pattern 36

Implementation

 Only one Implementor

 not necessary to create an abstract implementor class

 degenerate, but useful due to decoupling

 Which Implementor should I use ?

 Variant 1: let Abstraction know all concrete implementors and choose

 Variant 2: choose initially default implementor and change later

 Variant 3: use an Abstract Factory

 no coupling between Abstraction and concrete implementor classes

Design Pattern 37

Composite Pattern

Design Pattern 38

The Composite Pattern Defined

Root folder PancakeHouseMenu

The Composite Pattern allows you to compose objects into tree

structures to represent whole-part hierarchies Composite lets clients

treat individual objects and composition of objects uniformly.

Design Pattern 39

Composite Pattern Structure

The client uses

The Component may implement a default behavior for add(), remove(), getChild() and its operations.

Note that the leaf

also inherits methods

like add(), remove(),

and getChild(), which

don’t make a lot of

sense for a leaf node.

A leaf has no children

A Leaf defines the behavior

for the elements in the

composition It does this by

implementing the operations

the Composite supports. The Composite’s role is to define the

behavior of the components having children and to store child components

The Composite also implements the Leaf-related operations Note that some of these may not make sense

on a Composite so in that case an exception might be generated.

Design Pattern 40

Decorator Pattern

Design Pattern 41

Decorator Pattern Defined

defines the interface for

objects that can have

can adds responsibilities

to the component

Decorators can

extend the state of

the component

The Decorator Pattern attaches additional responsibilities to an object

dynamically Decorators provide a flexible alternative to subclassing for extending functionality.

Design Pattern 42

Proxy Pattern

Design Pattern 43

The Proxy Pattern

Both the Proxy and the RealSubject implement the Subject interface This allows any client to treat the proxy just like the RealSubject.

The RealSubject is usually the object that does most

of the real work; the Proxy controls access to it.

The Proxy often instantiates

or handles the creation of the RealSubject

The Proxy keeps a

reference to the

Subject, so that it

can forward requests

to the subject when

necessary.

The Proxy Pattern provides a surrogate or placeholder for another object to control access to it

Design Pattern 44

Dynamic Proxy

The Proxy now consists

of 2 classes

The Proxy is generated by Java and implements the entire Subject interface

You supply the InvocationHandler, which gets passed all method calls that are invoked on the Proxy The InvocationHandler controls access

to the methods of the RealSubject.

Design Pattern 45

Flyweight Pattern

Design Pattern 46

Flyweight

Use the Flyweight Pattern when one instance of a class

can be used to provide many “virtual instances” Use

sharing to support large numbers of fine-grained objects efficiently

Client

Design Pattern 47

Flyweight

 A flyweight is a shared object that can be used in multiple contexts simultaneously

 Flyweights have intrinsic and extrinsic state

 Intrinsic state is stored in the flyweight; it consists of

information that's independent of the flyweight's context, thereby making it sharable

 Extrinsic state depends on and varies with the flyweight's context and therefore can't be shared

 Client objects are responsible for passing extrinsic state to the flyweight when it needs it.