GRASP General Responsibility Assignment Software Patterns Object Oriented Analysis and Design

Aron Trauring T++ Technical Skills Training Program CUNY Institute for Software Design & Development (CISDD) New York Software Industry Association (NYSIA) December 17th, 2004

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Mini Exercise 1 Who will create Square object in Monopoly? (Use DM Larman p.158)

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Solution (Larman p. 283)

Have no design model so start with Domain Model Low representational gap build design model (dynamic and static) He who knows is responsible

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Creator
Creator Problem: Who should be responsible for creating a new instance of some class? Solution: Assign class B the responsibility to create an instance of class A if one of these is true: 1. B contains or compositely aggregates A 2. B records A 3. B closely uses A
Aron Trauring Zoteca 3

T++ CISDD NYSIA

GRASP - OOAD

4. B has the initializing data for A that will be passed to A when it is created (B is an expert w.r.t. A) If more than one applies, prefer a class B that meets criterion 1.

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Creator Example OrderLine

Order meets criterion 4 Determines method addLineItem()

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Creator When Not to Use

When want to reuse existing instances for performance purposes (caching) Really need instance of subclass base on some external criteria Other more complex situations Delegate responsibility further down

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Creator Benets
Existing associations means created class is in any case visible to creator High cohesion Does not increase coupling

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Mini Exercise 2 Given a key, which object can tell me about

Square in Monopoly LineItem in Example DCD Total in same example

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Information Expert
Information Expert Problem: What is a general principle of assigning responsibility to objects? Solution: Assign responsibility to the class that has the information necessary to fulll responsibility

Aron Trauring Zoteca

T++ CISDD NYSIA

GRASP - OOAD

Information Expert How to?

1. Clearly state the responsibility 2. Look in Design Model for relevant classes 3. Else look in Domain Model and create design classes

Aron Trauring Zoteca

10

T++ CISDD NYSIA

GRASP - OOAD

Information Expert Sale Total Example

Who should know the grand total of a sale? Product has information about Price so it is expert for that (getPrice method) LineItems has information about Product and Quantity so it is expert for PriceTotal (getPriceTotal method) Sale has information LineItems with associated PriceTotal so it is expert for SaleTotal (getSaleTotal method)

Aron Trauring Zoteca

11

T++ CISDD NYSIA

GRASP - OOAD

Information Expert Sample UML Model

getSubTotal == getPriceTotal
Aron Trauring Zoteca 12

T++ CISDD NYSIA

GRASP - OOAD

getTotal == getSaleTotal

Aron Trauring Zoteca

13

T++ CISDD NYSIA

GRASP - OOAD

Information Expert Sample Code Model

Might be simpler to show in code

Aron Trauring Zoteca

14

T++ CISDD NYSIA

GRASP - OOAD

Partial Information Expert

Fullling responsibility may require information spread across dierent classes Partial information experts collaborate in task getSaleTotal example Interact through messages (methods) to share the work

Aron Trauring Zoteca

15

T++ CISDD NYSIA

GRASP - OOAD

Information Expert Real World Analogy

Do It Myself [Coad] or Animation [Larman] principle objects are alive and can do things themselves Those who know do Ultimate knowledge may require co-operation

Aron Trauring Zoteca

16

T++ CISDD NYSIA

GRASP - OOAD

Information Expert When Not to Use

When violate low coupling and high cohesion goals Product does not look up its price and description directly Application Logic vs. Technical Services (Database) Sale does not save itself in database Knowing about Database services would lower cohesion and increase cross-layer coupling Separation of Major Concerns principle architectural issue

Aron Trauring Zoteca

17

T++ CISDD NYSIA

GRASP - OOAD

Information Expert Benets

Encapsulation objects support their own information supports low coupling Behavior is distributed across classes supports high cohesion

Aron Trauring Zoteca

18

T++ CISDD NYSIA

GRASP - OOAD

Mini-Exercise 3 Who creates the Payment?

makePayment method invoked in Register A Payment has to be associated with the Sale Who creates the Payment instance?

Aron Trauring Zoteca

19

T++ CISDD NYSIA

GRASP - OOAD

Solution 1

Aron Trauring Zoteca

20

T++ CISDD NYSIA

GRASP - OOAD

Solution 1 Justication
Register records Payment Creator pattern addPayment method passes p instance of Payment as parameter Register coupled to Payment class

Aron Trauring Zoteca

21

T++ CISDD NYSIA

