Well, firstly, I'm generally against the implementation of the interface, throwing NotImplementedException exceptions. This is basically how to say: "Well, this class can also function as a calculator, mistakenly, almost."
But in some cases, this is really 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 that implements an interface that, as you say, abides by the contract. If you then begin to deny part of the contract, it sounds to me like a contract, or its implementation, was poorly thought out.
Edit : after choosing Greg Beech : if the interface specifically says that implementations should throw these exceptions, then this is part of the contract, then I agree that the class is fully allowed for this.
Regarding the principle of substitution, indicates that:
Let q (x) be a property provable with respect to objects x of type T. Then q (y) must be true for objects y of type S, where S is a subtype of T.
In this context, it violates the principle in the same way as overriding a method from a base class if you change what the method does in the descendant type.
The principle is described in more detail on the wikipedia page, as well as the following points (brackets and emphasis on my comments):
- Preconditions cannot be strengthened in a subclass. (A precondition may be that "the class is ready to call this method at this point")
- Postconditions cannot be relaxed in a subclass. (A postcondition may be that after calling the method, something is true about the state of the class)
Since you did not specify the full contract of your interfaces, only the declarative part that the compiler can verify is impossible to know that the principle is implemented for your implementation.
For example, if your Method2 has the following conditions associated with it:
- May be called at any time.
- Changes the state of an object that will be ready for the next event in the event chain
Then throwing a NotImplementedException violates the principles.
However, if the contract also states that:
- For classes that do not support event chaining, this method should raise NotImplementedException or NotSupportedException
Then, probably, this is not so.