Chapter 17 Designing with Responsibilities Fig. 17.1 OOD Requirements Domain model Then: Define classes Add methods to classes Define messaging Simple! RIGHT? - NOT RDD Responsibility - contract or obligation of a class Doing- Doing something itself Initiate an action in another object Control or coordinate Knowing- Private data Related objects Things it can calculate Fig. 17.2 GRASP 9 patterns, first 5 in this chapter: Creator Information expert Low coupling Controller High cohesion Creator Problem: Who creates A? Solution: Assign creation to B IF: B contains (compositely aggregates) A B records A B closely uses A B has initializing data for A Fig apply Creator Fig Apply Creator Information Expert Problem: Assign a responsibility to an object? Solution: Choose the class that has the information to fulfill the responsibility Fig. 17.6 Low Coupling Problem: Reduce impact of change Solution: Keep coupling low! Fig. 17.7 Controller Problem: What object beyond UI controls a system operation Solution: Assign responibility to object If Overall system, root object, device that the software runs in, major subsystem Represents a use case scenario within which the operation occurs Fig SSD Fig. 17.9 Fig Next Steps Applied controller pattern Now what goes beyond the :MonoployGame class? High cohesion Problem: Keep objects focused, understandable, manageable (side effect support low coupling) Solution: assign responsibilities to improve cohesion Fig GRASP General Responsibility Assignment Software Patterns We just did 5 of 9 There rest are in Chapter 25 Polymorphism, Pure Fabrication, Indirection, Protected Variations