Comments on: Two controllers, type conformance and the Liskov Substitution Principle

By: domenico

domenico — Sun, 29 Nov 2009 13:15:26 +0000

I think that if we agree on that arguments values are part of a precondition the situation is more clear:

1. “Preconditions can be modified in redefined routines, but they may only be weakened[2]. That is, the redefined routine may lessen the obligation of the client, but not increase it.”

http://en.wikipedia.org/wiki/Precondition

2. “* Preconditions cannot be strengthened in a subtype.
* Postconditions cannot be weakened in a subtype.
* Invariants of the supertype must be preserved in a subtype.
* History constraint (the “history rule”)… ”

http://en.wikipedia.org/wiki/Behavioral_subtyping

So I agree with Zubair Khan and, personally, i would change the base class contract to throw an exception in presence of null arguments.

By: Mark Needham

Mark Needham — Thu, 19 Nov 2009 17:23:49 +0000

Yeh that’s interesting. In reality neither of those is likely to be null but it seemed like something interesting!

If I understand what you’re saying correctly then we should make MoreSpecificController handle the null situation without throwing a Null Pointer Exception? Makes sense.

By: Zubair Khan

Zubair Khan — Thu, 19 Nov 2009 15:21:59 +0000

I think we’re looking too closely at what the arguments are as opposed to what they can be(?)

null’s make this problem more obvious in that they’re not actually instances of the argument as the method has specified.

Saying that a sub class should be able to replace a super class wherever the super class is used doesn’t mean it is to behave the same (clearly).

So the fact the specific class snaps when given a null isn’t a violation of LSP. It’s just the fact that null’s are evil and a change in behaviour.

Having discussed the above with Pete (Gillard-Moss) he’s schooled me some. He states two things I didn’t consider.

1. In a contract based language the acceptable values are part of the contract, which means the subclass indeed breaks the initial contract.

2. Throwing an exception is beyond a change in behaviour, it too is a break in the contract given (1).

That to me suggests that either the super class should check for nulls and throw an exception, or the subclass should check for nulls and handle that scenario gracefully.

By: Mark Needham

Mark Needham — Wed, 18 Nov 2009 15:33:29 +0000

Couple of questions:

If we had explicit pre and post conditions then would it be true that sub classes should adhere to those laid out in their super class?

What would you say is the definition of a provable property? I think you’re saying that it’s just a coincidence that request and response aren’t being used in the super class, and that’s why it wouldn’t be a violate. Is that right?

By: MauricioC

MauricioC — Wed, 18 Nov 2009 15:28:49 +0000

Or, in other words: Every code can be held to much stronger assumptions than what’s explicitly stated as a pre-condition or post-condition, but that doesn’t mean derived classes have to adhere to those implicit assumptions. That’s why making pre-conditions and post-conditions explicit is a good idea.

By: MauricioC

MauricioC — Wed, 18 Nov 2009 15:25:27 +0000

Not really. Quoting Wikipedia’s more precise version of the Liskov Substitution Principle:

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.

The word “provable” is important: It means that implementation details for the Base class, such as the fact that GenericController doesn’t use request and response, need not be true for the Derived class as well. Unless not using request and response is by Design, at which point you obviously have a LSP violation.