MSO Lecture 6. Wouter Swierstra (adapted by HP) September 28, 2017

Transcription

1 1 MSO Lecture 6 Wouter Swierstra (adapted by HP) September 28, 2017

2 2 LAST LECTURE Case study: CAD/CAM system What are design patterns? Why are they important? What are the Facade and Adapter patterns?

3 3 THIS LECTURE What is the strategy patten? What is the bridge pattern?

4 4 RECALL: UP VS AGILE The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

5 AGILE SOFTWARE DEVELOPMENT WITH SCRUM 5

6 6 DESIGN IN AN AGILE SETTING Agile programming emphasises not to invest too much time in Big Design Up Front.

7 7 DESIGN IN AN AGILE SETTING Agile programming emphasises not to invest too much time in Big Design Up Front. Does that mean that design patterns are no longer relevant?

8 8 DESIGN IN AN AGILE SETTING Agile programming emphasises not to invest too much time in Big Design Up Front. Does that mean that design patterns are no longer relevant? Shalloway and Trott argue that by learning design patterns you will learn the qualities of good code and good design.

9 9 AGILE VS DESIGN PATTERNS Agile practices focus on: No redundancy; Readability; Testability. But Design Patterns value the same principles!

10 10 NO REDUNDANCY Never, never duplicate code. Copy-paste is a sin. Why? This leads to strange coupling behaviour and unmaintainable code. Instead: encapsulate change-sensitive code behind a well defined interface. Applying design patterns can encourage code reuse.

11 11 READABILITY Choose the names of objects and methods to reveal their intent. Whenever you feel the need to comment something, write a method instead. (Martin Fowler) Aim for short, cohesive methods in line with design pattern philosophy.

12 TESTABILITY "Code that is tightly coupled or weakly cohesive is harder to test." 12

13 13 TESTABILITY You may not have experienced this first hand, but some code is very hard to test. In particular, code that is tightly coupled or weakly cohesive is harder to test. You need to do a lot of work to set up your tests it may even be impossible (tightly coupled); Your tests may not measure the right thing (weakly cohesive). Decoupling these issues and writing cohesive classes and methods makes testing easier: exactly what is advocated by our three design principles and design patterns in general.

14 14 INCREMENTAL DELIVERY Agile focuses on delivering new product increments in every iteration. But some features are too big to implement in a single iteration. Instead, you may want to lay the groundwork and implement a partial solution first. And extend this later. But how can you design a partial solution that is easy to extend?

15 15 IN SUMMARY... Although the design pattern philosophy may seem at odds with Agile/XP practices they share the same ideas about what makes great code.

16 16 MOTIVATING EXAMPLE: VIDEO RENTAL STORE Customer statement() 1 * Rental daysrented:int * 1 Movie pricecode : int title : string

17 17 INITIAL CLASSES The Movie class defines three price codes as integer constants: CHILDREN = 0 STANDARD = 1 NEW = 2 The Rental class tracks the number of days a particular movie has been rented. Finally, the Customer class records a list Rentals.

18 18 BUT..., BEWARE OF THE WICKED SWITCH! switch (v.getmovie().getpricecode()) { case Movie.STANDARD : v_price = 3 euro * v.daysrented; break case Movie.NEW : v_price = 5 euro * v.daysrented; break case Movie.CHILDREN : v_price = 2 euro * v.daysrented }

19 19 WICKED SWITCHES! Switch commands are not bad in an intrinsic sense but they carry that smell especially when they are annoying. Do not confront programmers with switches if making the choice with respect of specific details is not their prime responsibility! When programming the control flow of a rental, you should not not be concerned with annoying details

20 Use inheritance! 20

21 21 Movie calculaterate(int days) ChildensMovie StandardMovie NewMovie

22 22 BUT THEN... The video store owner calls.

23 23 BUT THEN... The video store owner calls. We will not only rent movies,...

24 24 BUT THEN... The video store owner calls. We will not only rent movies, but also provide streaming services,...

25 25 BUT THEN... The video store owner calls. We will not only rent movies, but also provide streaming services, which also involves a new quality level: UHD

26 26 Requirements always change.

27 27 WHY DESIGN? If requirements always change, what good are design patterns? Or any upfront design? Isn t quick-and-dirty programming just as effective?

28 28 AN ANALOGY Every time I print a document, it is easier for me to put it on my desk, than file it away. This works fine if I only ever have ten documents to manage. But if I need to handle more documents, I need to invest in maintaining some kind of system. Lesson: Cutting corners in the short term, may have a price to pay in the long term.

