Download as PDF, PPTX
Uploaded byPhilip Schwarz
The Open Closed Principle - Part 1 - The Original Version
This document discusses the Open Closed Principle of software design. It explores the tension between meeting today's needs while allowing for future changes. The principle advocates designing software that is open for extension, but closed for modification, by favoring changing software through addition of new code rather than modifying existing code. This reduces the risks and costs of unexpected defects when software is modified. The document examines how qualities like flexibility, reliability and stability can be promoted by following this principle.
More Related Content
Similar to The Open Closed Principle - Part 1 - The Original Version
The Open Closed Principle - Part 1 - The Original Version
- 1. The Open Closed Principle Part I The Original Version © 2014 Philip Schwarz h>ps://twi>er.com/philip_schwarz philip.johann.schwarz@gmail.com This work is licensed under a CreaHve Commons A>ribuHon-‐NonCommercial-‐NoDerivs 3.0 Unported License.
- 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 ma2ers today’s needs future changes
- 5. its purpose, its enHre reason for being, is to reduce the cost of change.
- 6. 1999 3rd Apr 2014 @KentBeck design is irrelevant for today. it only ma2ers when we want to change the so9ware... @KentBeck change is the only reason to organize so9ware at all…
- 7. adopted by agile community as a truth about soZware development Henrik Christensen 2010
- 8. “soZware must be designed and developed to make it easy to change”
- 9. Let’s examine soZware qualiHes that enable ease of change Look for definiHons in ISO 9126 Projects someHmes fail due to not having any clear defini=ons of "success” This standard tries to develop a common understanding of project objec=ves and goals, e.g. soZware qualiHes
- 10. SoZware is Reliabile if it can maintain a specific level of performance under specific usage condiHons
- 11. in our secng… In parHcular, we are interested in preserving reliability in the face of change SoZware is Reliabile if it can perform the required func=ons without failing
- 12. “maintainability is composed of several, finer grained, qualiHes”
- 13. Analysability Maintainability Changeability Stability Testability SoZware is Analysable if you can • diagnose it for § deficiencies § causes of failure • idenHfy the parts to be modified “Analysability is basically the ability to understand soZware”
- 14. Analysability Maintainability Changeability Stability Testability SoZware is changeable if it allows you to • implement a specific modificaHon • add, modify, or enhance a feature at a reasonable cost “almost all Design Pa2erns are geared towards increasing design’s changeability”
- 15. Analysability Maintainability Changeability Stability Testability “SoZware is flexible if you can add/enhance func=onality purely by adding so9ware units and specifically not by modifying exis=ng so9ware units” Flexibility a special case of changeability
- 16. Changeability Behavioural changes that are introduced by modifying exisHng producHon code Changeability is a desirable quality, but it relies on Change by Modifica=on Change by ModificaHon “The less I ever modify a class, the higher the probability that it will remain free of defects” ModificaHons carry the risk of introducing defects, and the necessary cost of avoiding them: tesHng, code reviewing, etc.
- 17. Behavioural changes that are introduced by modifying exisHng producHon code Change by ModificaHon Change by AddiHon Behavioural changes that are introduced by adding new producHon code instead of modifying exisHng code Contrast Change by Addi=on avoids (risky) modifica=ons altogether with
- 18. Changeability Change by AddiHon Change by ModificaHon Changeability does not take a stand point with regards to the way a specified modificaHon is implemented Flexibility In contrast, Flexibility does take this stand point and requires that no modifica=ons are made
- 19. Analysability Maintainability Changeability Stability Testability SoZware is Stable if it avoids unexpected effects when modified “I advocate the pracHce to avoid modifying exis=ng code but preferably add features or modify exis=ng ones by other means” “any change to exisHng soZware carries a risk of introducing defects”
- 20. Changeability Stability Flexibility Reliability Change by ModificaHon Change by AddiHon -‐ + -‐ + Summary + supports -‐ risks undermining relies on
- 21. Ques=on: how do we promote flexibility, reliability and stability in our soZware? Analysability Maintainability Changeability Stability Testability Flexibility Reliability
- 22. Answer: we favour ‘Change by Addi=on’ over ‘Change by Modifica=on’ Changeability Stability Flexibility Reliability Change by ModificaHon Change by AddiHon -‐ + -‐ +
- 23. I cover techniques that focus on flexibility Christensen if you require that s/w can adapt to changing requirements without modifying the produc=on 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 Addi=on that you may come across is the Open Closed Principle” How do we achieve ? Change by AddiHon
- 25. The Open-‐Closed Principle Modules should be both open and closed Bertrand Meyer Object Oriented SoZware ConstrucHon The most comprehensive, definiHve OO reference ever published 1988
- 26. Isn’t there a contradic=on between the two terms? Modules should be both OPEN and CLOSED ¬(p ∧ ¬p)
- 27. The contradic=on 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 sHll 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 opera=ons
- 30. A module is said to be CLOSED If it is available for use by other modules Has a well-‐defined, stable descripHon (its interface – in informaHon 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 specificaHon module: • approved • baselined in version control • its interface published for benefit of other module authors 3
- 31. OPEN if it is sHll 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 lifeHme 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 unHl it is certain that it contains all the needed features x every developer would always be waiHng for compleHon of another developer's job then mulH-‐module s/w can never reach compleHon x in a system consisHng 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 modificaHon
- 35. the two goals of openness and closedness with tradi=onal techniques are incompa=ble
- 36. either you keep a module open and others cannot use it yet and any change or extension can trigger a painful chain reac=on 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 situaHon 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 solu=ons, equally unsa=sfactory
- 39. A B C D E A F G H I SoluHon 1
- 40. A B C D E A F G H I SoluHon 1
- 41. A B C D E A’ F G H I SoluHon We have taken a copy of A and modified it, turning it into the desired A’
- 42.
- 43.
- 44.
- 45. because it leads to the mul=ple maintenance problem
- 46.
- 47. DRIFT PracHce shows that over Hme the source trees evolve into completely different direcHons: they dri9 apart. AZer a while it is more or less like maintaining a set of completely different applica=ons At that point, before you do any of the operaHons, 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 AutomaHc Weather ObservaHon System 8 copies!!!
- 49. Analysability Stability Reliability soluHon -‐ -‐ -‐ Summary mul=ple maintenance problem
- 50. That was Meyer’s first unsa=sfactory soluHon 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. SoluHon 2 A B C D E A’ F G H I Change by ModificaHon
- 53. A+ B C D E A’ F G H I We have modified A into A+, which can switch between two modes of execuHon In one mode it behaves like A, and in the other it behaves as expected of A’ SoluHon
- 54. A+ B C D E A’ F G H I We have modified A into A+, which can switch between two modes of execuHon In one mode it behaves like A, and in the other it behaves as expected of A’ SoluHon
- 55. A+ B C D E A’ F G H I If (variant == VARIANT_1) then { …. } else { …. } At points of varia=on, A+ looks like this: We have modified A into A+, which can switch between two modes of execuHon In one mode it behaves like A, and in the other it behaves as expected of A’ AlternaHvely, this can be a switch SoluHon
- 56. A+ B C D E A’ F G H I SoluHon – Meyer’s Assessment
- 57. A+ B C D E A’ F G H I The poten=al for disaster is obvious: changes to A may invalidate the assumpHons on the basis of which the old clients used A. So the changes may start a dramaHc series of changes in clients, client of clients....etc SoluHon – Meyer’s Assessment
- 58. A+ A’ F G H I SoluHon – Meyer’s Assessment The poten=al for disaster is obvious: changes to A may invalidate the assumpHons on the basis of which the old clients used A. So the changes may start a dramaHc 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/ documentaHon
- 59. Even though the Change soluHon has this problema=c ripple effect, it is sHll be2er than the Copy solu=on. On the surface, the copy solu=on seems be2er 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 iden=cal: SoluHon – Meyer’s Assessment soluHon soluHon
- 60.
- 61. LiabiliHes, most of which deal with long term maintainability Change by ModificaHon Reliability Concerns – soluHon 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 soZware has, without much noHce, been given an extra responsibility drives towards Procedural Design Blob aka God Class SoluHon (Parametric soluHon) Christensen’s Assessment
- 62. A reasonable approach at first, but one with serious problems for applicaHons that need to grow over Hme SoluHon (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 varia=ons 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 (o9en finding all but one of them). Suddenly things get bad in a hurry.
- 65. Analysability Stability Reliability solu=on -‐ -‐ -‐ Summary Analysability Stability Reliability solu=on -‐ -‐ -‐ With non-‐OO methods, there are only only 2 solu=ons available to us, BOTH UNSATISFACTORY mul=ple maintenance problem Change by ModificaHon 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 bo>om clients, and avoiding duplica=on of so9ware?
- 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 exis=ng module A, …by sta=ng 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 AddiHon
- 69. Thanks to inheritance, OO developers can adopt a much more incremental approach to soZware development than used to be possible with earlier methods OO inheritance
- 70. Hacking = Slipshodapproach to building and modifying code Slipshod = Done poorly or too quickly; careless. The Hacker may seem bad but oZen his heart is pure.
- 71. He sees a useful piece of soZware, which is almost able to address the needs of the moment, more general than the soZware’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 solu=on
- 72. The impulse is good but the effect is oZen to pollute the soZware 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 aZer a few rounds of hacking, perhaps by different hackers, the soZware starts resembling a chunk of Swiss cheese that has been leZ 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 affec=ng the consistency of the original version. Inheritance Change by ModificaHon Change by AddiHon
- 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 complicaHon
- 76. The OCP principle and associated techniques are intended for the adapta=on 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 redefiniHon in inheritance is a way to address design flaws, let alone bugs Design Flaw
- 78. its purpose, its enHre reason for being, is to reduce the cost of change.
- 79. Ques=on: how do we promote flexibility, reliability and stability in our soZware? Analysability Maintainability Changeability Stability Testability Flexibility Reliability
- 80. Answer: we favour ‘Change by Addi=on’ over ‘Change by Modifica=on’ Changeability Stability Flexibility Reliability Change by ModificaHon Change by AddiHon -‐ + -‐ +
- 81. How do we achieve ? Change by AddiHon which uses OO inheritance Inheritance We apply the Open-‐Closed Principle
- 82. extends is evil!!!!! Yes, we’ll cover that in the next presentaHon: Part II But, using inheritance is no longer the main approach to saHsfying the OCP Allen Holub 2004 2003
- 83. in which we look at the modern, contemporary version of the OCP again, we’ll cover this in the next presentaHon: Part II Using inheritance is sHll one of the ways of saHsfying the OCP, and was considered THE approach for a long while Why extends is evil 1988 -‐ 1st ed. 1997 – 2nd ed. 1995 That started changing with the emergence of the design techniques presented in Design Pa2erns 2003
- 85. References All images sourced from h>p://www.google.co.uk/advanced_image_search, so see there for details of which are subject to copyright Object-‐Oriented So9ware Construc=on – by Bertrand Meyer; PublicaHon Date: 3 April 1997 | ISBN-‐10: 0136291554 | ISBN-‐13: 978-‐0136291558 | EdiHon: 2 Flexible, Reliable So9ware: Using Pa2erns and Agile Development – by Henrik B. Christensen; PublicaHon Date: 11 May 2010 | ISBN-‐10: 1420093622 | ISBN-‐13: 978-‐1420093629 Design Pa2erns Explained: A New Perspec=ve on Object-‐Oriented Design; by Alan Shalloway; PublicaHon Date: 12 Oct 2004 | ISBN-‐10: 0321247140 | ISBN-‐13: 978-‐0321247148 | EdiHon: 2 Less -‐ The Path to Be2er Design; by Sandi Metz at GoRuCo 2011 goruco_2011_-‐_sandi_metz_-‐_less_-‐_the_path_to_be>er_design_1280x720.mp4 Why Extends is Evil -‐ Improve your code by replacing concrete base classes with interfaces; by Allen Holub; h>p://www.javaworld.com/arHcle/2073649/core-‐java/why-‐extends-‐is-‐evil.html