Open Inheritance

Martin Fowler writes about "Designe Inheritance". Designed Inheritance means that you (as a class developer) design upfront which parts of your class can be overridden and extended by subclass and which methods/structures cannot (are sealed for extension).

Martin says he favors open inheritance (i.e. not restricting overrides etc.). I think going for open inheritance is something you should do if you either know exactly who your users (developers that inherit your class) and you know that they are good enough, or you don't care who your users will be.

The problem is that someone who inherits your class can very easily commit Liskov Substitution Principle violations and cause problems with other parts of your application/framework/library that rely on the inherited class.

If you want to go with open inheritance and mitigate the LSP violation risk, I suggest sending the class a long with a suite of tests that verify the invariants on the classes interface.

There are, in fact, tools like RSPEC, JBehave, or nBehave which allow you to specify how a class should behave. These tools are based on a notion called BDD or Behavior Driven Design. BDD is wider in scope that what is needed here -- which is only making sure the post conditions, preconditions, and invariants are kept and not necessarily defining all the behavior of the class (which can also be beneficial ).

By the way, Dan North (who invented BDD) defined the difference between the xSpec and xBehave efforts as follows:

• xspec uses the vocabulary of "specification" where xBehave talks about "behaviours".
• xspec is exclusively looking at BDD-as-evolution-of-TDD, whereas xBehave is also about automating stories and scenarios.
• xspec extends the language to add DSL-type verification, so it is well-suited to dynamic languages (Ruby and Smalltalk are the current target platforms). xBehave uses Joe Walnes's constraints-based approach.

To sum up this post. The good thing about designed inheritance is that it saves class users the effort of learning all the details and risks involved in overriding the behavior of the class they are extending. If you opt for open inheritance, it is recommended to back that up with code (tests) that will help those inheriting the class from falling into traps and LSP violations that will result in odd bugs when they'll actually try to use their inherited class.

Posted by Arnon Rotem-Gal-Oz at 05:02 AM  Permalink