Object-Oriented Design Part 2

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

What are you goingto learn about today? • More patterns to help you make good object-oriented design decisions http://flic.kr/p/8JpkTg

Iterative Development Process We are here Analysis Requirements Design InitialPlanning Implementation Planning Testing Evaluation Deployment

Recall: Responsibility-Driven Design Frames object design as deciding • How to assign responsibilities to objects • How objects should collaborate http://flic.kr/p/btp5ZK

Recall: Two types of object responsibilities • 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

Recall: Objects collaborate by sending messages Register collaborates with Sale and Payment to process a sale

Recall: Assigning responsibilities anddesigning collaborations is hard • No mechanical method • Requires expert human judgment! • Fortunately there’s patterns! • Tried and true template solutions to common problems Let’s look at 4 more of Larman’s GRASP patterns

? ? Design Question #1 Recall this design: Register handles all system operations Model View

? ? Design Question #1 What class should be responsible for this? Assume we need to create a Payment instance and add it to a Sale instance

Recall these competing designs Registerresponsible Saleresponsible Coupling is one criteria for choosing, but there is another criteria…

High Cohesion Pattern Assign responsibilities so that cohesion remains high Cohesion: Measure of how strongly related and focused the responsibilities of a class/package/etc are

Critique of first design How does adding the responsibility of creating payments affect Register’s cohesiveness? It may not seem like a big deal in this small example, but what if Register is responsible for a large number of user operations?

Problems with low cohesion Elements with low cohesion are • Hard to understand • Hard to reuse • Hard to maintain • Brittle (affected by change)

By delegating creating Payment to Sale, this design promotes higher cohesion in Register

Coupling and Cohesion are interrelated • Coupling: how strongly one element depends on others • Lower coupling = better • Cohesion: how focused an element’s responsibilities are • Higher cohesion = better • The lower the coupling, the higher the cohesion tends to be and vice versa

? ? Design Question #2 Why is this design fragile (in the face of change)? public void fragileMethod() { AccountHolder holder = sale.getPayment().getAccount().getAccountHolder(); ... } • Depends too much on object structure—a common point of instability • Coupling: Couples “this” to many classes • Cohesion: “This” has added responsibility of knowing how to use those classes

Law of Demeter – “Don’t talk to strangers” • Within a method, only send messages to: • The “this” object • A parameter of the method • An attribute of “this” • An element of a collection which is an attribute of “this” • An object created within the method Stranger and stranger… public void fragileMethod() { AccountHolder holder = sale.getPayment().getAccount().getAccountHolder(); ... }

? ? Design Question #3 How to make different calculators pluggable?We’ll need to decouple tax calculator from Sale, but how? Assume: • System uses external third-party tax calculator • Many different kinds, such as: TaxMaster GoodAsGoldTaxPro

Indirection Pattern To decouple two classes, assign responsibility to an intermediate object to mediate between the two • Intermediary creates indirection

Example intermediary adapter for decoupling Sale and TaxMaster class Adds level of indirection : TaxMaster

? ? Design Question #4 How do we make tax calculators interchangeable? • Tax calculators have similar but varying interfaces • One supports raw TCP socket protocol • Another has SOAP interface TaxMaster GoodAsGoldTaxPro … TCP-related operations … … SOAP-related operations …

Protected Variations Pattern To reduce the potential drawbacks of design instability: • Identify points of variation/instability • Create stable interface (in the broad sense) around such points

Example use of Protected Variations Pattern to decouple Sales and tax calculators Wrap all the different calculator adapters with one interface

? ? Design Question #5 How to wrap tax calculators with interface? ??????????????????????? <???> TaxMaster GoodAsGoldTaxPro

Polymorphism Pattern When related behaviors vary by class, use polymorphic operations to handle the behaviors Polymorphic operations: Operations of different objects that have the same signature, making the objects/methods interchangeable

How to apply Polymorphism to tax calculators Adapters share same interface but have different implementations adaptee adaptee adaptee <???> TaxMaster GoodAsGoldTaxPro Thus, different tax calculators can be swapped in and out

How have you used polymorphismin your project? http://flic.kr/p/9ksxQa

Summary • More patterns • High Cohesion • Indirection • Protected Variations • Polymorphism • Plus • Coupling vs cohesion • Law of Demeter http://flic.kr/p/YSY3X

Object-Oriented Design Part 2