Design Patterns                                   Chapter 8Object-Oriented Software Systems Engineering – Chapter 8   Slid...
Objectives In this chapter we will:  Discuss why software design patterns evolved  Define and describe a software design...
Design Patterns – An Introduction  Objectives     Understand why software design patterns evolved     Define and descri...
Why patterns?  designing reusable software is hard  novices are overwhelmed  experts draw from experience  some design...
Why patterns?                “Wisdom is often ascribed to those                    who can tell just the right story      ...
What is a pattern?Occurrence  chess                                 from rules to expertise  literature                 ...
Architectural PatternsLight from two sides                                                           Place at             ...
What is a pattern?    “Each pattern describes a problem which occurs          over and over again in our environment,     ...
What is a pattern?Patterns are proven   “Aggressive disregard for originality”   Rule of three           “Once is an eve...
The Origins of Design Patterns  They originate from the work of Christopher   Alexander, a building architect in the 1970...
From Buildings to Software  Alexander’s work ‘discovered’ by Kent Beck and    friends in the 1980’s.  They applied Alexa...
What is a software pattern?  proven software practice  piece of literature  building block  possible abstraction level...
What is a Design Pattern?  A design pattern is defined as ‘ a description of   communicating objects and classes that are...
What is a software pattern?     “A methodology tells you how to write down the                  decisions you have made.  ...
GRASP Patterns  General Responsibility Assigning Software    Patterns       Five patterns              Expert          ...
Expert  Expert     Assign responsibility to the information expert              Sale         date         time          ...
Expert          Sale       date       time       total sales()              Contains               1..*                   ...
Creator    Creator - Assign class B the responsibility to create an     instance of class A if one of the following is tr...
Low CouplingDesign 1  makePayment()                         1:create()                        :POST                       ...
High Coupling    Design 1         Sale                                               Payment   date              1      Pa...
Low Coupling      Design 2           Sale                                             Payment      date            1     P...
High Cohesion  Same example can be analysed from point of view   of high cohesion (functional cohesion)  Design two is b...
Controller  Assign responsibility for handling a system event    messages       Usually assigned to a controller       ...
Design Patterns: Essentials  Patterns are found through trial and error and by   observation.  In general a design patte...
Patterns in the S/W Development Lifecycle  Design patterns are considered complementary to   existing object-oriented met...
The ‘Gang of Four’  The most widely known work on design patterns is   that of Gamma, Helm, Johnson and Vlissides .   ‘Th...
Summary In this chapter we have:  Discussed why software design patterns evolved  Defined and described a software desig...
Upcoming SlideShare
Loading in …5
×

8. design patterns

