4 ms·

I have to confess, I have never been able to figure out what the Open Closed principle means. I've never seen an explanation that made sense. Extension vs modif

• namelosw 7y ago
  About the Extension: Think about the concept of '+', you can '+' integers, rational numbers, matrix, etc. There possibly thousands of kinds of things that could be '+'-ed. (Actually, this concept is called monoid) Your job is to implement the abstract idea of '+' (the operator itself without specific meaning) and the integer implementation for '+'. Then you can compile publish your package to a jar, dll or any other form of package other people can download. Everyone, possibly thousands of people can download this package and extend and use the exact same '+' from you, for their own datatype without modifying your code or recompiling your package. At last, 99 out of 100 this could be over-engineering for most of the languages like Java. But for language like Haskell have a feature named type classes, make this almost no-brainer, so it would become 5 out 10 this could be over-engineering in Haskell because the cost and mental overhead are reduced.
• charlieflowers 7y ago
  Essentially, it means that you can extend something by writing _new_ code, in a _new_ file, rather than modifying some code. For example, a case statement cannot be modified without adding a new case. But something that finds all objects which implement IFoo and uses them can be modified by implementing a new implementer of IFoo. (That's not the only and probably not the best example, but it is an example). A lot of people don't realize that most (maybe all) of these principles originated on C++ code bases way back, where changing one file in one tiny way could cause massive number of files to need recompiling -- which at the time was very painful due to slow compilers. They have some good applicability, but I think they're massively over-sold.
  • zmmmmm 7y ago
    Thanks. That makes "open for extension" clear, but it still leaves me wondering about "closed for modification". It is certainly a nice aspiration that code doesn't need to be modified to customize it if one can achieve that. But failing that, code should be as modifiable as we can possibly make it. Making it "closed for modification" sounds like a bad thing, like it will be very hard to maintain.
    • mdpopescu 7y ago
      Changing an existing class (modification) is possibly bad, because it can introduce bugs. The code was working, you made a change, oops! Adding a new class (when the code was written to be extensible) should prevent that. See for example [1] where Sandi Metz shows how to rewrite some incredibly complex code to make that possible. [1] https://www.youtube.com/watch?v=8bZh5LMaSmE https://www.youtube.com/watch?v=8bZh5LMaSmE
    • dsego 7y ago
      This is my interpretation. Usually bad devs I've worked with will mistakenly keep things DRY by reusing code in a bad way, for example modifying existing classes to handle cases they were not meant to handle. The most primitive example is reusing a function because it does 80% of some logic and then adding some bool flags to make it do something a bit different. Instead one should always abstract things and extract reusable bits, but only if it makes sense. But more often than not, lazy or misguided devs will see a similar piece of code and try to reuse it by modifying it to add new behavior, because "copy/pasting is bad".