How to loosen input contracts by inheritance?

Question

According to LSP wiki:

Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.).

...

These are detailed in a terminology resembling that of design by contract methodology, leading to some restrictions on how contracts can interact with inheritance:

• Preconditions cannot be strengthened in a subtype.
• Postconditions cannot be weakened in a subtype.
• Invariants of the supertype must be preserved in a subtype.

and this text about contracts:

If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

A function without an in contract means that any values of the function parameters are allowed. This implies that if any function in an inheritance hierarchy has no in contract, then in contracts on functions overriding it have no useful effect.

Conversely, all of the out contracts need to be satisfied, so overriding functions becomes a processes of tightening the out contracts.

you can loosen preconditions in a subtype, but the instances of the ancestor must be substitutable with the instances of the subtype.

I was wondering how is it possible to loosen preconditions while keeping the same behavior? For example if I write a unit test for argument validation by a method, then loosening the preconditions mean that the unit test will fail by the instances of the subclass. So by loosening a precondition I can violate LSP.

class T {
    aMethod(x){
        assert(x !== "invalid");
        const y = this.doSomething(x);
        const z = this.doAnotherThing(y);
        return z;
    },
    doSomething(x){
        // ...
        return y;
    },
    doAnotherThing(y){
        // ...
        return z;
    }
}

class S extends T {
    aMethod(x){
        // loosening preconditions by removing the assertion
        const y = this.doSomething(x);
        const z = this.doAnotherThing(y);
        return z;
    }
}

.

class TestCase {
    testInputValidation(C){
        expect(function (){
            const o = new C();
            o.aMethod("invalid");
        }).toThrow();
    }
}

var tc = new TestCase();
tc.testInputValidation(T); // passes
tc.testInputValidation(S); // fails because I loosened the contract

Maybe I don't understand LSP and contracts, I don't know. Can you write a (preferably not dummy) example which fulfills both substitution and precondition loosening?

Conclusion:

I think most of the LSP descriptions missing the point. The real question is why we need LSP by inheritance? Violating LSP will lead to unexpected errors, because we won't be able to use instances of subclasses where we used instances of the base class. The subclass instances pass the type check, so we will have errors related to their behavior, which is relatively hard to debug. So LSP acts as a preventive measure.

The example was not the best, I mean it did not make much sense, because only the in-contract was removed/loosened. To make this work I should have written something like this:

class S extends T {
    aMethod(x){
        // loosening preconditions by removing the assertion
        const y = this.doSomething(x);
        const z = this.doAnotherThing(y);
        return z;
    },
    doSomething(x){
        if (x == "invalid")
            x = transformToValid(x);
        return super.doSomething(x);
    }
}

To answer the question from my point of view. I was testing for the in-contract of the base class and that contract was loosened in the subclass, so it is natural that the test failed for the subclass. We should not test the subclasses for the same contracts as we test the base class for, if we test for contracts at all. On the other hand we must test the subclasses for inputs that pass the base class in-contract and the outputs for these inputs must pass the out-contract of the base class. By applying LSP the latter is assured, because we can only strengthen the out-contract in subclasses. So it is possible to reuse certain tests by subclasses. We need to write new tests only for the loosened part of the in-contract, which is not part of the out-contract of the base class. To my understanding the assert(x !== "invalid"); is an in-contract in the base class. Using contracts can help by any code modification, because you can read the valid inputs from these contracts, and if you strengthen a precondition, then you will know, that you have to check every usage of the actual method, because the changes can break them. If you loosen a precondtion, then you will know, that these changes should not break existing code except if you have subclasses overriding the actual method. So it is better to make these contracts explicit in the code. Thank you for all your answers! I gave the points to NickL, because he helped the most to understand the relevance of LSP and contracts.

Answer 1

By removing the assert you actually changed the postcondition. As you can see in your test, you check whether the postcondition .toThrow() holds. What the function says: precondition: given an input of "invalid", postcondition: throws assertionerror.

You could weaken the precondition by always throwing an assertion error. What you are doing now is weakening the postcondition.

The reason why you can consider the assertion error as a postcondition is this case is because you expect it to be the output. When you test a function, you use data that satisfies the precondition, call the function and verify whether the postcondition holds for the result. You can weaken the precondition, but should still ensure that the postcondition holds (it is allowed to be stronger)

Here an example written as a Hoare triple

{ x >= 2 } x := x + 1 { x > 2}

The contract for this function could be given an input greater than or equal to 2, the result will be greater than 2

now with weaker precondition:

{ x >= 1 } x := x + 2 { x > 2}

Or, I could interpret this change as a stronger postcondition (which is also allowed):

{ x >= 2 } x := x + 2 { x > 3}

In both cases, the contract of the original function still holds. The whole point of LSP is that no matter what type you replace it with, you at least get the behavior of what the contract states. My change to the body of the function could be interpreted as either weakening of the precondition or strengthening the postcondition.

Don't confuse this with the behavior of the function. Yes, the behavior will be changed, and so has the output in this particular example. The first function would return f(2) = 3, and the second function would return f(2) = 4. However, remember that we defined the contract as the result will be greater than 2., we did not define the exact output.

When we talk about the strengthening of types, we mean that a more specific type is stronger than a more abstract type. Object is weaker than Number, Double is stronger than Number.

Preconditions are assumptions you are allowed to make. The assumption >=1 contains more elements than AND contains the elements of >=2, thus it is weaker. The 'error' raised by assert only tests the assumption, since the function only provides valid output based on the assumption.

Answer 2

What those texts about LSP and contracts effectively say is:

For all valid inputs to aMethod, the implementation in S must behave the same as the implementation in T. When calling o.aMethod(x), the caller should not have to care if o is an object of type T or type S.

Note that I am only talking about * valid* inputs to aMethod. If "invalid" is considered a valid input to T::aMethod (with the defined result of throwing an exception), then the base class method has the weakest possible contract and there is no weakening that the derived class can do.
If "invalid" is not considered to be valid input (and the assert only exists as a sanity check that the caller does obey the preconditions), then the derived class is allowed to define sensible behavior for "invalid". This is what is meant by weakening the precondition, because a larger set of values is acceptable to the function.

This means that negative tests against the preconditions of the base class (i.e. tests that verify that values that don't meet the preconditions aren't accepted) are not required to show the same result when executed against a derived class.

Answer 3

You seem to be confused about the exact meaning of precondition. A precondition is an abstract concept used in formal reasoning about code. It is not an assert() call. Indeed is does not have to appear in the code at all.

The precondition specifies the set of circumstances in which there is a defined meaning for an object. If the precondition does not hold the formal meaning is undefined. The LSP definition starts with Let phi(x) be a property provable about objects x of type T. This implicitly excludes any circumstances that violate the precondition of T, because nothing can be proved starting with undefined.

Usually it is not at all clear what a reasonable precondition for a given piece of code is. The author likely has some more or less fuzzy idea about the circumstances in which the code should have a defined meaning. But most of the time this idea is not explicit in the code (just as in your example). assert() might be used to express the precondition, but it just as well might specify behavior for that input (though I would consider that bad style). Without an explicit language element for preconditions as in Eiffel or an explicit definition of the precondition in the documentation there is always uncertainty and some room for argument.

Your example code is confused about whether there is any precondition at all. If the assert(x !== "invalid") is meant as precondition then any test for that behavior is meaningless / undefined / forbidden. If the assert is not as meant as precondition then the precondition is true for all inputs. Which already is the weakest possible precondition.