5

The open/closed principle seems to be about preventing regressions in an object or method. Given that your code is covered by tests because you're practicing BDD this seems a redundant requirement. In addition it seems to introduce additional complexity by requiring extensibility at the API level rather than the language level.

opsb
  • 29,325
  • 19
  • 89
  • 99
  • 1
    There are a bunch of agile techniques which don't apply to APIs that you've published outside your own organisation, because it's simply impossible to update all the code that depends on the interface you're changing. open/closed is more suitable to that kind of thing, I think, or in general to interfaces (if any) that you design for permanence. – Steve Jessop Jan 24 '11 at 16:01

1 Answers1

6

Absolutely there are benefits. In fact, the two principals (BDD and Open/Closed) are designed for different purposes. BDD is designed to lead the development process, and that's where its benefits are felt (shortening timelines, making higher quality code, etc). Open/Closed is designed to be done in the development process, but help in maintenance.

The benefits of BDD are easy to grasp. Shorter timelines for initial development mean less cost for the project as a whole, right? Wrong. Based upon The 60/60 Rule, 60% of the cost of the project is from maintaining it (and 60% of that cost is from requirements changes post-deployment). So while it's beneficial to save money during the initial development phase, the bigger savings is to be had during maintenance.

And that's where the Open/Closed principal will pay off. By following that principal, you will save yourself a lot of time in maintenance (since you don't need to track down broken Unit Tests because you change the functionality of a method).

And the Open/Closed principal isn't about preventing regressions so much as it is preventing a changing API which is almost impossible to keep up with. If you notice, good APIs never change. They may be extended. Parts may be deprecated. But you never see setFoo(string bar) change to setFoo(int bar). That's what Open/Closed is there to prevent...

ircmaxell
  • 163,128
  • 34
  • 264
  • 314
  • I understand why you wouldn't want your api to change. Where I'm not so sure is when you want to add to the api of a class. I'm not sure if I've groked open/closed correctly but it seems to suggest that you shouldn't change a class at all once it's closed. If this is the case then it feels like it conflicts with other principles like don't optimize early and emergent design through refactoring. Perhaps I'm wrong though and it only refers to closing individual methods? – opsb Jan 24 '11 at 23:43
  • @opsb: I think you've grokked it correctly. Applied to classes, the open/closed principle says, "you know how you can add new methods to a class, and it's still completely backward-compatible with all existing code? Well, don't do it. Instead, create a new class with all the functionality of the old class, plus more. This new class can be a subclass of the old class if it helps". You can also try to anticipate the need for change through dependency injection, strategy pattern, and any other such tricks you can think of that make your classes more flexible without needing to change them. – Steve Jessop Jan 24 '11 at 23:46
  • It's the subclassing to add new functionality that makes me uncomfortable. Given that your api hasn't changed and you're only adding functionality I can't see the benefit to fragmenting what should be a single class across 2 classes i.e. given that you have ensured no regressions in your existing api, what justification is there for using a design which at any other point in the process would be considered inferior. – opsb Jan 24 '11 at 23:51
  • I suppose the recurring concern I have with the whole principle is that it seems like a case of YAGNI. It requires up front design to allow extensibility in the right places. For me this is in direct conflict with BDD. – opsb Jan 24 '11 at 23:54