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

Software design: Lecture 27 - 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 (1.18 MB, 32 trang )

1

Software Design
Lecture : 27


2

Motivation for Design Pattern
 Employee  A  works  for  a  company  which  makes  simulation  game 
with name of “SimUDuck”

 The  game  show  variety  of  ducks  which  can  swim  and  quacking 
sounds.

 The  initial  software  designer  of  the  software  apply  basic  design 
principles and come up with a class diagram as shown in next slide


3


4

Problem
 Due  to  intense  pressure  from  the  market  forces  the 
management  needs  an  innovative  features  to  have  an 
competitive edge over the competitors. 


5



Solution
 Management  decides  to  hold  series  of  brainstorming 
sessions to find out of the box solution

 Finally  they  come  up  with  a  feature  to  show  the  flying 
ducks along with other ducks 


6

This is what the we wants!!


7

Employee A Thinks:
 It’s nothing, after all I am OO Designer, all I need to do is 
to  add  fly  method  in  super  class  Duck  and  all  the 
subclasses will inherit it.

 Its just a work of not more than a week!!!

 Wow that’s the greatness of OOAD


8

Class Diagram Proposed by Joe



9

Problem in the Proposed Solution
 What Joe fail to understand is that not all the ducks fly 
i­e rubber duck etc but fly method is available for all the 
subclasses.


10

Root Cause
 A  localized  update  in  the  code  is  having  non­local  side 
effects (rubber duck)

 Rubber  duck  also  don’t  quack  so  quack  must  be 
overridden to squeak . Improved version on next slide


11


12

Problem
 Joe  thinks  that  he  can  just  override  the  fly  method  in 
rubber duck class as in case of quack but fly method will 
do nothing !!

 But what if a new type of duck to be added which is not 

suppose  to  fly  or  quack    i­e  Wooden  Decoy  duck;  as 
shown in next slide


13


14

Another Problem
 Joe  just  received  an  memo  that  product  features  will  keep  on 
changing at regular interval so he needs to keep his fingers cross all 
the  times  or  rethink  his  decision  about  inheritance,  because  it 
may  happen  that  he  will  be  forced  to  override  fly  and  quack 
method for every new duck subclass.

 He needs a cleaner solution to handle the situation in which some of 
the duck types may fly or quack not all!!


15

Innovative Solution
• Instead of using Inheritance Joe decides to go 
with Interfaces.
• There should be two interfaces i­e Flyable and 
Quackable; classes will implements as required.


16


Any Problem with  Solution below


17

Maintenance Nightmare
 Introduction of Interfaces will destroy code reuse

 When ever a change is needed, you need to track down 
the class which implements that behavior i­e flyable; and 
that will introduce more bugs!!

 At this point you might be thinking that something magical 
should occur to solve the problem


18


19

Design Techniques 
 Seperation of interface and Implementation

 Identify the aspects of the application which varies and 
separate them from what stays the same 

 Encapsulate the varied code so it’s not effected with 
change.



20

Applying Rule to Duck Class


21

Magical Solution: Design Patterns
 Open  /  Close  Principle  and  Separation  of  Interface  and 
Implementation  forms  the  basis  of  almost  all  the  design 
patterns


22

What are Patterns – Inspiration from Buildings
 During  the  late  1970s,  an  architect  named  Christopher 
Alexander  carried  out  the  first  known  work  in  the  area  of 
patterns.

 Alexander and his colleagues studied different structures 
that were designed to solve the same problem

 He identified similarities that exists among quality designs


23


Design Patterns
 In  1987,  influenced  by  the  writings  of  Alexander,  Kent 
Beck  and  Ward  Cunningham  applied  the  architectural 
pattern ideas for the software design and development.

 In  1994,  the  publication  of  the  book  entitled  Design  Patterns: 
Elements of Reusable Object­Oriented Software on design patterns 
by  Erich  Gamma,  Richard  Helm,  Ralph  Johnson  and  John  Vlissides 
explained the usefulness of patterns and resulted in the widespread 
popularity for design patterns


24

What are Design Patterns ??
“Some body has already solve your problem”
 A design pattern is a documented best practice or core of a solution 
that has been applied successfully in multiple environments to solve 
a problem that recurs in a specific set of situations.

 It is “a recurring solution to a common problem in a given context 
and system of forces.”


25

Design Patterns – Language Independent 
 A design pattern is an effective means to convey/communicate what has
been learned about high­quality designs. The result is:


–  A  shared  language  for  communicating  the  experience  gained  in 
     dealing with these recurring problems and their solutions.

–  A  common  vocabulary  of  system  design  elements  for  problem        
solving  discussions.  A  means  of  reusing  and  building  upon  the 

      

acquired insight resulting in an improvement in the software quality       in 
terms of its maintainability and reusability.


×