The Open-Closed Principle - Part 1 - The Original Version

The Open-Closed Principle - Part 1 - The Original Version.

Keywords: "open closed principle", "ocp", "bertrand meyer", "object oriented programming", "object oriented inheritance", "class inheritance", "implementation inheritance"

1. @philip_schwarz deck by https://fpilluminated.org/ Bertrand Meyer Henrik Christensen
2. Tension Between known needs of today changes that will arrive in the future Sandi Metz The Fundamental Target of Design
3. Code needs to work today just once, and it needs to be easy to change forever
4. It is at this point of tension where design matters today’s needs future changes
5. its purpose, its entire reason for being, is to reduce the cost of change.
6. 1999 3rd Apr 2014 @KentBeck design is irrelevant for today. it only matters when we want to change the software... @KentBeck change is the only reason to organize software at all… Kent Beck
7. adopted by agile community as a truth about software development Henrik Christensen 2010
8. “software must be designed and developed to make it easy to change”
9. Let’s examine software qualities that enable ease of change Look for definitions in ISO 9126 Projects sometimes fail due to not having any clear definitions of "success” This standard tries to develop a common understanding of project objectives and goals, e.g. software qualities
10. Software is Reliabile if it can maintain a specific level of performance under specific usage conditions
11. in our setting… In particular, we are interested in preserving reliability in the face of change Software is Reliabile if it can perform the required functions without failing
12. “maintainability is composed of several, finer grained, qualities”
13. Analysability Maintainability Changeability Stability Testability Software is Analysable if you can • diagnose it for § deficiencies § causes of failure • identify the parts to be modified “Analysability is basically the ability to understand software”
14. Analysability Maintainability Changeability Stability Testability Software is changeable if it allows you to • implement a specific modification • add, modify, or enhance a feature at a reasonable cost “almost all Design Patterns are geared towards increasing design’s changeability”
15. Analysability Maintainability Changeability Stability Testability “Software is flexible if you can add/enhance functionality purely by adding software units and specifically not by modifying existing software units” Flexibility a special case of changeability
16. Changeability Behavioural changes that are introduced by modifying existing production code Changeability is a desirable quality, but it relies on Change by Modification Change by Modification “The less I ever modify a class, the higher the probability that it will remain free of defects” Modifications carry the risk of introducing defects, and the necessary cost of avoiding them: testing, code reviewing, etc.
17. Behavioural changes that are introduced by modifying existing production code Change by Modification Change by Addition Behavioural changes that are introduced by adding new production code instead of modifying existing code Contrast Change by Addition avoids (risky) modifications altogether with
18. Changeability Change by Addition Change by Modification Changeability does not take a stand point with regards to the way a specified modification is implemented Flexibility In contrast, Flexibility does take this stand point and requires that no modifications are made
19. Analysability Maintainability Changeability Stability Testability Software is Stable if it avoids unexpected effects when modified “I advocate the practice to avoid modifying existing code but preferably add features or modify existing ones by other means” Flexibility “any change to existing software carries a risk of introducing defects”
20. Changeability Stability Flexibility Reliability Change by Modification Change by Addition - + - + Summary + supports - risks undermining relies on
21. Question: how do we promote flexibility, reliability and stability in our software? Analysability Maintainability Changeability Stability Testability Flexibility Reliability
22. Answer: we favour ‘Change by Addition’ over ‘Change by Modification’ Changeability Stability Flexibility Reliability Change by Modification Change by Addition - + - +
23. I cover techniques that focus on flexibility Christensen if you require that s/w can adapt to changing requirements without modifying the production code then you need to employ a SPECIAL set of design and programming techniques as well as adopt a SPECIAL mindset
24. “Another way of characterising Change by Addition that you may come across is the Open Closed Principle” How do we achieve ? Change by Addition
25. The Open-Closed Principle Modules should be both open and closed Bertrand Meyer Object Oriented Software Construction The most comprehensive, definitive OO reference ever published 1988
26. Isn’t there a contradiction between the two terms? Modules should be both OPEN and CLOSED ¬(p ∧ ¬p)
27. The contradiction is only apparent The two terms correspond to goals of a different nature e.g. a Dutch door can be both OPEN and CLOSED It is a
28. So let’s look at the goals of the OCP OCP
29. A module is said to be OPEN if it is still available for extension or add fields to its data structures Data Structures fields + operations e.g. it should be possible to expand its set of operations
30. A module is said to be CLOSED If it is available for use by other modules Has a well-defined, stable description (its interface – in information hiding sense) public part secret part interface 1 can be compiled, stored in a library, and made available for clients to use 2 in the case of a design or specification module: • approved • baselined in version control • its interface published for benefit of other module authors 3
31. OPEN if it is still available for extension CLOSED If it is available for use by other modules Recap – A module is…
32. It is impossible to foresee all the elements that a module will need in its lifetime X The need for ness so developers wish to keep the module open for as long as possible so that they can address changes, and extensions by changing elements or adding new elements
33. The need for ness if a module is never closed until it is certain that it contains all the needed features x every developer would always be waiting for completion of another developer's job then multi-module s/w can never reach completion x in a system consisting of many modules, most modules will depend on some others but it is also necessary to close modules
34. Modules should be both open and closed We want modules to be both for extension and for modification
35. the two goals of openness and closedness with traditional techniques are incompatible
36. either you keep a module open and others cannot use it yet and any change or extension can trigger a painful chain reaction of changes or you close it in many other modules which relied on the original module directly or indirectly
37. A B C D E A module and its clients A’ F G H I New clients which need A’, an adapted or extended version of A Typical situation where the needs for Open and Closed modules are hard to reconcile = client of
38. With non-OO methods, there seem to be only 2 solutions, equally unsatisfactory
39. A B C D E A F G H I Solution 1
40. A B C D E A F G H I Solution 1
41. A B C D E A’ F G H I Solution We have taken a copy of A and modified it, turning it into the desired A’
42. Solution Meyer’s Assessment the consequences are appalling an explosion of variants of the original module, many of them very similar, but never quite identical if you extrapolate its effects to • many modules • many modification requests • a long period of time
43. Solution (Source tree copy) Christensen’s Assessment Probably the main reason it is encountered so often in practice Easy to explain to colleagues & new developers No implementation interference X
44. Solution (Source tree copy) Christensen’s Assessment Quick but very dangerous In the long run it is often a real disaster… The solution has severe limitations.
45. because it leads to the multiple maintenance problem
46. Solution (Source tree copy) Christensen’s Assessment when you want to add/modify logic you have to: • Do it for each source tree • Write the same test cases for each source tree you have to do it in each source tree when you need to remove a defect
47. DRIFT Practice shows that over time the source trees evolve into completely different directions: they drift apart. After a while it is more or less like maintaining a set of completely different applications At that point, before you do any of the operations, you have to first analyse each source tree!!
48. Used in airports to generate reports of local weather one variant for each airport in Denmark init and config code Example SAWOS - Semi Automatic Weather Observation System 8 copies!!!
49. Analysability Stability Reliability solution - - - Summary multiple maintenance problem
50. That was Meyer’s first unsatisfactory solution to the problem of making modules both OPEN and CLOSED Let’s turn to the second one
51. A B C D E A’ F G H I A module and its clients New clients which need A’, an adapted or extended version of A = client of Problem
52. Solution 2 A B C D E A’ F G H I Change by Modification
53. A+ B C D E A’ F G H I We have modified A into A+, which can switch between two modes of execution In one mode it behaves like A, and in the other it behaves as expected of A’ Solution
54. A+ B C D E A’ F G H I We have modified A into A+, which can switch between two modes of execution In one mode it behaves like A, and in the other it behaves as expected of A’ Solution
55. A+ B C D E A’ F G H I if (variant == VARIANT_1) then { …. } else { …. } At points of variation, A+ looks like this: We have modified A into A+, which can switch between two modes of execution In one mode it behaves like A, and in the other it behaves as expected of A’ Alternatively, this can be a switch Solution
56. A+ B C D E A’ F G H I Solution – Meyer’s Assessment
57. A+ B C D E A’ F G H I The potential for disaster is obvious: changes to A may invalidate the assumptions on the basis of which the old clients used A. So the changes may start a dramatic series of changes in clients, client of clients....etc Solution – Meyer’s Assessment
58. A+ A’ F G H I Solution – Meyer’s Assessment The potential for disaster is obvious: changes to A may invalidate the assumptions on the basis of which the old clients used A. So the changes may start a dramatic series of changes in clients, client of clients....etc B C E D this is a nightmare for the proj. mgr. the system regresses and several modules have to be re- opened for dev/test/debug/documentation
59. Even though the Change solution has this problematic ripple effect, it is still better than the Copy solution. On the surface, the copy solution seems better because it avoids the ripple effect of change but in fact it may even be more catastrophic…it only postpones the day of reckoning We saw earlier the risks of an explosion of variants, many of them very similar, but never quite identical: Solution – Meyer’s Assessment solution solution
60. Solution (Parametric solution) Christensen’s Assessment Conditionals are easy to understand. So approach is easy to describe to other developers. Avoids Multiple Maintenance Problem Only one code base to maintain solution solution
61. Liabilities, most of which deal with long term maintainability Change by Modification Reliability Concerns – solution relies on with risk of introducing new defects Analysability concerns – as more and more requirements are handled by parameter switching, the code becomes less easy to analyse … Responsibility erosion – the software has, without much notice, been given an extra responsibility drives towards Procedural Design Blob aka God Class Solution (Parametric solution) Christensen’s Assessment
62. A reasonable approach at first, but one with serious problems for applications that need to grow over time Solution (Switches) Shalloway’s Assessment Not too bad as long as you just keep adding cases… 2004
63. but soon you need to introduce fall-throughs… …and then the switches are not as nice as they used to be
64. Eventually you need to start adding variations within a case. I like to call this switch The flow of the switches themselves becomes confusing, hard to read, hard to decipher. When a new case comes in the programmer must find every place it can be involved (often finding all but one of them). Suddenly things get bad in a hurry.
65. Analysability Stability Reliability solution - - - Summary Analysability Stability Reliability solution - - - With non-OO methods, there are only only 2 solutions available to us, BOTH UNSATISFACTORY multiple maintenance problem Change by Modification CHANGE COPY
66. If non-OO methods are all we have, then Meyer says we face a change or copy dilemma CHANGE COPY
67. A B C D E A’ F G H I So how can we have modules that are both and ? How can we keep A and everything in the top part of the figure unchanged, … …while providing A’ to the bottom clients, and avoiding duplication of software?
68. A B C D E A’ F G H I With the OO concept of inheritance Inheritance allows us to get out of the CHANGE OR COPY dilemma… …because inheritance allows us to define a new module A' in terms of an existing module A, …by stating only the differences between the two A’ defines new features, and redefines (i.e. modifies) one or more of A’s features inherits from Change by Addition
69. Thanks to inheritance, OO developers can adopt a much more incremental approach to software development than used to be possible with earlier methods OO inheritance
70. Hacking = Slipshod approach to building and modifying code Slipshod = Done poorly or too quickly; careless. The Hacker may seem bad but often his heart is pure.
71. He sees a useful piece of software, which is almost able to address the needs of the moment, more general than the software’s original purpose. Hacker Spurred by a laudable desire not to redo what can be reused, our hacker starts modifying the original to add provisions for new cases solution
72. The impulse is good but the effect is often to pollute the software with many clauses of the form if that_special_case then… if (<special case D>) then … if (<special case C>) then … if (<special case B>) then … if (<special case A>) then … switch
73. so that after a few rounds of hacking, perhaps by different hackers, the software starts resembling a chunk of Swiss cheese that has been left outside for too long in August – it has both holes and growth Hacking
74. Open-Closed Principle = One way to describe the OCP and the consequent OO techniques is to think of them as organised hacking Hacking The organised form of hacking will enable us to cater to the variants without affecting the consistency of the original version. Inheritance Change by Modification Change by Addition
75. if you have control over original s/w and can rewrite it so that it will address the needs of several kinds of clients …you should do so Caveats at no extra complication
76. The OCP principle and associated techniques are intended for the adaptation of healthy modules If there is something wrong with a module you should fix it… …not leave the original alone and try to correct the problem in the derived module Derived Base neither OCP nor redefinition in inheritance is a way to address design flaws, let alone bugs Design Flaw
78. its purpose, its entire reason for being, is to reduce the cost of change.
79. Question: how do we promote flexibility, reliability and stability in our software? Analysability Maintainability Changeability Stability Testability Flexibility Reliability
80. Answer: we favour ‘Change by Addition’ over ‘Change by Modification’ Changeability Stability Flexibility Reliability Change by Modification Change by Addition - + - +
81. How do we achieve ? Change by Addition which uses OO inheritance Inheritance We apply the Open-Closed Principle
82. multiple maintenance problem Change by Modification CHANGE solution COPY solution Hacker Change by Addition OCP solution Chooses Chooses switch
83. I hope you enjoyed that. See you in part two.