GRASP - OOAD

Solution 2

Aron Trauring Zoteca

22

T++ CISDD NYSIA

GRASP - OOAD

Coupling
Measure of how strongly one element is: 1. connected to 2. has knowledge of 3. relies on another element

Aron Trauring Zoteca

23

T++ CISDD NYSIA

GRASP - OOAD

Problems with High Coupling

Forced local changes because of changes in related class Harder to understand in isolation Harder to reuse drags in more classes

Aron Trauring Zoteca

24

T++ CISDD NYSIA

GRASP - OOAD

Low Coupling
Low Coupling Problem: How to support low dependency, low change impact and increased reuse? Solution: Assign responsibility so coupling remains low. Use this principle to evaluate alternatives All other things being equal prefer the low coupling solution Note: Information Expert encourages Low Coupling

Aron Trauring Zoteca

25

T++ CISDD NYSIA

GRASP - OOAD

Types of Coupling
ClassX has an attribute (data member or instance variable) that refers to ClassY or ClassY instance Sale contains Orderline ClassX object calls on services of a ClassY object Product calls ProductCatalog.lookupPrice(itemID) ClassX has a method that references ClassY or ClassY instance In Orderline:
Aron Trauring Zoteca 26

T++ CISDD NYSIA

GRASP - OOAD

def getPriceTotal(self): return (self.product.getPrice() * self.quantity) ClassX is a direct or indirect subclass of ClassY Class PizzaBot(Chef) ClassX is an interface, and ClassY implements that interface Lamp.Turnon

Aron Trauring Zoteca

27

T++ CISDD NYSIA

GRASP - OOAD

Low Coupling Observations

Evaluative principle needs to be considered in context of other principles Measure current degree of coupling and assess damage of increasing Example: Tradeos between benets of sub-classing and increased coupling Generic classes with high probability of reuse should have low coupling Try not be highly coupled to unstable parts of system if can

Aron Trauring Zoteca

28

T++ CISDD NYSIA

GRASP - OOAD

Low Coupling When Not To

Too little coupling means we arent a collaborating community of objects Its ok to be highly coupled with stable or pervasive elements (e.g. language libraries)

Aron Trauring Zoteca

29

T++ CISDD NYSIA

GRASP - OOAD

Low Coupling Benets

Not aected by changes in other components Simple to understand in isolation Convenient to reuse

Aron Trauring Zoteca

30

T++ CISDD NYSIA

GRASP - OOAD

Controller Understanding the Problem

SSD boundary between the User and SUD UI layer catches the request The request is a system operation public interface Model-View Separation principle says UI must not contain business logic Problem: to which domain layer object should the UI pass the system operation?

Aron Trauring Zoteca

31

T++ CISDD NYSIA

GRASP - OOAD

Mini Exercise 1 Lahrman p. 288 Which object starts the game?

Aron Trauring Zoteca

32

T++ CISDD NYSIA

GRASP - OOAD

Controller
Controller Problem: What rst object beyond the UI layer receives and co-ordinates (controls ) a system operation Solution: Assign the responsibility to a class representing one of the following choices: 1. Facade Controller : represents the overall system, a root object, a device that the object is running within, or a major sub-system 2. Use Case or Session Controller : represents a use case scenario within which the system event occurs
Aron Trauring Zoteca 33

T++ CISDD NYSIA

GRASP - OOAD

Session Controllers
Naming conventions: <UseCaseName>Handler or <UseCaseName>CoOrdinator or <UseCaseName>Session Use same controller class for all system operations in the use case scenario Session is a type of conversation between the actor and the SUD

Aron Trauring Zoteca

34

T++ CISDD NYSIA

GRASP - OOAD

Mini Exercise 1 Solution on pp. 288-9

Aron Trauring Zoteca

35

T++ CISDD NYSIA

GRASP - OOAD

Controller NextGen POS Example

Conceptual representation what is the the class that handles these operations?
Aron Trauring Zoteca 36

T++ CISDD NYSIA

GRASP - OOAD

Aron Trauring Zoteca

37

T++ CISDD NYSIA

GRASP - OOAD

Controller Example Options

Facade : Register, POSSystem Session: ProcessSaleHandler, ProcessSaleSession

Aron Trauring Zoteca 38

T++ CISDD NYSIA

GRASP - OOAD

Aron Trauring Zoteca

39

T++ CISDD NYSIA

GRASP - OOAD

