2 ms·

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-

by 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 platz 12y ago

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.