Question

When reviewing our codebase, I found an inheritance structure that resembles the following pattern:

interface IBase {     void Method1();     void Method2(); }  interface IInterface2 : IBase {     void Method3(); }  class Class1 : IInterface2 {     ... }  class Class2 : IInterface2 {     ... }  class Class3 : IInterface2 {      ... } 

In Class2, Method1 throws NotImplementedException.

Questions:

• What do you think in general about inheriting interfaces?
• Does the relationship between IBase and Class2 violate the Liskov Substitution Principle?

Answer 1

Well, first of all, I’m generally against implementing an interface by throwing NotImplementedException exceptions. It is basically like saying ‘Well, this class can also function as a calculator, err, almost’.

But in some cases it really is the only way to do something ‘the right way’, so I’m not 100% against it.

Just something to be aware of.

An interface is a contract, by implementing the interface you say that you abide by the contract. If you then start negating parts of the contract, it sounds to me as the contract, or the implementation of it, was poorly thought out.

---

Edit: After seing Greg Beech‘s answer: If an interface specifically says that implementations should throw these exceptions, then it’s part of the contract, then I agree that the class is fully allowed to do it.

---

As for the substitution principle, it states that:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

In this context, it violates the principle just as much as overriding a method from a base class does, if you change what the method does in the descendant type.

The principle is more detailed on the wikipedia page, like the following points (parenthesis and emphasis on my comments):

• Preconditions cannot be strengthened in a subclass. (A precondition could be that ‘the class is ready for a call to this method at this point’)
• Postconditions cannot be weakened in a subclass. (A postcondition could be that after calling the method, something is true about the state of the class)

Since you have not shown the full contract of your interfaces, only the declarative part that the compiler can check, it is impossible to know wether the principle holds for your implementation of not.

For instance, if your Method2 has the following conditions attached to it:

• Can be called at all times
• Modifies the state of the object to be ready for the next event in a chain of events

Then throwing a NotImplementedException violates the principles.

However, if the contract also states that:

• For classes that doesn’t support chains of events, this method should throw NotImplementedException or NotSupportedException

Then it probably does not.