Learning Object-Oriented Design Part 2: Patterns for Good Design

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

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

3. Recall: Iterative development process We are here http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg

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

5. 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

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

7. 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 more of Larman’s GRASP patterns

8. ? ? POS Design Question What class should be responsible for this? Recall this problem from last time: Assume we need to create a Payment instance and associate it with a Sale instance

9. Assume that Register is responsible for handling all user operations

10. Recall these competing designs

11. 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

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

13. 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?

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

15. 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 beand vice versa

16. ? ? POS Design Question How to make different calculators pluggable? • External third-party tax calculators, such as • Tax-Master • Good-As-Gold Tax-Pro • Calculators have similar but varying interfaces • One supports raw TCP socket protocol • Another has SOAP interface

17. 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

18. ? ? POS Design Question How to make different calculators pluggable? Solution: Adapt the different calculators to a single interface with polymorphic operations

19. How to apply the Polymorphism Patternto tax calculators All objects who use a tax calculator collaborate with implementers of this interface Thus, different tax calculators can be swapped in and out

20. See the Java example of how to implement this How have you used polymorphism in your projects?

21. ? ? POS Design Question How to design objects so that instability of some objects does not undesirably affect others? • Designs of certain objects are more likely to change or vary • Their designs are unstable • Example: Tax calculator interfaces vary widely

22. 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

23. Example use of Protected Variations Pattern to decouple Sales and tax calculators Adapter interface wraps all the different calculators

24. 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(); ... }

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