Software design: Lecture 35 - Sheraz Pervaiz

Software design - Lecture 35. The main topics covered in this chapter include: façade design pattern; scenario – building a movie theatre; classes in building home theatre; simplified class diagram; client access without facade; class diagram of facade;...

Lecture : 35

1

Façade Design Pattern

Theatre

7

Simplified Class Diagram

 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

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

11

13

Class Diagram of Facade

Principle

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

Rules Explained with Example

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

        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.

 Build an application which perform the following  tasks

23

25

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

Lecture : 36

27

Composite  Design Pattern

29

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

relation

31

33

Example

35

Tree Structure Revisited 

 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

37

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.

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 

FileSystemComponent interface as shown in next slide

41

 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

43

 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

 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

45

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

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

objects

47

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.

 Client to keep track when calling a non­common  method like addcomponent and getcomponent as  these methods exists only in DirComponent

49

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