3 ms·

> ...you don't risk breaking any existing functionality but > then why not just use a test suite? The examples fail to make explicit that there are two prog

by jt2190 12y ago

> ...you don't risk breaking any existing functionality but > then why not just use a test suite? The examples fail to make explicit that there are two programmers: One is building and distributing a library, the second is building an application using that library. The library programmer can easily distribute the test suite so that the application programmer can run the tests, but that doesn't change the fact that if the library programmer changes an object's interface, it breaks the application programmer's code. By committing to keep the old object's interface intact, the library programmer is giving the application programmer time to migrate their code to the new objects.

platz 12y ago
I like your library/application distinction. For applications I'm not sure open/closed makes as much sense - http://codeofrob.com/entries/my-relationship-with-solid---the-big-o.html http://codeofrob.com/entries/my-relationship-with-solid---th...
- ollysb 12y ago
  I think the distinction is a straw man really. Changing the semantics of interfaces is generally a bad idea once you have code depending on them whether it be within your application or a library. Where open/closed falls down is that it requires that you subclass just for _adding_ new methods to an interface. You're not effecting any existing code but you're still introducing entropy into your codebase.
- jt2190 12y ago
  > For applications I'm not sure open/closed makes as > much sense. I agree with you. If the same programmer (or team) is maintaining "both sides" of an object's interface, i.e. both implementing the behavior of the object AND consuming the object in their application code, I think we can assume that they'll know that if they change one side they'll need to immediately change the other. I'm not sure I agree with Rob Ashton's points, though. In his blog post, Rob trivializes the utility of third-party libraries: > * These [libraries] are either replicable in a few > hours work, or easily extended via a pull request. This is simply not the case with any truly useful library. Useful libraries often represent years of careful design work and debugging. (Think networking libraries, UI frameworks, etc.) He also underestimates the amount of time it takes to continuously change application code to keep up with breaking changes from third-party libraries: > * These [libraries] can be forked for your > project and changes merged from upstream with > little effort. Again, if the library distributes a breaking change, it may require many, many hours of code changes and re-testing to make sure everything's still working properly. Hours that could be spent building new features. For that kind of tradeoff there'd better be a damn good reason for the change: Improved security or performance or ease of use.

by jt2190 12y ago

platz 12y ago

I like your library/application distinction. For applications I'm not sure open/closed makes as much sense - http://codeofrob.com/entries/my-relationship-with-solid---the-big-o.html http://codeofrob.com/entries/my-relationship-with-solid---th...

ollysb 12y ago
I think the distinction is a straw man really. Changing the semantics of interfaces is generally a bad idea once you have code depending on them whether it be within your application or a library. Where open/closed falls down is that it requires that you subclass just for _adding_ new methods to an interface. You're not effecting any existing code but you're still introducing entropy into your codebase.
jt2190 12y ago
> For applications I'm not sure open/closed makes as > much sense. I agree with you. If the same programmer (or team) is maintaining "both sides" of an object's interface, i.e. both implementing the behavior of the object AND consuming the object in their application code, I think we can assume that they'll know that if they change one side they'll need to immediately change the other. I'm not sure I agree with Rob Ashton's points, though. In his blog post, Rob trivializes the utility of third-party libraries: > * These [libraries] are either replicable in a few > hours work, or easily extended via a pull request. This is simply not the case with any truly useful library. Useful libraries often represent years of careful design work and debugging. (Think networking libraries, UI frameworks, etc.) He also underestimates the amount of time it takes to continuously change application code to keep up with breaking changes from third-party libraries: > * These [libraries] can be forked for your > project and changes merged from upstream with > little effort. Again, if the library distributes a breaking change, it may require many, many hours of code changes and re-testing to make sure everything's still working properly. Hours that could be spent building new features. For that kind of tradeoff there'd better be a damn good reason for the change: Improved security or performance or ease of use.