省略super（）和/或*弱化*先决条件是否违反Liskov替换原则？

Question

I've been digging into some of the SOLID design principles lately, and some information I got from one source originally made sense to me, but based on the strict definitions I've been able to find for thr LSP, it seems like that info might not be correct. The info was specifically that:

1) Not calling back into super() on an overridden method violates LSP (or at least opens you up to violation) because the base class's behavior may change at some point, and your subclass could be missing that behavior in a way that causes the subclass to no longer be substitutable for the parent. That seems to make sense to me, but it would be great if someone could elaborate on that/give some info on when it would ever be appropriate to not call back into super.

2) Subclasses should not be less restrictive than the parent. The example was: if you have a parent class that takes only positive integers, then you make a subclass that accepts both positive and negative ints. So the child should work fine in place of the parent, but the child can't delegate back to super in this case.

I thought that made sense, but the info on LSP seems to say the opposite: a precondition can't be strengthened by the child. Both seem to make sense to me, but Liskov only states that the precondition can't be strengthened and the postcondition can't be weakened. Can someone help enlighten me on this?

Answer 1

1) Case, when it would ever be appropriate to not call back into super

Usually (but not always) such case means something is wrong with the class hierarchy design.

Not calling the super class implementation doesn't violate the LSP if the child method accepts correct input types and returns correct output type. It only indicates the possibility of the problem.

Here is an absolutely valid example when you don't call the super method:

class Animal

   void eat(Food food)
       // Eat the food

class Cat extends Animal

   void meow()
       // Say meow


class AnimalOwner

   Animal findAPet() 
       return new Animal()

class CatOwner

   // we can return the subclass of Animal here
   Cat findAPet() 
       return new Cat() // We don't need to use the parent implementation

Here the CatOwner::findAPet() returns a Cat (an Animal subclass), this is valid in terms of LSP and we don't call the parent implementation.

Take into account that calling the parent implementation does not guarantee that you can not fall into the same problem as when you don't call it.

Consider this example:

 class Child

    Output doSomething()
        parent = super::doSomething()
        if parent->isNotGood():
           return new OutputSubclass()  // We called super, but we return 
                                        // something different, might be not safe
        else:
           return parent                // We called super and return 
                                        // the same value, safe

2) "Preconditions cannot be strengthened in a subtype". This also means that pre-conditions (expectations related to input parameters) can stay the same or be weakened. In the example you mention, the pre-conditions are actually weakened, so there is no conflict:

Parent::doSomething(PositiveInteger value)  // Only positive integers

Child::doSomething(Integer value)           // Positive or negative integers, 
                                            // pre-condition is weaker 
                                            // (covers wider area of values)

What is not exactly correct is the first sentence: "Subclasses should not be less restrictive than the parent". Subclasses can be less restrictive when we talk about pre-conditions (input parameters) and this is what shown in the example.

Answer 2

The Liskov substitution principle requires that you can use a subtype when the base type is expected. To do this you must adhere to the contract of the base type. For a base-class B with a method f, precondition Pre, postcondition Post and invariant I, this means that

• The caller code only guarantees that Pre holds when potentially using your object. If Pre holds, your precondition must also hold. Logically Pre implies the pre-condition of your derived method. This means that you can widen the pre-condition because Pre -> (Pre and condition), as long as there is no contradiction
• The caller code expects that Post holds when the method is finished. This means that you can add more guarantees, but you shall not weaken the Postcondition.
• The invariant of your sub-class must be compatible with the base-class' invariant.

I would consider explicitly calling base-class implementation a code smell (except for constructors). It is much better to use the te,plate method pattern (or non-virtual interface in C++ ) to enforce the base-class contract. In Python, this looks like:

class Base:
   def publicMethod(self, x):
       // do something
       self.templateMethod(x)
       // do something else

   def templateMethod(self, x):
       // has to be overriden by sub-classes
       // it provides extension hooks, but
       // publicMethod ensures that the overall
       // functionality is correct