Tải bản đầy đủ (.pdf) (53 trang)

Software design: Lecture 35 - Sheraz Pervaiz

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (866.62 KB, 53 trang )

1

Software Design
Lecture : 35


2

FaỗadeDesignPattern


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


6

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


7

NeedforSimplicity
AtthispointintimeFaỗadeiswhatyouneed

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ỗadeDesignPatternDefined

Faỗadeprovidesaunifiedinterfacetoasetof
interfaces in a subsystem. It define a higher
levelinterfacewhichiseasiertouse


11

FaỗadeDesignPatterncontinue
Faỗade decouple the client from interacting with the
subsystems instead Faỗade take up the responsibility of
dealingwiththesubsystemsitself.


Faỗade will not add any extra functionality it will just
simplytheaccesstofunctionality.

Clientcanalsoaccesssubsystemsdirectlyasifthereisno
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


ApplyingPrincipleinFacade
There can be several Faỗade within One Faỗade
withtheincreaseincomplexity.

We aim to maintain  minimum  possible 
communication with other classes.


21


22

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.


23

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


24

Sequence Diagram of System


25

Sequence Diagram with Facade


×