Skip to main content
Software Engineering

Timeline for Following Open Closed Principle

Current License: CC BY-SA 3.0

27 events
when toggle format what by license comment
Dec 26, 2017 at 16:57 history edited JacquesB CC BY-SA 3.0
deleted 110 characters in body
Dec 25, 2017 at 7:39 history edited Doc Brown CC BY-SA 3.0
Made a suggested improvement.
Dec 25, 2017 at 7:35 comment added Doc Brown @JacquesB: suggestion, I will edit your answer slightly to correct this error, and if you don't like the edit, you can revert it.
Dec 24, 2017 at 11:15 comment added Doc Brown @JacquesB: yes, it is about the purpose, and not about the defintion. That is exactly my point. The purpose of OCP is that code changes become unnecessary, but the OCP itself, its defintion, refers to the design process . In your answer, however, you still write "applying the OCP" synomously to "not changing code of a big-ball-of-mud system". And that is IMHO wrong.
Dec 24, 2017 at 10:35 comment added JacquesB @DocBrown: I don't see how discussion about designing components according to OCP can be separated from discussion how to use such components (extending vs modifying). I certainly don't see the value of deliberately ignoring one side of the coin. Understanding the purpose of the OCP helps one understand when it is appropriate to apply. The Martin quote is about the purpose of the OCP, not a definition of the OCP.
Dec 24, 2017 at 9:48 comment added Doc Brown @JacquesB: but you are not alone, that fundamental misunderstanding was already discussed in this former SE.SE question, for example.
Dec 24, 2017 at 8:27 comment added Doc Brown ,,, and if you look at the whole paper, without taking single sentences out of their context, this is all about how to design components, not more. Or if you look at the other SOLID principles - they are all design principles. Those sources don't tell you how to use, reuse or abuse components, they only tell you how to design components. But to be fair, the words Uncle Bob used there in his "you are not allowed" style are open for misinterpretation (but not closed for thinking twice about their meaning) ;-)
Dec 24, 2017 at 8:20 comment added Doc Brown @JacquesB: well, may understanding of this cite is you should design modules [..], so - you don't need to - extend the behavior of such modules [...]. So Uncle Bob is perfectly in sync with what I wrote above - the OCP is a design principle, not a reuse principle for components which are misdesigned.
Dec 23, 2017 at 23:20 comment added JacquesB @DocBrown: I don't know if there is an "official" definition of OCP, but Robert Martin states "The openclosed principle (..) says that you should design modules that never change. When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works." (www2.cs.duke.edu/courses/fall07/cps108/papers/ocp.pdf) Of course you may disagree with this interpretation of the OCP, but it is not just me that has misunderstood the principle then.
Dec 22, 2017 at 9:14 comment added Doc Brown @JacquesB: that is fine, but still I recommend to rewrite (or delete) your paragraph about the "big-ball-of-mud" architecture from your answer. You are pretending there that keeping legacy code unchanged is a form of applying the OCP, that is IMHO wrong. If you would write instead that some people mistakenly think that has this something to do with the OCP, then your answer would IMHO become better.
Dec 22, 2017 at 8:28 comment added JacquesB @DocBrown: I recommend designing components as "open for extension" if you are writing a component/library for use by third parties. Otherwise follow the YAGNI principle.
Dec 22, 2017 at 7:47 comment added Doc Brown @JacquesB: as I wrote in my answer I linked to, I agree mostly what you wrote about OCP for 3rd party libs. However, I think your usage of the term "OCP" as a synonym for treating components as unmodifiable (as opposed to designing them ) is 100% wrong. So what are you recommending here in your first sentence? Not trying to design components in that way, or not trying to reuse components without modifying them? Your partly correct, partly wrong usage of the term OCP makes your answer look very strange to me.
Dec 22, 2017 at 7:35 comment added JacquesB @DocBrown: Good point, I could have been more clear. My point is that the OCP make the most sense when the designer of the component and the client are independent. This is the case with a 3rd party library or service API, but not when the component and client code is in the same project, in which case OCP is not necessary. But if you have a big-ball-of-mud architecture, it might still make sense to treat components as closed, out of fear of breaking anything if the component is changed.
Dec 21, 2017 at 20:39 comment added Doc Brown ... so maybe your initial recommendation for not following the OCP is caused by the the same misunderstanding? Maybe you wanted to recommend to apply changes to existing code, and not to avoid following the OCP?
Dec 21, 2017 at 20:37 comment added Doc Brown @JacquesB: your answer has some good points in it, but when you wrote the part about "big-ball-of-mud" systems, you were intermixing "following the OCP" (which is something the author of a component does to prevent the necessity for code change)s with "not changing existing code" (which is something a user of a component decides about, but has IMHO nothing to do with the OCP). The OCP is a design principles for designing reusable components, not a principle for reusing code in a "don't change" manner (and so producing technical debt).
Dec 21, 2017 at 18:30 comment added Giorgio @AndresF.: Good point.
Dec 21, 2017 at 15:45 comment added Andres F. @JacquesB the problem is people applying [principles] uncritically: when enough people misapply a principle, the fault lies with the principle (or at least, with how it's explained). The same happens with statements such as "methodology X would work, if only": when the "if onlys" become boundless, it's a sign the methodology doesn't work outside laboratory conditions ;)
Dec 21, 2017 at 14:49 history edited candied_orange CC BY-SA 3.0
edited body
Dec 21, 2017 at 11:31 comment added JacquesB @Georgio: Good point. I have added a paragraph than OCP might also be appropriate if you have a legacy "big-ball-of-mud"-architecture.
Dec 21, 2017 at 11:30 history edited JacquesB CC BY-SA 3.0
added 409 characters in body
Dec 21, 2017 at 9:28 comment added JacquesB @user949300: I don't think OCP is generally meaningless, it is just that you need to understand the contexts where it is useful. The problem is not the principles themselves, the problem is people applying them uncritically.
Dec 21, 2017 at 8:46 comment added Giorgio "It is often cleaner and simpler to modify behavior rather than extend it.": I disagree with this. If you modify the behaviour of a module that is used internally by many other modules, you can have unexpected side effect and changes of behaviour everywhere in your software. I have seen so many bugs appear because of this. If possible, you should try to stabilize your code over time, especially those modules on which many other modules depend.
Dec 21, 2017 at 8:37 comment added user949300 I agree with this answer. And it makes me wonder why SOLID is so highly rated, when it's #2 principal, OCP, is generally meaningless, it's #3 principal, LSP, seems to mainly affect mutable rectangles and squares, and it's #1 principal, SRP, is frequently misunderstood and misapplied.
Dec 21, 2017 at 8:30 vote accept Bhalchandra K
Dec 21, 2017 at 7:54 history edited JacquesB CC BY-SA 3.0
added 9 characters in body
Dec 21, 2017 at 7:45 history edited JacquesB CC BY-SA 3.0
added 184 characters in body
Dec 21, 2017 at 7:36 history answered JacquesB CC BY-SA 3.0
toggle format