29 29 EXCUSES, EXCUSES... We don t know what requirements are going to change. If we try to see how things will change, we ll stay in analysis... If we try to write our software that is extensible, we ll stay in design forever. We don t have the money. We don t have the time. I ll get to it later...

30 30 PICK YOUR POISON It would seem that there are only two choices: Overdesign. Quick and dirty.

31 31 A THIRD WAY You don t need to fix the design upfront but you do need to think about where the changes are most likely to happen. If you think about this beforehand, the investment to write adaptable code is much lower than having to refactor a large code base post hoc.

32 32 SOME PRINCIPLES OF GOOD DESIGN Program to an interface, not an implementation. Favor aggregation over inheritance. Encapsulate the concept that varies. Applying these can help write code that is robust to change.

33 33 CASE STUDY: E-COMMERCE Suppose I need to write software for an online retailer (Amazon, Bol,... ). I know that different countries have different address formats, tax rules, or shipping costs. Even if I do not yet know which countries I will ship to, or how these issues will be implemented exactly, I do know where to expect variation.

34 34 GENERAL ARCHITECTURE Introduce a controller object that processes sales requests. It delegates the handling of sales to a SalesOrder class: Allows for filling out the order with a GUI; Handles tax calculation; Processes the order; Prints a receipt. (Possibly with the help of other classes.)

35 35 HANDLING NEW CASES How can I handle new taxation rules? There are a few alternatives you may already be familiar with: Copy-and-paste; Switches or ifs; Inheritance. But these techniques all have drawbacks...

36 36 COPY-AND-PASTE Need new rules for calculating tax? Copy-and-paste the old rules and update them where necessary. Golden rule: Never, ever copy-and-paste code. You end up with two versions of the same code, which leads to maintenance nightmares.