854 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
854
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 1
  • 3 Whether it has to be accepted or to be changed in the future: Designing reusable software is difficult. There are no hard and fast rules. Experienced designers, however, manage to make good designs. Novices, on the contrary, are not sure which design rule to follow when and do not have a handle to relate problems to solutions. The "secret" of experienced designers is (amongst other secrets) that they can draw from a rich knowledge base of designs that are known to work. An experienced designer knows when a particular solution is applicable, how it is established, and what consequences are implied by its selection
  • 4 3 Expertise often manifests in being able to tell stories about successful design rather than just reciting good design rules. If a prior experience is understood only in terms of the generalization or principle behind the case, we don't have as many places to put the new case in memory. We can tell people abstract rules of thumb which we have derived from prior experiences, but it is very difficult for other people to learn from these. We have difficulty remembering such abstractions, but we can more easily remember a good story. Stories give life to past experience. Stories make the events in memory memorable to others and to ourselves. This is one of the reasons why people like to tell stories~\\cite{shank90}.
  • 5 4 When people begin to learn to play chess they first learn all the rules and physical requirements of the game. They learn the names of all the pieces, the way that pieces move move and capture, and the geometry and orientation of the board. At this point, people can play chess, although they will probably not a very good players. But as they progress, they will learn the principles of the game. They learn the value of protecting their pieces, and the relative value of those pieces. They learn the strategic value of the center squares and the power of a threat. They learn how the king can oppose the enemy king and how even one passed pawn can win the game. At this point, people can play a good game of chess. They know how to reason through the game and can recognize ``stupid'' mistakes. However, to become a master of chess, one must study the games of other masters. Buried in those games are patterns that must be understood, memorized, and applied repeatedly until they become second nature. There are thousands upon thousands of these patterns. Opening patterns are so numerous that there are books dedicated to their variations. Midgame patterns and ending patterns are also prevalent, and the master must be familiar with them all. So it is with software. First one learns the rules. The algorithms, data structures and languages of software. At this point, one can write programs, albeit not very good ones. Later, one learns the principles of software design. Structured programming, modular programming, object oriented programming. One learns the the importance of cohesion and coupling, of information hiding and dependency management. But to truly master software design, one must study the designs of other masters. Deep within those designs are patterns that can be used in other designs. Those patterns must be understood, memorized, and applied repeatedly until they become second nature. This chess analogy appears courtesy of Robert C. Martin (rmartin@oma.com).
  • 6 In architecture there are also rules (e.g., specification of required amount of light in a room) as in software design (e.g., low coupling, high cohesion, number of parameters per method), but in both cases this rules allow to judge an existing configuration but do not generate solutions. Patterns are working solutions and represent solutions that obey design rules and moreover, suggest a specific solution (dining corner with light from three sides, curved entry path). Peter Naur's NATO comment (1968) -- referring to Alexander's “Synthesis of Form” and "Principles of Software Engineering Management" by Tom Gilb (1988) are early software references
  • 7 6 Expertise often manifests in being able to tell stories about successful design rather than just reciting good design rules.
  • 8 Ergo, an essential property of a design pattern should be its successful application in several distinct applications
  • 10 6 Quote from “Patterns generate architecture”, Ecoop ‘94.
  • 8. design patterns

    1. 1. Design Patterns Chapter 8Object-Oriented Software Systems Engineering – Chapter 8 Slide 1
    2. 2. Objectives In this chapter we will:  Discuss why software design patterns evolved  Define and describe a software design pattern  Describe fundamental patterns (GRASP patterns)Object-Oriented Software Systems Engineering – Chapter 8 Slide 2
    3. 3. Design Patterns – An Introduction  Objectives  Understand why software design patterns evolved  Define and describe a software design pattern  Describe fundamental patterns (GRASP patterns)Object-Oriented Software Systems Engineering – Chapter 8 Slide 3
    4. 4. Why patterns?  designing reusable software is hard  novices are overwhelmed  experts draw from experience  some design solutions reoccur  understanding reoccurring solutions is beneficial in several waysObject-Oriented Software Systems Engineering – Chapter 8 Slide 4
    5. 5. Why patterns? “Wisdom is often ascribed to those who can tell just the right story at the right moment and who often have a large number of stories to tell.” Robert C. ShankObject-Oriented Software Systems Engineering – Chapter 8 Slide 5
    6. 6. What is a pattern?Occurrence  chess from rules to expertise  literature oldest reference  agriculture wisdom vs. science  fishing anecdotal documentation  architecture pioneer work  software designObject-Oriented Software Systems Engineering – Chapter 8 Slide 6
    7. 7. Architectural PatternsLight from two sides Place at Window Deep terraceObject-Oriented Software Systems Engineering – Chapter 8 Slide 7
    8. 8. What is a pattern? “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Alexander et al.Object-Oriented Software Systems Engineering – Chapter 8 Slide 8
    9. 9. What is a pattern?Patterns are proven  “Aggressive disregard for originality”  Rule of three “Once is an event, twice is an incident, thrice its a pattern.” Jerry WeinbergObject-Oriented Software Systems Engineering – Chapter 8 Slide 9
    10. 10. The Origins of Design Patterns  They originate from the work of Christopher Alexander, a building architect in the 1970’s.  Alexander’s idea was to improve the quality of the buildings of the time by utilising proven ‘patterns’ of good architectural design.  ‘Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem.’Object-Oriented Software Systems Engineering – Chapter 8 Slide 10
    11. 11. From Buildings to Software  Alexander’s work ‘discovered’ by Kent Beck and friends in the 1980’s.  They applied Alexander’s ideas about constructing buildings to the building of software.  Patterns are found in all areas of computing, from user interface design, the writing of device drivers to the use of databases.Object-Oriented Software Systems Engineering – Chapter 8 Slide 11
    12. 12. What is a software pattern?  proven software practice  piece of literature  building block  possible abstraction levels:  language construct  idiom  design pattern  architectural patternObject-Oriented Software Systems Engineering – Chapter 8 Slide 12
    13. 13. What is a Design Pattern?  A design pattern is defined as ‘ a description of communicating objects and classes that are customised to solve a general design problem in a particular context’.  Patterns capture good design principles and communicate them to others.  Design patterns represent the first legitimate attempt at design reusability.Object-Oriented Software Systems Engineering – Chapter 8 Slide 13
    14. 14. What is a software pattern? “A methodology tells you how to write down the decisions you have made. A pattern tells you which decisions to make, when and how to make them, and why they are the right” Beck & JohnsonObject-Oriented Software Systems Engineering – Chapter 8 Slide 14
    15. 15. GRASP Patterns  General Responsibility Assigning Software Patterns  Five patterns  Expert  Creator  High Cohesion  Low coupling  ControllerObject-Oriented Software Systems Engineering – Chapter 8 Slide 15
    16. 16. Expert  Expert  Assign responsibility to the information expert Sale date time Product Contains Specification 1..* description Described-by price Sales * UPC LineItem quantity • What about responsibilities for • grandTotal of sale • You also need subtotal for a line item • A method to return the priceObject-Oriented Software Systems Engineering – Chapter 8 Slide 16
    17. 17. Expert Sale date time total sales() Contains 1..* Product Described-by Specification Sales * LineItem description price quantity UPC subtotal() getPrice()  Benefits  Encapsulation is maintained. Supports low coupling which leads to robust and maintainable systemsObject-Oriented Software Systems Engineering – Chapter 8 Slide 17
    18. 18. Creator  Creator - Assign class B the responsibility to create an instance of class A if one of the following is true  B aggregates or contains A objects  B records instances of A objects  B closely uses A objects  B has the intializing data that will be passed to A when created  Who should be responsible for creating a SalesLineItem instance? Sale date time Product Contains Specification 1..* description Sales Described-by price * LineItem UPC quantityObject-Oriented Software Systems Engineering – Chapter 8 Slide 18
    19. 19. Low CouplingDesign 1 makePayment() 1:create() :POST p:Payment 2:addPayment(p) :SaleDesign 2 makePayment() 1:makePayment(p) :POST :Sale 1.1create() p:PaymentObject-Oriented Software Systems Engineering – Chapter 8 Slide 19
    20. 20. High Coupling Design 1 Sale Payment date 1 Paid-by 1 Time amount payment getAmount() 1 totalSales() addPayment(p) Captures makeLineItem(i,q) 1 Post sale.makeLineItem(item,qty) sale endSale() Payment p = new enterItem(item,qty) Payment(cash); makePayment(cash) sale.addPayment(p);Object-Oriented Software Systems Engineering – Chapter 8 Slide 20
    21. 21. Low Coupling Design 2 Sale Payment date 1 Paid-by 1 Time amount payment getAmount() 1 totalSales() makeLineItem(i,q) Captures makePayment(cash) 1 Post sale.makeLineItem(item,qty) sale endSale() Payment p = new enterItem(item,qty) Payment(cash) makePayment(cash) sale.makePayment(cash)Object-Oriented Software Systems Engineering – Chapter 8 Slide 21
    22. 22. High Cohesion  Same example can be analysed from point of view of high cohesion (functional cohesion)  Design two is betterObject-Oriented Software Systems Engineering – Chapter 8 Slide 22
    23. 23. Controller  Assign responsibility for handling a system event messages  Usually assigned to a controller  Logically the controller should not be a “window”, “Frame”, “applet”, “application” e.t.c. these classes just handle the events and delegate them to a controller.  In practice view and control may be embedded in a single element known as a UI delegate (MVC architecture)  endSale(), enterItem() & makePayment() are embedded into the POST classObject-Oriented Software Systems Engineering – Chapter 8 Slide 23
    24. 24. Design Patterns: Essentials  Patterns are found through trial and error and by observation.  In general a design pattern has four essential elements:  The pattern name  The problem the pattern is used to solve  The solution or template for implementing the pattern  The consequences or results of applying the pattern.Object-Oriented Software Systems Engineering – Chapter 8 Slide 24
    25. 25. Patterns in the S/W Development Lifecycle  Design patterns are considered complementary to existing object-oriented methodologies.  Success in using design patterns largely depends in the correct selection of the appropriate pattern.  Knowledge and understanding of the use of existing documented patterns is all important.  Therefore the way patterns are catalogued must be unambiguous and complete.Object-Oriented Software Systems Engineering – Chapter 8 Slide 25
    26. 26. The ‘Gang of Four’  The most widely known work on design patterns is that of Gamma, Helm, Johnson and Vlissides . ‘The gang of four’ as they are commonly referred to.  Their book ‘Design Patterns: Elements of Reusable Object-Oriented Software’ was published in 1994.  It contains a description of the concepts of patterns, plus a catalog of 23 design patterns with their full documentation.Object-Oriented Software Systems Engineering – Chapter 8 Slide 26
    27. 27. Summary In this chapter we have:  Discussed why software design patterns evolved  Defined and described a software design pattern  Described fundamental patterns (GRASP patterns)Object-Oriented Software Systems Engineering – Chapter 8 Slide 27

    ×