14 grasp-1

GRASP — General Responsibility

Assignment Software Patterns

Object Oriented Analysis and Design

Aron TrauringT++ 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 1


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



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 ifone of these is true:

1. B “contains” or compositely aggregates A

2. B records A

3. B closely uses A



4. B has the initializing data for A that will be passed to A when it is created (Bis an expert w.r.t. A)

If more than one applies, prefer a class B that meets criterion 1.



Creator — Example OrderLine

• Order meets criterion 4

• Determines method addLineItem()



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



Creator — Benefits

• Existing associations means created class is in any case visible to creator

• High cohesion

• Does not increase coupling



Mini Exercise 2 — Given a key, which object can tell

me about

• Square in Monopoly

• LineItem in Example DCD

• Total in same example



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 necessaryto fulfill responsibility



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



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 (getPricemethod)

• LineItems has information about Product and Quantity so it is expert forPriceTotal (getPriceTotal method)

• Sale has information LineItems with associated PriceTotal so it is expertfor SaleTotal (getSaleTotal method)



Information Expert — Sample UML Model

• getSubTotal == getPriceTotal



• getTotal == getSaleTotal



Information Expert — Sample Code Model

• Might be simpler to show in code



Partial Information Expert

• Fulfilling responsibility may require information spread across different classes

• Partial information experts collaborate in task — getSaleTotal example

• Interact through messages (methods) to share the work



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



Information Expert — When Not to Use

• When violate low coupling and high cohesion goals

• Product does not look up its price and description directly — ApplicationLogic vs. Technical Services (Database)

• Sale does not save itself in database

• Knowing about Database services would lower cohesion and increase cross-layercoupling

• “Separation of Major Concerns” principle — architectural issue



Information Expert — Benefits

• Encapsulation — objects support their own information — supports lowcoupling

• Behavior is distributed across classes — supports high cohesion



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?



Solution 1



Solution 1 — Justification

• Register records Payment

• Creator pattern

• addPayment method passes p instance of Payment as parameter

• Register coupled to Payment class



Solution 2



Coupling

Measure of how strongly one element is:

1. connected to

2. has knowledge of

3. relies on

another element



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



Low Coupling

Low Coupling

Problem: How to support low dependency, low change impact and increasedreuse?

Solution: Assign responsibility so coupling remains low. Use this principle toevaluate alternatives

All other things being equal prefer the low coupling solution

Note: Information Expert encourages Low Coupling



Types of Coupling

• ClassX has an attribute (data member or instance variable) that refers toClassY 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:



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



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: Tradeoffs between benefits 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



Low Coupling — When Not To

• Too little coupling means we aren’t a “collaborating community of objects”

• It’s ok to be highly coupled with stable or pervasive elements (e.g. languagelibraries)



Low Coupling — Benefits

• Not affected by changes in other components

• Simple to understand in isolation

• Convenient to reuse



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?



Mini Exercise 1 — Lahrman p. 288 — Which object

starts the game?



Controller

Controller

Problem: What first object beyond the UI layer receives and co-ordinates(controls) a system operation

Solution: Assign the responsibility to a class representing one of the followingchoices:

1. Facade Controller : represents the overall system, a root object, a device thatthe object is running within, or a major sub-system

2. Use Case or Session Controller : represents a use case scenario within whichthe system event occurs



Session Controllers

• Naming conventions: <UseCaseName>Handler or <UseCaseName>CoOrdinatoror <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



Mini Exercise 1 — Solution on pp. 288-9



Controller — NextGen POS Example

• Conceptual representation — what is the the class that handles these opera-tions?



Controller Example — Options

• Facade: Register, POSSystem

• Session: ProcessSaleHandler, ProcessSaleSession

•



•



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



Ex: identify out of sequence EndSale before MakePayment



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 ofsystem operations

• Suitable in message handling system when can’t direct messages to alternativecontrollers — Internet application servers



Controller — Use Case

• Pure Fabrication — ProcessSaleHandler in not a domain concept inDomain Model

• When assigning to facade may lead to high coupling or low cohesion (“Bloat”)

• Many system operations across different processes

• Conceptually easier to understand and build



Controller vs. UI

• UI should not have responsibility for fulfilling system operations

• System operations handled in domain layer

• Controller is responsible for forwarding messages on



Controller — Benefits

• 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 specific)

• Helps ensure sequence of operation which may differ from UI input

• Can reason about system state — UI does not preserve state



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 ofdelegating

• When the controller has many attributes (much information) about the systemwhich should be distributed to or duplicates from elsewhere



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



Bloated Controllers — POS Example

• ProcessSalesHandler

• ProcessReturnsHandler

• ProcessPaymentHandler



Cohesion Defined

• measure of how strongly related and focused the responsibilities of an objectare

• Goal: highly related responsibilities

• Goal: small number of responsibilities



Low Cohesion — The Problem

• Hard to understand

• Hard to rescue

• Hard to maintain

• Subject to constant need to change (usually high coupling)



High Cohesion

High Cohesion

Problem: How to keep objects focused, understandable and manageable, andas a side effect support Low Coupling?

Solution: Assign responsibility so cohesion remains high.

Dosage: Use as an evaluation tool



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 lowcohesion



• Delegating to Sale creates greater cohesion in Register

• Second example also has lower coupling, so therefore more desirable on thatscore



High Cohesion — Observations

• Real world analogy: Delegate responsibility

• Highly related to low coupling

• Needs to be used in conjunction with other principles



High Cohesion — When Not to

• Class that needs to be maintained by a specialist — group functions by areaof expertise (SQL queries)

• Performance issues demand grouping a set of operations together — RPC



High Cohesion — Benefits

• Clarity and ease of comprehension of design increased

• Maintenance and enhancements are simplified

• Low coupling is often supported

• Enhances reuse


14 grasp-1

Documents

cisdd nysiagrasp ooad4

downaron trauring zoteca

couplingaron trauring

workaron trauring zoteca

aron trauring zoteca20

aron trauring zoteca22

aron trauring zoteca4

examplearon trauring