1

Design Pattern

Lecture : 11
 2

Façade Design Pattern

 3

Scenario – Building a Movie Theatre

 You have decided to build your own home theatre
compromising of the some what following components:

i. DVD Player
ii.Sound Systems
iii.Amplifiers
iv.Projector
v.Screen
vi.CD Player
vii.Theatre Lights etc

 You have spend a lot of time making all the connections

to make it work
 4

Classes in Building Home Theatre

 5

Steps in Watching the Movie

i. Dim the lights
ii. Turn the projector on
iii. Connect DVD to Projector
iv. Turn on the sound Amplifier on
v. Connect Amplifier input to DVD
vi. Adjust the sound
vii. Set the DVD Player on
viii.Watch the movie

 Exhausted !!! Is it that difficult to watch a movie

 Think about turning off the Home Theatre
6
 7

Need for Simplicity

 At this point in time Façade is what you need

 Façade let you use the complex system by providing a

simple interface to use the complex sub systems

 Power of subsystems is still there but the complexity is

reduced by availability of simpler interface to interact
with
 8

Simplified Class Diagram

9
 10

Façade Design Pattern Defined

Façade provides a unified interface to a

set of interfaces in a subsystem. It define
a higher level interface which is easier to
use
 11

Façade Design Pattern continue…

 Façade decouple the client from interacting with the
subsystems instead Façade take up the responsibility of
dealing with the subsystems itself.

 Façade will not add any extra functionality it will just simply
the access to functionality.

 Client can also access subsystems directly as if there is no

Façade.
 12

Client Access without Facade

 13

Client Access with Facade

 14

Class Diagram of Facade

15
 16

New Software Design Principle

The Principle of Least Knowledge

“Talk only to your immediate friends”

 When creating software design for any object be careful

of the number of classes it is interacting with and how it
will be interacting with them
 17

Guidelines for Implementing Principle

 Suppose we have an object with several methods, now
for that object we should invoke methods only that
belongs to:

i. An Object itself
ii.Object passed in as a parameter
iii.Any method that object creates or instantiates.
iv.Any component of the Object
 18

Rules Explained with Example

19
 20

• Engine  Rule Number 4 (Composition between

car and engine) engine is component not object.
• Public void start(Key key)  Rule Number 2
• Door.lock(); 
 21

Applying Principle in Facade

There can be several Façade within One Façade

with the increase in complexity.

We aim to maintain minimum possible

communication with other classes.
22
 23

Example
For an typical online transaction oriented system,
customer can perform transactions against an account i-e
Pay pal etc; credit card validators are used for verifying the
creditionals of a client submitted by the client for checkout
purposes. Address of the customer is also stored and
checked for data entry checks for shipment purposes.
Usually account, address and credit card subsystems works
together to provide the feature of online transaction.
 24

To Do Tasks:
Build an application which perform the
following tasks

i. Accepts customer details (account, address and credit

card details)
ii. Validates the input data
iii. Saves the input data to appropriate data files
 Assuming there are three classes and each class is having
its own validation and data storage mechanism
 25

Sequence Diagram of System

 26

Sequence Diagram with Facade

 27

• I want you people write the code…

• Class work = 20 minutes
 28

Advantages of Facade
 It shields the client from subsystem components, thereby
reducing the number of objects that clients have to deal with.

 It promote weak coupling between the subsystems and its

client.

 Clients can directly access subsystems also, it provide choice

between ease use and generality
 29

Design Pattern

Lecture : 12
 30

Composite Design Pattern

 31

Motivation for Composite Design Pattern

Every component or object can be classified into one

of the two categories —

i. Individual Components
ii.Composite Components — which are composed of
individual components or other composite
components
 32

Intend of Composite Design Pattern

 To have a common interface for both individual and

composite components so that client programs can view
both the individual components and groups of
components uniformly.

 Usually a Tree structure having nodes and leave nodes

represents composite and individual components
respectively.
 33

Discussion on Whole-Part relation

 34

Aggregation or “ has –a “ relationship

 Specialized form of association i-e Weak Association.

 Assembling a class from other classes.

 Aggregation is a special type of relationship used

