Are there any benefits to following the open/closed principle when using BDD?

Question

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.

Answer 1

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