1. Object-Oriented Software Engineering Practical Software Development using UML and Java Design Patterns Sources: Chapter 6: Using Design Patterns, and Chapter 30 (parts) Designing the Logical Architecture with Patterns Craig Larman’s Text: Applying UML and Patterns, Chaps: 16, 17, 22, & 23.

2. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns2 Patterns Architectural: - related to the large-scale and coarse- grained design, and typically applied during the early iterations (the elaboration phase) when the major structures and connections are established. Design Patterns: - related to the small and medium-scale design of objects and frameworks. Applicable to designing a solution for connecting the large scale elements defined via architectural patterns, and during detailed design work for any local design aspect. (Sometimes also known as architectural patterns).

3. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns3 Sample Titles The Façade pattern, which can be used to provide the interface from one layer to the next… Singleton pattern – to ensure global access to a single instance of a class. Information Expert (Expert); Adaptor; Creator; Observer; Low Coupling; High Cohesion; Controller; etc. etc. Design Patterns are often organized into different categories too. Most of these notes from the first two lectures on Design Patterns are taken directly from Larman’s text.

4. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns4 Preview: Want to look at more class diagrams – static.  But we want to look at recurring groupings of classes that are regularly used to address common problems.  Want to take advantage of experiences of others and create a better, more resilient design. Want to use patterns that assist us in separating concerns (abstraction- occurrence, observer, player-role); patterns used to better create class hierarchies of instances; patterns in which one method simply calls another method in another class (have you seen this??); patterns where you use delegation to gain access to facilities in one or more other classes (Adaptor, Façade, Proxy); patterns that help protect other objects from unanticipated access (immutable and read-only interfaces).

5. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns5 Preview: continued. We will study several of the most often used patterns – GRASP Patterns, and Gang of Four (GoF) Patterns Please recognize that in some cases, you will note that you may be already doing some of these things. You may now see more rationale and more formal reasoning… In all cases, the patterns will be most helpful as we strive to design objects.

6. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns6 One more look before we look at design patterns: Design Patterns are groups of objects designed to support simply a ‘good object design’ with emphasis on those features that ‘constitute’ good object design, such as design that yields high cohesion of our objects, low coupling between our objects, which, among other things, fosters more likely reuse It is one thing to create an object…it is quite another to create the right object for the right situation.

7. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns7 Object design is NOT a simple undertaking and involves, as all design does, making decisions. Good object design involves the assignment of responsibilities, and there are patterns that can assist us. Deciding what methods belong where and how objects interact is critically important and NOT trivial. All this is really at the heart of what it means to develop an object- oriented system, not merely the drawing of domain model diagrams, package diagrams, etc. We will thus look at a number of object patterns in attempts to develop better designs.

8. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns8 6.1 Introduction to Patterns (from OOSE book) The recurring aspects of designs are called design patterns.  A pattern is the outline of a reusable solution to a general problem encountered in a particular context Many of them have been systematically documented for all software developers to use A good pattern should —Be as general as possible —Contain a solution that has been proven to effectively solve the problem in the indicated context. Studying patterns is an effective way to learn from the experience of others

9. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns9 Introduction – Suggestive Names Patterns have names and the names are ‘suggestive’ The names can be used in our vocabulary to communicate design intentions. Here again, naming a pattern is using an abstraction of the details of that pattern.

10. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns10 Grasp Patterns General Responsibility Assignment Software Patterns. GRASP Patterns is redundant – but it stuck. Recognize that according to Craig Larman: 1.“The skillful assignment of responsibilities is extremely important in object design, 2.Determining the assignment of responsibilities often occurs during the creation of interaction diagrams and certainly during programming.” Larman, p. 219. Please note that much of the following information is taken directly from Larman’s book.

11. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns11 GRASP Patterns Note: A Design Model may have hundreds or thousands of software classes and hence hundreds or thousands of responsibilities to be fulfilled. During object design, when interactions between objects are defined, we make choices about the assignment of responsibilities to software classes..

12. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns12 1. Information Expert (or Expert) (GRASP Pattern) Start by assigning responsibilities by clearly stating the responsibility: Who should be responsible for knowing the grand total of a sale? So, ‘who’ has the information needed to determine the total?

13. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns13 Expert (Grasp Pattern) Next question: look in Domain Model or Design Model? Domain Model contains conceptual classes of the real- world domain; Design Model contains the software classes. First choice: If we have relevant classes in the Design Model, choose this first. Second choice: look into Domain Model and attempt to use (or expand) its representations to inspire the creation of corresponding design classes.

14. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns14 Expert (Grasp Pattern) Continuing… Assume we are just starting and we have no real Design Model. So look to Domain Model and we find “Sale.” Sale date time SalesLineItem quantity Product Specification description price itemID 1 * * 1 Described by Contains

15. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns15 Add a Sale class to the Design Model, and give it the responsibility of knowing its total, expressed with a method named getTotal. This approach supports a low representational gap, in which the software design of objects appeals to our concepts of how the real domain is organized…. We now have:

16. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns16 t := getTotal() : Sale date time getTotal() New method ------  Our first design class:

17. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns17 What info do we need in the grand total? We need to know about all the SalesLineItem instances of a sale and sum their subtotals. A Sales instance contains these; thus by Information Expert, Sale is the suitable class for this responsibility. But it needs help…and we are not done.

18. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns18 What information is needed to determine the line item subtotals? We need: SalesLineItem.quantity and ProductSpecification.price The SalesLineItem “knows” its quantity (is an attribute) and its associated ProductSpecification (via association); Therefore, by Expert, SalesLineItem should determine the subtotal; it is the information Expert in this case. So, ‘now’ what do we have?

19. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns19 Consider: t := getTotal() : Sale : SalesLineItem 1 *: st := getSubtotal() :Sale date time getTotal() :SalesLineItem quantity getSubtotal() Well, we now have: Note: we have added a responsibility, getSubtotal() to SalesLineItem We have also added another class to our Design Model

20. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns20 Continuing: To fulfill the responsibility of knowing and answering the subtotal, a SalesLineItem needs to know the product price. The ProductSpecification is an information expert on answering its price (it is an attribute of ProductSpecification); thus we need a message sent to it asking for the price. This is shown on the next slide….and we end up with:

21. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns21 Consider: See the design classes and an abbreviated communications (collaboration) diagram. t := getTotal() : Sale : SalesLineItem : Product Specification 1 *: st := getSubtotal() 1.1: p := getPrice() Sale date time getTotal() SalesLineItem quantity getSubtotal() Product Specification description price itemID getPrice() Please note that the responsibilities were decided upon while drawing an interaction diagram. The principle by which each responsibility was assigned was Information Expert – placing it with the object that had the information needed to fulfill it.

22. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns22 Continuing… Information Expert is frequently used in assigning responsibilities. It is thee guiding principles and continuously used in object design. Note that the fulfillment of responsibilities often requires spanning several different classes. This implies that there are several partial information experts who collaborate in the task. Fundamentally, they do things relative to the information they ‘know.’

23. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns23 But be careful: Now, running Expert ‘into the ground..’ Who should be responsible for saving Sale in a database? Clearly, much of the information is in the Sale object and thus by ‘Expert’ an argument could be made to put that responsibility in the Sale class. But, by extension, then, EACH class would have its own services to save itself in the database. This, of course, leads to problems in cohesion and coupling, and duplication.

24. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns24 Being careful with Expert… What does all this mean? If we were to do this: Sale would have to now contain logic related to database handling, such as related to SQL and JDBC. Class is NOW no longer focused on just pure application of logic of ‘being a sale;” it now has other kinds of responsibilities, which lowers its cohesion! The class must be coupled to the technical database services of another subsystem, such as JDBC services, rather than ‘just’ being coupled to other objects in the domain layer of software objects, which raises its coupling. And, it is likely that similar database logic would be duplicated in many persistent classes.

25. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns25 Being careful with Expert - final These problems violate a basic architectural principle: design for the separation of major system concerns. Keep application logic in one place (such as the domain software objects); Keep database logic in another place (such as a persistence services subsystem), etc. rather than intermingling different system concerns in the same component.  Supporting a separation of major concerns improves coupling and cohesion in a design. Thus, even though “by Expert” there could be some justification to put the responsibility for database services into the Sale class, for other reasons, (usually coupling and cohesion), it is a poor design.

26. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns26 Benefits of Expert: Benefits: 1. Information encapsulation is maintained, since objects use their own information to fulfill tasks. This usually supports low coupling, which leads to a more robust and maintainable system. (Low Coupling is also a GRASP pattern). 2. Behavior is distributed across the classes that have the required information thus encouraging more cohesive ‘lightweight’ class definitions that are easier to understand and maintain. High cohesion is usually supported. Reuse potential up.

27. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns27 The Creator Pattern (a GRASP Pattern) Problem: Who is responsible for creating new instances of some class? Solution: Assign class B the responsibility to create an instance of class A if one or more of the following is true: B aggregates A B contains A B records instances of A objects B closely uses A objects B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A) If more than one option applies, prefer a class B which aggregates or contains class A.

28. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns28 Creator - continued This is a very common activity in OO systems. This is, then, a general principle for the assignment of creation activities. This approach can result in low coupling, increased clarity, encapsulation, and reusability.

29. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns29 Creator - Example In Craig Larman’s Point of Sales application, we have the previously described class relationships. Sale date time getTotal() SalesLineItem quantity getSubtotal() Product Specification description price itemID getPrice() 1 * * 1 Described by Contains Who should be responsible for creating a SalesLineItem instance? In Creator, we look for a class that aggregates, contains, records … SalesLineItem instances.

30. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns30 Creator - example Here, clearly, Sales contains or aggregates many SalesLineItem instances. Since a Sale contains many SalesLineItem objects, the Creator pattern suggests that Sale is a good candidate to have the responsibility of creating SalesLineItem instances. See next slide: Clearly a Sale contains (aggregates) SalesLineItem objects. Thus the Creator pattern suggests that Sale is a good candidate for this responsibility.

31. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns31 Abbreviated Sequence Diagram: :Register :SalesLineItem :Sale makeLineItem(quantity) create (quantity) The assignment of responsibilities requires that a makeLineItem method be defined in Sale. Once again, the context for these decisions was while drawing the interaction diagram. The method section of a class can then summarize the responsibility assignment results concretely realized as methods.

32. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns32 Benefits of Creator Pattern: Object creation is a very common activity, and we want a creator that needs to be connected to the created object; This naturally supports now coupling too. Sometimes a creator is found by looking for the class that has the initializing data that will be passed in during creation. This is actually an example of the Expert pattern. Initializing data is passed in during creation via some kind of initialization method, like a Constructor, or, …. Please note that these words/drawings are almost verbatim from Craig Larman’s textbook….

33. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns33 More Grasp Patterns Coming… We will next look at Polymorphism – a Grasp Pattern and Controller – another Grasp Pattern.