to model a "whole to its parts" relationship

 Part class is independent from the whole class's

lifecycle.
 35

Aggregation
In an aggregation relationship, the child class
instance can outlive its parent class.

Child class can be a part of multiple parent classes.

To represent an aggregation relationship, you draw

a solid line from the parent class to the part class,
and draw an unfilled diamond shape on the parent
class's association end
 36

Example
 37

Aggregation Example
 38

Tree Structure Revisited

 39

Composite Pattern Defined

 Composite Design pattern allow us to compose

objects into tree structures to represent whole-

part hierarchy . It let the client handle the

composite and individual components in a

uniform manner
 40

Class Diagram of Composite Design

Pattern
41
 42

Example of Composite Pattern

 Let us create an application to simulate the

Windows/UNIX file system. The file system consists
mainly of two types of components — directories and
files. Directories can be made up of other directories or
files, whereas files cannot contain any other file system
component. In this aspect, directories act as nonterminal
nodes and files act as terminal nodes or leaf node of a
tree structure.
 43

Design Approach
 Let us define a common interface for both directories
and files in the form of a Java interface
FileSystemComponent The FileSystemComponent
interface declares methods that are common for both file
components and directory components. Let us further
define two classes — FileComponent and DirComponent
— as implementers of the common
FileSystemComponent interface as shown in next slide
 44

Class Diagram of Proposed Approach

 45

Description of Classes
FileComponent
The FileComponent class represents a file in the file
system and offers implementation for the following
methods.

getComponentSize()

• This method returns the size (in kilobytes) of the file

represented by the File- Component object.
 46

Class Descriptions
DirComponent

This class represents a directory in the file system. Since

directories are composite entities, the DirComponent
provides methods to deal with the components it
contains. These methods are in addition to the common
getComponentSize method declared in the
FileSystemComponent interface.
 47

Class Description
addComponent(FileSystemComponent)
This method is used by client applications to add different
DirComponent and FileComponent objects to a
DirComponent object.

 getComponent(int)

The DirComponent stores the other FileSystemComponent

objects inside a vector. This method is used to retrieve one
such object stored at the specified location.
 48

Class Description
getComponentSize()

This method returns the size (in kilobytes) of the

directory represented by the DirComponent
object. As part of the implementation, the
DirComponent object iterates over the collection
of FileSystemComponent objects it contains, in a
recursive manner, and sums up the sizes of all
individual FileComponents. The final sum is
returned as the size of the directory it represents.
 49

Processing of Class Diagram

A typical client would first create a set of
FileSystemComponent objects (both DirComponent and
FileComponent instances). It can use the addComponent
method of the DirComponent to add different
FileSystemComponents to a DirComponent, creating a
hierarchy of file system (FileSystemComponent)
objects.
 50

Calculating the Size of Object

When the client wants to query any of these objects for its size, it
can simply invoke the getComponentSize method. The client
does not have to be aware of the calculations involved or the
manner in which the calculations are carried out in
determining the component size. In this aspect, the client
treats both the
FileComponent and the DirComponent object in the same
manner. No separate code is required to query FileComponent
objects and DirComponent objects for their size.
 51

Problem in Current Design

Client to keep track when calling a non-common

method like addcomponent and getcomponent

as these methods exists only in DirComponent

 52

Design Approach -II

Provide the same advantage of allowing the client
application to treat both the composite DirComponent
and the individual FileComponent objects in a uniform
manner while invoking the getComponentSize method
53
 54

• public abstract class FileSystemComponent {

• String name;
• public FileSystemComponent(String cName) {
• name = cName;
• }
• public void addComponent(FileSystemComponent component)
• throws CompositeException {
• throw new CompositeException(
• "Invalid Operation. Not Supported");
• }
• public FileSystemComponent getComponent(int componentNum)
• throws CompositeException {
• throw new CompositeException(
• "Invalid Operation. Not Supported");
• }
• public abstract long getComponentSize();
• }//End of class FileSystemComponent
 55

Code in Word File