Controller Observations
Delegation pattern External input events may come from human actors or other systems Facade the face of the domain layer to the world Ex: Register Handler deals with a clear cut part of the issue Ex: ProcessSale Session conversation where information needs to be retained between steps
Aron Trauring Zoteca 40

T++ CISDD NYSIA

GRASP - OOAD

Ex: identify out of sequence EndSale before MakePayment

Aron Trauring Zoteca

41

T++ CISDD NYSIA

GRASP - OOAD

Controller Facade
cover over the other layers of the application Abstraction of an overall physical unit Register, PizzaShop The entire software system POSSystem Abstraction of some other overall system or sub-system concept MonopolyGame Suitable for relatively small systems and/or system with limited number of system operations Suitable in message handling system when cant direct messages to alternative controllers Internet application servers
Aron Trauring Zoteca 42

T++ CISDD NYSIA

GRASP - OOAD

Controller Use Case

Pure Fabrication ProcessSaleHandler in not a domain concept in Domain Model When assigning to facade may lead to high coupling or low cohesion (Bloat) Many system operations across dierent processes Conceptually easier to understand and build

Aron Trauring Zoteca

43

T++ CISDD NYSIA

GRASP - OOAD

Controller vs. UI
UI should not have responsibility for fullling system operations System operations handled in domain layer Controller is responsible for forwarding messages on

Aron Trauring Zoteca

44

T++ CISDD NYSIA

GRASP - OOAD

Controller Benets
Allows for easy change of UI and/or alternative UI and/or Batch mode Allows for reuse of domain layer code (UI is usually application specic) Helps ensure sequence of operation which may dier from UI input Can reason about system state UI does not preserve state

Aron Trauring Zoteca

45

T++ CISDD NYSIA

GRASP - OOAD

Bloated Controllers The Problem

Low cohesion unfocused and handling too many areas of responsibility: When have a facade controller handling all of many system events When the controller performs many of the system operations instead of delegating When the controller has many attributes (much information) about the system which should be distributed to or duplicates from elsewhere

Aron Trauring Zoteca

46

T++ CISDD NYSIA

GRASP - OOAD

Bloated Controllers The Solution

Add more controllers use case instead of facade Design the controller so that it delegates operations to other objects High Cohesion is itself a GRASP principle

Aron Trauring Zoteca

47

T++ CISDD NYSIA

GRASP - OOAD

Bloated Controllers POS Example

ProcessSalesHandler ProcessReturnsHandler ProcessPaymentHandler

Aron Trauring Zoteca

48

T++ CISDD NYSIA

GRASP - OOAD

Cohesion Dened
measure of how strongly related and focused the responsibilities of an object are Goal: highly related responsibilities Goal: small number of responsibilities

Aron Trauring Zoteca

49

T++ CISDD NYSIA

GRASP - OOAD

Low Cohesion The Problem

Hard to understand Hard to rescue Hard to maintain Subject to constant need to change (usually high coupling)

Aron Trauring Zoteca

50

T++ CISDD NYSIA

GRASP - OOAD

High Cohesion
High Cohesion Problem: How to keep objects focused, understandable and manageable, and as a side eect support Low Coupling? Solution: Assign responsibility so cohesion remains high. Dosage: Use as an evaluation tool

Aron Trauring Zoteca

51

T++ CISDD NYSIA

GRASP - OOAD

High Cohesion NextGen POS Example

Register creates Payment in real world, so by Creator should in software too Danger: Register might start taking on too many responsibilities One step in isolation might not be a problem but adding up will lead to low cohesion
Aron Trauring Zoteca 52

T++ CISDD NYSIA

GRASP - OOAD

Delegating to Sale creates greater cohesion in Register Second example also has lower coupling, so therefore more desirable on that score

Aron Trauring Zoteca

53

T++ CISDD NYSIA

GRASP - OOAD

High Cohesion Observations

Real world analogy: Delegate responsibility Highly related to low coupling Needs to be used in conjunction with other principles

Aron Trauring Zoteca

54

T++ CISDD NYSIA

GRASP - OOAD

High Cohesion When Not to

Class that needs to be maintained by a specialist group functions by area of expertise (SQL queries) Performance issues demand grouping a set of operations together RPC

Aron Trauring Zoteca

55

T++ CISDD NYSIA

GRASP - OOAD

High Cohesion Benets

Clarity and ease of comprehension of design increased Maintenance and enhancements are simplied Low coupling is often supported Enhances reuse

Aron Trauring Zoteca

56