Fall 2009ACS-3913 Ron McFadyen1 From the Merriam-Webster’s online dictionary (): Main Entry: an·thro·po·mor·phism Date: 1753 an interpretation.

Fall 2009 ACS-3913 Ron McFadyen 1

From the Merriam-Webster’s online dictionary (www.m-w.com):

Main Entry: an·thro·po·mor·phism

Date: 1753

an interpretation of what is not human or personal in terms of human or personal characteristics : HUMANIZATION

Anthropomorphism

Fall 2009 ACS-3913 Ron McFadyen 2

Anthropomorphism

Anthropomorphism: Object-oriented programming

works like human organizations. Each object will

communicate with another one by sending messages. So

the software objects work by just sending those messages.

Fall 2009 ACS-3913 Ron McFadyen 3

Responsibility-Driven Design (RDD)

• Detailed object design is usually done from the point of view of:

– Objects have responsibilities

– Objects collaborate

– Similar to how we conceive of people

• In RDD we do object design such that we will ask questions such as:

– What are the responsibilities of this object?

– Who does it collaborate with?

Fall 2009 ACS-3913 Ron McFadyen 4

Architectural Layers

Fall 2009 ACS-3913 Ron McFadyen 5

Sample Problem 1

• What object should receive this message?

• How should objects interact to fulfill the request?

???

Presentation

ApplicationLogic

Video Store

Record Rental

Video ID

...

...

...

... ...

Clerk

appLogicRequest()

Now what happens?

• How do we justify out decision?

Fall 2009 ACS-3913 Ron McFadyen 6

Sample Problem 2

• How should the objects interact in order for changes in the data to be reflected in the two displays?

Graphic

Display

List

Display

Data

User

• How do we justify our decision?

Fall 2009 ACS-3913 Ron McFadyen 7

•idea was first put forth by Christopher Alexander (1977) in his work on architectural design principles

•a pattern is a named problem/solution pair that can be applied in new contexts

•advice from previous designers to help designers in new situations

•rules of thumb - not new ideas

•There are many books on the subject; examples:•Design Patterns - Erich Gamma et al

•Java Design Patterns: a tutorial - James Cooper

•Design Patterns Java Workbook - Steven John Metsker

•Data Access Patterns - Clifton Nock

•Patterns of Enterprise Application Architecture – Martin Fowler

Patterns

Fall 2009 ACS-3913 Ron McFadyen 8

• Guiding principles to help us assign responsibilities

• GRASP:

– General Responsibility Assignment Software Patterns

– Very very fundamental, simple, basic principles of object design.

– Developed by Craig Larman

GRASP Patterns Fundamental Principles of Object Design

Fall 2009 ACS-3913 Ron McFadyen 9

GRASP Patterns

• Expert

• Creator

• Controller

• Low Coupling

• High Cohesion

Fall 2009 ACS-3913 Ron McFadyen 10

???

Presentation

ApplicationLogic

Video Store

Record Rental

Video ID

...

...

...

... ...

Clerk

appLogicRequest()

What object should this be?

What object in the domain (or application layer) receives requests for work from the UI layer?

Controller

Fall 2009 ACS-3913 Ron McFadyen 11

Basic Principle: Interface objects should not have responsibility for handling system events

Controller: a non-user interface object responsible for receiving or handling a system event.

In the Process Sale Use Case, there are several system events:

makeNewSale, enterItem, endSale, makePayment

The Controller doesn’t do much … it should delegate work to other objects … it receives the request & coordinates fulfillment

Fall 2009 ACS-3913 Ron McFadyen 12

makeNewSale

enterItem

endSale

makePayment

System Operations

Fall 2009 ACS-3913 Ron McFadyen 13

In general there are two candidates:– An object whose name reflects the use case.

• e.g. ProcessSaleHandler

– An object whose name reflects the overall server, business, or large-scale entity.

• A kind of “façade” object• e.g. Register, Store, Cashier

Choose or invent an object in the application layer for this.

Fall 2009 ACS-3913 Ron McFadyen 14

Register, Store, Cashier

Register is chosen in the text

Fall 2009 ACS-3913 Ron McFadyen 15

Allocating System Operations

Register has been chosen to handle all system operations

Ch 20 shows the code for this

If Use Case handlers were chosen

Fall 2009 ACS-3913 Ron McFadyen 16

The Controller pattern promotes reuse

•UI code is not intertwined with system event code

•UI can be replaced

•Multiple UIs could be utilized

When a legal sequence of operations must occur, state information must be kept … a Controller object is an excellent choice for this information

Fall 2009 ACS-3913 Ron McFadyen 17

A controller is class whose job it is to coordinate the system events

The controller sees to it the messages are sent to the correct objects in the model – it delegates

The reason to have a controller is to separate the business model from the visual logic called a view

Fall 2009 ACS-3913 Ron McFadyen 18

Advantage - is that the changes to the model do not affect the GUI (view) logic

Advantage - is that the changes to the GUI (view) do not affect the model logic – could have multiple GUIs – GUI is replaceable

