Mark Needham

Two controllers, type conformance and the Liskov Substitution Principle

with 6 comments

public class GenericController extends Controller {
	private final SomeFactory someFactory;
 
	public GenericController(SomeFactory someFactory);
        this.someFactory = someFactory;
	}
 
    public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
        // do some stuff but never use 'request' or 'response'
    }
}

public class MoreSpecificController extends GenericController {
	private final SomeFactory someFactory;
 
	public MoreSpecificController(SomeFactory someFactory);
        super(someFactory);
	}
 
    public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
    		...    
		// do some stuff which does use 'request'
		String someValue = request.getParameter("someParameter");
    }
}

@Test
public void someTest() {
	GenericController genericController = new GenericController();
 
	genericController.handleRequest(null, null);
 
	// and so on
}

@Test
public void someTest() {
	MoreSpecificController moreSpecificController = new MoreSpecificController();
 
	moreSpecificController.handleRequest(mock(HttpServletRequest.class), mock(HttpServletResponse.class));
 
	// and so on
}

6 Responses to 'Two controllers, type conformance and the Liskov Substitution Principle'

Subscribe to comments with RSS or TrackBack to 'Two controllers, type conformance and the Liskov Substitution Principle'.

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

   

   MauricioC

   19 Nov 09 at 1:25 am
2. 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.

   

   MauricioC

   19 Nov 09 at 1:28 am
3. 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?

   

   Mark Needham

   19 Nov 09 at 1:33 am
4. 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.

   

   Zubair Khan

   20 Nov 09 at 1:21 am
5. 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.

   

   Mark Needham

   20 Nov 09 at 3:23 am
6. 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.

   

   domenico

   29 Nov 09 at 11:15 pm

Leave a Reply