> 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 obje

> 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.