The Open-Closed Principle - Part 1 - The Original Version
0 likes60 views
The Open-Closed Principle - Part 1 - The Original Version
- 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.