Chapter 17

Initial Object Design Inputs: requirements meetings various Use Cases – 10% complete Key risks addressed with preliminary programming System Sequence Diagrams The Domain Model Glossary Use Case post-conditions clarify proposed achievements.

Object Design Activities: Test-first development (test code production code) Some UML modeling Sequence Diagrams concurrent with Class Diagrams Apply GRASP principles and GoF Design Patterns Follow RDD – responsibility-driven design Class diagrams are intended for understanding, not documentation

Object Design Outcome: Add methods to appropriate classes. This simplistic description hides the deep principles and issues involved and he consequences of getting it wrong.

Fig inputs and outputs of a day of design

Responsibility-Driven Design (RDD): Think in terms of responsibilities, roles and collaborations Two kinds: – doing – knowing Think about responsibility “granularity” Responsibilities happen in conjunction with collaborations between objects.

Responsibility-Driven Design (RDD): Doing: –doing something itself –initiating action in others –controlling or coordinating activities across various objects

Responsibility-Driven Design (RDD): Knowing: –knowing about private data –knowing about related objects –knowing about secondary data it can calculate (result of a method call)

Guidelines: Domain Model guides what classes “know” Results in “low representational gap” keep your eye on responsibility “granularity” –big responsibilities get spread over many classes –small responsibilities may take only one method Collaboration is everywhere – methods talk to one another

RDD as Metaphor: An OO Design seen as a community of collaborating responsible objects.

GRASP: General Responsibility Assignment Software Patterns or Principles Basic principles to follow when assigning responsibilities Used in place of experience based on recognized successful patterns

GRASP Principles: Information Expert: assign responsibility to the knowledgeable class; the one with the necessary info Creator: Creation responsibility goes to the class that –contains an object –aggregates an object –has initializing data Controller: A class that represents the overall system, “root”, a device, a subsystem or a Use Case goal. This is the first class beyond the UI. Low Coupling: Keep unnecessary coupling to a minimum. Typically one of many alternatives.

GRASP Principles: High Cohesion: assign responsibility so cohesion remains high. Typically one of many alternatives. Polymorphism: Assign responsibilities as behaviour varies by type. Use polymorphism. Pure Fabrication: When a highly cohesive set of behaviours needs a home and no domain object does it. Indirection: Use an intermediate object when you don't want to classes to know about each other. Protected Variations: Protecting against instability if variations need frequent tweaking. Identify places of predictable instability and protect them with an interface.

Fig What GRASP principles are applied here?

Patterns: A pattern is a named description of a problem and its solution that can be applied to new contexts. Naming a pattern is important. If you can't name it you don't understand it. Patterns are all old friends. Keep to the tried and true. “New” pattern is an oxymoron. Own the GoF book – Design Patterns

Fig What GRASP patterns are in use?

Fig Board aggregates Square. Start there.

Find the GRASP patterns in use here: Creator: Board creates Square (LRG) since it aggregates squares. Information expert: To retrieve one square one needs to know about all squares. This is Board's job as aggregator. Low Coupling: Knowing about squares as a collection and then individually means low coupling. Controller: High Cohesion:

Fig. 17.4

Fig. 17.6

Find the GRASP patterns in use here: Low Coupling: Knowing about squares as a collection and then individually means low coupling. Controller: High Cohesion:

Fig. 17.7

Fig. 17.8

Fig. 17.9

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig

Fig