34
Object-Oriented Design Par p://flic.kr/p/btp5ZK

Object-Oriented Design Part 2

  • Upload
    oliana

  • View
    20

  • Download
    0

Embed Size (px)

DESCRIPTION

Object-Oriented Design Part 2. http://flic.kr/p/btp5ZK. Responsibility-Driven Design. Frames object design as deciding How to assign responsibilities to objects How objects should collaborate What role each each object should play in a collaboration. http://flic.kr/p/btp5ZK. - PowerPoint PPT Presentation

Citation preview

Page 1: Object-Oriented Design Part 2

Object-Oriented Design Part 2http://flic.kr/p/btp5ZK

Page 2: Object-Oriented Design Part 2

Responsibility-Driven Design

Frames object design as deciding•How to assign responsibilities to objects•How objects should collaborate– What role each each object should play in a collaboration

http:

//fli

c.kr

/p/b

tp5Z

K

Page 3: Object-Oriented Design Part 2

What is meant by responsibilities

An object’s obligations (and thus behavior)Two types:•Doing responsibilities, e.g.:– Creating an object– Calculating something– Initiating action on other objects– Coordinating activities among other objects

•Knowing responsibilities, e.g.:– Knowing about data– Knowing about related objects– Knowing about things it can derive or calculate

Page 4: Object-Oriented Design Part 2

Domain Model attributes inspireknowing responsibilities

Design

Analysis

Register knows its ID Sale knows its time

Page 5: Object-Oriented Design Part 2

What is meant by collaboration?

Objects interact (via messages) to fulfill responsibilities•Example: Register collaborates

with Sale and Paymentto process a payment

(its responsibility)

Page 6: Object-Oriented Design Part 2

Responsibilities vary in granularity

• “Big” responsibilities may require collaborations of many objects

• “Small” responsibilities may be fulfilled by a single object

Page 7: Object-Oriented Design Part 2

How to assign responsibilities and

design collaborations?

• No mechanical method– Requires expert human

judgment!

• But there’s hope: patterns!

http://flic.kr/p/4tTsQe

Page 8: Object-Oriented Design Part 2

Patterns

• Repeatable solution for a commonly occurring software problem

• Codify existing tried-and-true knowledge• Provide vocabulary

Page 9: Object-Oriented Design Part 2

Point of Sale Example

• Think of a cashier’s register– Cashier scans or manually enters the price of items– All items sold make up a sale– Payment is received, change is given– A receipt is generated

Page 10: Object-Oriented Design Part 2

What object should be responsible forcreating a SalesLineItem?

POS Design Question

Page 11: Object-Oriented Design Part 2

Creator Pattern

Assign class B responsibility of creating instances of class A if 1+ of the following:•B “contains” A•B records A•B closely uses A•B has initializing data for A– B is an expert with respect to creating A

Page 12: Object-Oriented Design Part 2

What object should be responsible for creating a SalesLineItem?

The Creator Pattern says that Sale should create

SalesLineItem

POS Design Question

Page 13: Object-Oriented Design Part 2

How a Sale object might createa SalesLineItem object

: Register : Sale

Page 14: Object-Oriented Design Part 2

What object should be responsible forknowing the grand total of a sale?

POS Design Question

Page 15: Object-Oriented Design Part 2

Information Expert Pattern

Assign a knowing responsibility to the class that has the information necessary to fulfill the responsibility

Page 16: Object-Oriented Design Part 2

What object should be responsible forknowing the grand total of a sale?

POS Design Question

The Information Expert Pattern says that Sale should

know the grand total

Page 17: Object-Oriented Design Part 2

How Sale might calculate the grand total

Sale will need a method for computing the total

Page 18: Object-Oriented Design Part 2

How Sale might calculate the grand total

Sales will get the subtotal from each SalesLineItem

Page 19: Object-Oriented Design Part 2

How Sale might calculate the grand total

SalesLineItem will need to get the price from ProductDescription

Page 20: Object-Oriented Design Part 2

How Sale might calculate the grand total

These three objects collaborate to compute the grand total

Each one must fulfill its own set of responsibilities

Page 21: Object-Oriented Design Part 2

What class should be responsible for this?

POS Design Question

Assume we need to create a Payment instance and associate it with a Sale instance

Page 22: Object-Oriented Design Part 2

One possible design: Register creates Payment

Page 23: Object-Oriented Design Part 2

Another possible design: Sale creates Payment

Page 24: Object-Oriented Design Part 2

Which design is better?

Page 25: Object-Oriented Design Part 2

Low Coupling Pattern

Assign responsibilities so that coupling stays low

Coupling: measure of how strongly one element•is connected to others•has knowledge of others•relies on others

Page 26: Object-Oriented Design Part 2

Common types of coupling in OO languages

Class C is coupled to class D if•C has instance variable that refers to D•C invokes method/function of D•C method parameter or local variable references D•C is direct or indirect subclass of D•C implements interface D

Page 27: Object-Oriented Design Part 2

Problems with high coupling

Given class C highly coupled to class D:•Changes in D may force changes in C•Harder to understand C in isolation•Harder to reuse C because of dependencies on D

Page 28: Object-Oriented Design Part 2

Which design has lower coupling?Assuming Sale will eventually need to be coupled with Payment

First design adds extra coupling between Register and Sale so second design has lower coupling

Page 29: Object-Oriented Design Part 2

Critique: Other considerations may override preference toward low coupling

• Strength of coupling should be balanced against other design considerations

Critique: High coupling to stable/pervasive elements is seldom a problem

• Consider coupling to Java standard libraries

Page 30: Object-Oriented Design Part 2

Review of Key OO Concepts

• Objects/Classes• Information Hiding – The ability to protect class contents from

external entities– Private/Protected

• Inheritance – The ability for a class to extend and override functionality of another class– Generalization/Specification

• Interface – A contract of functionality other classes can implement

• Polymorphism – The ability to create an entity that has more than one type

Page 31: Object-Oriented Design Part 2

Design Advice

• Inputs for your design– Use Cases– Sequence Diagrams– Prototypes– Dataflow Diagrams– Architecture Diagrams

Page 32: Object-Oriented Design Part 2

Best practices

• Use known design patterns– Creator– Information Expert– More to come on the next class

• Take advantage of tried-and-true libraries– Don’t reimplement something that’s already been done

• Ex: Use known encryption libraries, they have been thoroughly tested and much less likely to have bugs

Page 33: Object-Oriented Design Part 2

Vision Statement

• Next week we’ll start Agile• Everyone will create a new vision statement with a

new topic using the same specification as HW 0• Consider a solution that lends itself to an iterative

design• These will be due next Monday

Page 34: Object-Oriented Design Part 2

What’s next for you?

• HW 3 is due tomorrow by midnight• HW 4 is posted• Think about your new vision statements