Chapter 7: Object Design Examples with GRASP

Objective Design use case realizations. Apply GRASP to assign responsibilities to classes. Apply UML to illustrate and think through the design of objects.

7.1. What is a Use Case Realization? A use-case realization –Describes how a particular use case is realized within the Design Model, in terms of collaborating objects. the connection between the requirements expressed as use cases and the object design that satisfies the requirements.

7.1. What is a Use Case Realization?

7.2. Artifact Comments SSDs, System Operations, Interaction Diagrams, and Use Case Realizations

7.2. Artifact Comments The Domain Model and Use Case Realizations – The Domain Model inspires some of the software objects, such as a Sale conceptual class and Sale software class

7.3. What's Next? The remainder of this chapter is organized as follows: –A relatively detailed discussion of the design of the NextGen POS. –Likewise, for the Monopoly case study, Applying UML and patterns to these case studies. let's get into the details…

7.4. Use Case Realizations for the NextGen Iteration –Who should be responsible for calculating the Sale total? By Expert, it should be the Sale itself, implemented as a getTotal method. –Who should be responsible for calculating the SalesLineItem subtotal? By Expert, it should be the SalesLineItem itself, implemented as a getSubtotal method. –Who should be responsible for providing the ProductDescription price? By Expert, it should be the ProductDescription itself, implemented as a getPrice operation. My goodness, that was detailed!

7.4. Use Case Realizations for the NextGen Iteration The Sale.getTotal Design

7.4. Use Case Realizations for the NextGen Iteration

How to Design makePayment? –Two Candidates for Creating the Payment Register –By Creator “register" records account information in real domain “register" records account information in real domain –By Expert Register is the controller that receives the system operation makePayment message. Sale –It will closely use a Payment

7.4. Use Case Realizations for the NextGen Iteration When there are alternative design choices –take a closer look at the cohesion and coupling implications of the alternatives –and possibly at the future evolution pressures on the alternatives

7.4. Use Case Realizations for the NextGen Iteration Logging a Sale –Who is responsible for knowing all the logged sales and doing the logging? Store –the logged sales are strongly related to its finance SalesLedger –makes sense as the design grows and the Store becomes incohesive –SalesLedger is not in domain model

7.4. Use Case Realizations for the NextGen Iteration

Calculating the Balance –Who is responsible for knowing the balance? need the sale total and payment cash tendered

7.4. Use Case Realizations for the NextGen Iteration The Final NextGen DCD for Iteration-1

7.4. Use Case Realizations for the NextGen Iteration How to Connect the UI Layer to the Domain Layer? –An initializer object called from the application starting method (e.g., the Java main method) creates both a UI and a domain object and passes the domain object to the UI. –A UI object retrieves the domain object from a well-known source, such as a factory object that is responsible for creating domain objects.

7.4. Use Case Realizations for the NextGen Iteration

How to show the running total in UI –Add a getTotal method to the Register. Lower coupling from the UI to the domain layer make Register less cohesive. –A UI directly sends messages to the Sale. increases the coupling from the UI to the domain layer.

7.4. Use Case Realizations for the NextGen Iteration

Initialization and the 'Start Up' Use Case –When to Create the Initialization Design? Do the initialization design last. –How do Applications Start Up? create an initial domain object or a set of peer initial domain objects –in the starting main method or in a Factory object called from the main method the initial domain object is responsible for the creation of its direct child domain objects.

7.4. Use Case Realizations for the NextGen Iteration public class Main { public static void main( String[] args ) { // Store is the initial domain object. // The Store creates some other domain objects. Store store = new Store(); Register register = store.getRegister(); ProcessSaleJFrame frame = new ProcessSaleJFrame( register );......}}

7.4. Use Case Realizations for the NextGen Iteration Choosing the Initial Domain Object –a class at or near the root of the containment or aggregation hierarchy of domain objects. Store.create Design –Create a Store, Register, ProductCatalog, and ProductDescriptions. –Associate the ProductCatalog with ProductDescriptions. –Associate Store with ProductCatalog. –Associate Store with Register. –Associate Register with ProductCatalog

7.4. Use Case Realizations for the NextGen Iteration Multiplicity between classes of objects in the Domain Model and Design Model may not be the same.

7.5. Use Case Realizations for the Monopoly Iteration

How to Design playGame? –Choosing the Controller Class MonopolyGame / MGame PlayMonopolyGameHandlerPlayMonopolyGameSession

7.5. Use Case Realizations for the Monopoly Iteration The Game-Loop Algorithm –turn a player rolling the dice and moving the piece –round all the players taking one turn Now the game loop: for N rounds for each Player p p takes a turn Who is Responsible for Controlling the Game Loop?

7.5. Use Case Realizations for the Monopoly Iteration Information Needed Who Has the Information the current round count No object has it yet, but assigning this to the MonopolyGame object is justifiable. all the players MonopolyGame is a good candidate.

7.5. Use Case Realizations for the Monopoly Iteration playRound helper method –Factors the play-single-round logic into a helper method; it is good to organize cohesive chunks of behavior into small separate methods. –Good OO method design encourages small methods with a single purpose. This supports High Cohesion at the method level.

7.5. Use Case Realizations for the Monopoly Iteration Who Takes a Turn? –Rolling the dice –Moving a piece to the square indicated by the total of the dice face values. a naive reaction might be to say "a Player object should take the turn"

7.5. Use Case Realizations for the Monopoly Iteration Information Needed Who Has the Information current location of the player a Piece knows its Square and a Player knows its Piece. the two Die objects MonopolyGame is a candidate since we think of the dice as being part of the game. all the squares Board is a good candidate. Interesting Problem! –There are three partial information experts for the "take a turn" responsibility

7.5. Use Case Realizations for the Monopoly Iteration When there are multiple partial information experts –place the responsibility in the dominant one the object with the majority of the information When there are alternative design choices, – consider the coupling and cohesion impact of each, and choose the best. When there is no clear winner –consider probable future evolution of the software objects and the impact in terms of Information Expert, cohesion, and coupling.

7.5. Use Case Realizations for the Monopoly Iteration

Taking a Turn –calculating a random number total between 2 and 12 (the range of two dice) Die –calculating the new square location Board –moving the player's piece from an old location to a new square location Piece Who Coordinates All This? –Player The Problem of Visibility –Player need visibility to the Die, Board, and Piece objects

7.5. Use Case Realizations for the Monopoly Iteration

// style #1; used in the official solution public void roll() { faceValue = // random num generation } public int getFaceValue() { return faceValue; } // style #2; why is this poor? public int roll() { faceValue = // random num generation return faceValue; }

7.5. Use Case Realizations for the Monopoly Iteration Command-Query Separation Principle –a command method that performs an action often has side effects such as changing the state of objects, and is void –a query that returns data to the caller and has no side effects

7.5. Use Case Realizations for the Monopoly Iteration Initialization and the 'Start Up' Use Case

Questions & Answers