37 37 CONDITIONALS public int computetax(mynation) switch(mynation) { case "NL": return price * 1.21; break; case "UK": // Insert code here break; } This works fine how extensible is it?

38 public int computeshipping(mynation) switch(mynation) { case "NL": // Insert code here break; case "UK": // Insert code here break; } 38

39 public int convertcurrency(mynation) switch(mynation) { case "NL": // Insert code here break; case "UK": // Insert code here break; } 39

40 40 HANDLING CHANGE What happens if I want to start shipping to Germany? Suddenly, I need to change lots of pieces of code, spread over different files: lack of cohesion! What happens if I need to ship to both French-speaking and Dutch-speaking parts of Belgium? Even more complex cases...

41 41 INHERITANCE SalesOrder calculatetax() NLOrder UKOrder

42 42 INHERITANCE: A CRITICAL EVALUATION Introducing this class hierarchy enables us to vary the tax calculation in every subclass. But what about handling other variations: Different languages (like in Belgium); Different date formats; Different shipping costs; Different address formats;... How can I share code between subclasses? Many modification may require us to revisit the entire hierarchy.

43 43 A BETTER APPROACH Find what varies and encapsulate it in a class of its own. 2. Contain this class in the original class.

44 44 MORE CONCRETELY 1. The tax calculation across different countries is different. We need to introduce a separate class, CalcTax. 2. Every SalesOrder should have a CalcTax.

45 45 SalesOrder CalcTax calculatetax(price : double) NLTax UKTax

46 46 ANOTHER EXAMPLE 1. Different kinds of movies have different rental rates. We need to introduce a separate class, RateCalculator. 2. Every Rental should have a RateCalculator.

47 47 Rental RateCalculator calculaterate(daysrented : int) NewMovie ChildrensMovie StandardMovie

48 48 OR IN CODE public class Rental { private ratecalculator RateCalculator;... }

49 abstract class RateCalculator { public abstract int calculaterate(days int) } 49

50 50 class NewMovieRateCalculator : RateCalculator { public override int calculaterate(days int) { // New movies cost 5 euros per day to rent return 5 * daysrented; } } And similar implementations for other price classes.

51 51 WHY IS THIS BETTER THAN INHERITANCE? Cohesion is stronger There is one place where all rate calculation happens. Easier to shift responsibility. Users of the SalesOrder or Movie class do not need to decide how to compute taxes or rental prices. When a New movie is no longer New, future rentals will assign the right RateCalculator.

52 52 IS INHERITANCE BAD? This solution still uses inheritance (NewMovieCalculator is a subclass of RateCalculator). But it uses it very carefully, to capture a single kind of variation.

53 53 THE STRATEGY PATTERN Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it. The Gang of Four, describing the Strategy pattern s intent.

54 STRATEGY PATTERN Intent: Use different business rules or algorithms depending on the context. Problem: The selection of a computation that needs to be performed depends on the client making the request or the data being acted on. Solution: Separate the selection of the algorithm from the implementation of the algorithm. Allows for the selection to be made in context. Participants: The Strategy class specifies the different algorithms; ConcreteStrategy implements such an algorithm; Context uses a specific ConcreteStrategy. Consequences: Defines a family of algorithms; Switches/conditionals can be eliminated; You invoke all algorithms in the same way. 54

55 55 STRATEGY: IMPLEMENTATION Client Context Strategy computation(...) ConcreteStrategyA computation(..) ConcreteStrategyB computation(..) ConcreteStrategyC computation(..)

56 56 NOTES ON USING THE STRATEGY PATTERN The computation in the ConcreteStrategy classes may need extra information. It is the responsibility of the Context to gather the required information and pass it to the computations. Applying the Strategy class makes it easier to test code. You can write unit tests for individual ConcreteStrategy objects, without having to worry about the rest of the context.

57 57 EXERCISE Take a thorough look at the code on pp in Shalloway and Trott. Can you relate it to the diagram of figure 9-4? Where will the switch take place?

58 58 THE BRIDGE PATTERN Intent: Decouple an abstraction from its implementation so the two can vary independently.

59 59 THE BRIDGE PATTERN Intent: Decouple an abstraction from its implementation so the two can vary independently. Huh?

60 60 THE BRIDGE PATTERN The Bridge pattern is one of the most complicated patterns we ll see but once you understand the principles of object oriented design, it should make sense. So remember: Favour aggregation over inheritance; Find what varies and encapsulate it;

61 61 TOWARDS THE BRIDGE PATTERN Case study: Suppose I have to write a game that works on different platforms. Both these platforms have a similar graphics library, but there are subtle differences in the interface. How do I encapsulate the variation?

62 62 USE INHERITANCE! Mario +draw() ios Mario + draw() Android Mario + draw() ios Graphics + drawpixel(x,y) + setcolor(c) Android Graphics + setpixel(x,y,c)

63 63 USE INHERITANCE Mario +draw() ios Mario + draw() Android Mario + draw() ios Graphics + drawpixel(x,y) + setcolor(c) Android Graphics + setpixel(x,y,c) Question: Where might there be duplicate code? What happens when I need to ship to another platform?

64 64 CODE DUPLICATION The two draw methods are probably very similar. Duplicate code is a Very Bad Thing. Can we avoid this duplication?

65 65 INHERITANCE AND OVERLOADING Mario # setpixel(x,y,c) + draw() ios Mario #setpixel(x,y,c) Android Mario #setpixel(x,y,c) ios Graphics + drawpixel(x,y) + setcolor(c) Android Graphics + setpixel(x,y,c)

66 66 BUT THEN... Of course, the requirements will change. Suppose we need to draw both Mario and Luigi with both drawing programs... Introduce an abstract class Plumber; Introduce abstract subclasses, Mario and Luigi, of the Plumber class; Introduce two concrete implementations for both drawing programs for both the Mario and the Luigi class.

67 67 Plumber +draw() Mario +draw() #setpixel(x,y,c) Luigi +draw() #setpixel(x,y,c) ios Mario #setpixel(x,y,c) Android Mario #setpixel(x,y,c) ios Luigi #setpixel(x,y,c) Android Luigi #setpixel(x,y,c) ios Graphics Android Graphics

68 68 EVALUATING THIS DESIGN This solves our original problem but: introducing a new Plumber requires the definition of three new classes (one abstract and one implementation for each drawing program). introducing a new Graphics platform requires a new subclass for every Plumber. the abstraction (the different kinds of Plumbers) and their implementation (the different kinds of Graphics classes) are tightly coupled. there is redundancy the different concrete Luigi or Mario classes may share a lot of code.

69 69 CAN WE DO BETTER? So maybe this was not the right design choice. Perhaps we should introduce two abstract Plumber classes, one for each platform program...

70 70 Plumber +draw() Android Plumbers #setpixel(x,y,c) ios Plumbers #setpixel(x,y,c) AndroidMario +draw() AndroidLuigi +draw() ios Mario +draw() ios Luigi +draw() Android Graphics ios Graphics Question: Problem solved?

71 71 EVALUATING THIS DESIGN This design does split things up differently, but it still suffers from many of the same disadvantages as our previous approach: duplicate code in the Android Mario and ios Mario classes (and also for Luigi of course); introducing new platforms requires a new abstract class, together with a new concrete implementation for each different Plumber; introducing a new Plumber requires a new concrete implementation for each different Graphics platform. the implementations and abstractions are still too tightly coupled.

72 72 THE BRIDGE PATTERN Intent: Decouple an abstraction from its implementation so the two can vary independently. Here we have precisely this situation: we have different Plumbers (abstractions) that we want to draw with different Graphics platforms (implementations). How can we decouple the abstractions and implementations?

73 73 THE BRIDGE PATTERN Let s try to derive the Bridge pattern ourselves, by simply applying some of the principles of good object oriented design: Find what varies and encapsulate it; Favour aggregation over inheritance; Program to an interface, not an implementation.

74 74 COMMONALITY-VARIABILITY ANALYSIS We want to support different kinds of plumbers and different kinds of Graphics platforms: We want to be able to draw a Plumber (although Mario and Luigi get drawn differently); Our drawing programs support the drawing of individual pixels (even if they do so differently).

75 75 STARTING THE DESIGN... Plumber +draw() Graphics +setpixel(x,y,c) This tries to capture the commonality between the different Plumbers and the different Graphics platforms.

76 76 INTRODUCING VARIATION. Next we want to introduce some variation: We have two different kinds of Plumber; We have two different kinds of Graphics; Let s try adding some subclasses...

77 77 INTRODUCING VARIATION Plumber +draw() Graphics +setpixel(x,y,c) Mario +draw() Luigi +draw() Android Graphics +setpixel(x,y,c) ios Graphics +setpixel(x,y,c) Find what varies and encapsulate it.

78 HOW ARE THE TWO RELATED? Favour aggregation over inheritance let s not try to introduce any further subtypes for the moment. Should Graphics use a Plumber object? Probably not. Then the Graphics would need to inspect what kind of Plumber they have to figure out how to draw them. Should Plumber use Graphics? Yes! When a Plumber needs to be drawn, we will use functions from Graphics and we do not want to worry about the platform (Android/iOS) We are free to use different drawing programs, because the Plumber class programs to an interface, not an implementation. 78

79 79 THE BRIDGE PATTERN Plumber +draw() Graphics +setpixel(x,y,c) Mario +draw() Luigi +draw() Android Graphics +setpixel(x,y,c) ios Graphics +setpixel(x,y,c) ios Engine +drawpixel(x,y) +setcolor(c)

80 80 EVALUATING THE BRIDGE How well does this separate implementations (Graphics) from the abstractions (Plumbers)?

81 81 Plumbers (abstractions) Plumber +draw() Graphics (implementations) Graphics +setpixel(x,y,c) Mario +draw() Luigi +draw() Android Graphics +setpixel(x,y,c) ios Graphics +setpixel(x,y,c) ios Engine +drawpixel(x,y) +setcolor(c)

82 82 Did you spot another pattern? Which one?

83 83 THE BRIDGE PATTERN Intent: Decouple a set of implementations from the objects using them. Problem: The derivations of an abstract class must use multiple implementations, without causing an explosion in the number of classes; Solution: Define an interface for all implementations to use and have the derivations of the abstract class use that. Consequences: The decoupling of the implementations from the objects that use them increases extensibility. Client objects are not aware of implementation issues.

84 84 BRIDGE PATTERN: IMPLEMENTATION Abstraction +operation() Implementation +operationimpl() RefinedAbstraction +operation() ConcreteImpl1 +operationimpl() ConcreteImpl2 +operationimpl()

85 85 ONE RULE, ONE PLACE Design principle: If you have a rule for how to do something, only implement it once. Why? Maintainability: if the rule changes, there is only piece of code to update; Cohesion: the responsibility for this computation is in a single place;

86 86 DRAWBACKS OF THE BRIDGE PATTERN What happens if I want to add a new Plumber? If I can draw it using the setpixel method, all we need to do is define a new concrete subclass of the Plumber class.... but if I can t, I will need to change the interface that the abstract Graphics class defines, together with all its concrete implementations. Implementing the Bridge pattern solves one problem, but may introduce new problems or weaknesses in your design.

87 87 MATERIAL COVERED Design Patterns explained. Chapter Picture on slide 10 is taken from "The Hurt Locker"