It provides a buffer between the visual (view) and the business logic (model)

Fall 2009 ACS-3913 Ron McFadyen 19

desirable coupling of interface layer to domain layer

Fall 2009 ACS-3913 Ron McFadyen 20

Expert

• Assign a responsibility to the object that has the information necessary to fulfill it.

– “That which has the information, does the work.”

– Not a sophisticated idea - rather, it is common sense

– E.g., What software object calculates grand total?

• What information is needed to do this?

• What object has the majority of this information.

Fall 2009 ACS-3913 Ron McFadyen 21

Expert Example.

In the NextGEN POS application, it is necessary to know the grand total of a sale.

Where should that responsibility be placed?

{We will be assigning a few responsibilities in this example}

Expert suggests that we should look for a class that has the information needed to determine the grand total.

If our design is just beginning, we look at the Domain Model and bring the pertinent conceptual classes into the class model

Fall 2009 ACS-3913 Ron McFadyen 22

What information is needed to determine the grand total?

It is necessary to know all the SalesLineItem instances of a sale and to sum their subtotals. A Sale instance is aware of these … Sale is the Expert choice for having the responsibility of knowing the grand total.

Sale

Sales LineItem Product

Description

contains

Described by

1

1..*

*1

Fall 2009 ACS-3913 Ron McFadyen 23

Consider figure 17.15 …

Expert leads us to place the method getTotal() in Sale

Fall 2009 ACS-3913 Ron McFadyen 24

Consider figure 17.16 …

A line item knows its quantity and the associated Product, so it is the expert … SalesLineItem should determine the line item subtotal

… another method, getSubTotal() required in SalesLineItem

Fall 2009 ACS-3913 Ron McFadyen 25

Consider Figure 17.17 …

Only the ProductDescription knows the price; so ProductDescription needs a method ...

… another method getPrice() required in ProductDescription

Fall 2009 ACS-3913 Ron McFadyen 26

Creator

• What object should have the responsibility to create an X?

– Ignores special-case patterns such as Factory… later GoF

• Choose an object C, such that:

– C contains or compositely aggregates X

– C closely uses X

– C records instances of X objects

– C has the initializing data for X

Fall 2009 ACS-3913 Ron McFadyen 27

Example: Who should be responsible for creating a SalesLineItem? Since Sale “contains” SalesLineItems, Creator suggests Sale as the candidate for this responsiblity

Sale

Sales LineItem Product

Description

contains

Described by

1

1..*

*1

Fall 2009 ACS-3913 Ron McFadyen 28

:Register

:SalesLineItem

makeLineItem(qty)

create(qty)

:Sale

We assign the responsibility of creating a SalesLineItem to Sale – Sale will have a method makeLineItem

Fall 2009 ACS-3913 Ron McFadyen 29

Low CouplingHigh Cohesion

We use the same example, “creating a payment”, for both of these patterns.

Both patterns happen to suggest the same collaboration

Fall 2009 ACS-3913 Ron McFadyen 30

Low Coupling

• When we need to assign a responsibility to a class, we should do so such that coupling remains low.

• Coupling: a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.

• Low coupling: not dependent on too many other elements

• High coupling results in

– classes that are harder to understand in isolation

– changes to related classes force local changes

– classes that are harder to reuse

Fall 2009 ACS-3913 Ron McFadyen 31

Low Coupling

• Example

Assume we need to create a Payment instance … what class should do this?

Fall 2009 ACS-3913 Ron McFadyen 32

Creator pattern suggests Register

Register creates Payment (Collaboration diagram)

Fall 2009 ACS-3913 Ron McFadyen 33

An alternative design

Which of the two designs supports lower coupling?

Fall 2009 ACS-3913 Ron McFadyen 34

High Cohesion

• How do we assign responsibilities so that cohesion remains high?

• Cohesion: a measure of how strongly related and focused the responsibilities of an element are.

– Cohesion is a measure of how single purpose the attributes and behavior within a class are

– It is better that attributes and behaviour in classes be related.

• A class with highly related responsibilities and which does not do excessive amounts of work has high cohesion

Fall 2009 ACS-3913 Ron McFadyen 35

High Cohesion

•Rule of Thumb (ROT): A class with high cohesion has a relatively small number of methods, with highly related functionality, and does not do too much work … it collaborates with others to get work done.

•Low cohesion results in classes that

–are hard to comprehend

–hard to reuse–hard to maintain

–delicate - constantly affected by change

Fall 2009 ACS-3913 Ron McFadyen 36

High Cohesion

•ExampleAssume we need to create a Payment instance … what class should do this?

Fall 2009 ACS-3913 Ron McFadyen 37

First solution

Fall 2009 ACS-3913 Ron McFadyen 38

second solution

Which solution supports higher cohesion for Register?

Fall 2009 ACS-3913 Ron McFadyen 39

Note, when considering which class to assign the responsibility of creating a payment, the text arrives at the same solution when applying both principles