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

Question

我最近一直在深入研究一些坚实的设计原则，我从一个来源获得的一些信息最初对我来说是有意义的，但基于我能够找到的关于thr LSP的严格定义，这些信息似乎不正确。具体信息如下：

1） 不在重写的方法上回调super（）会违反LSP（或者至少会导致违反），因为基类的行为可能会在某个点上发生更改，并且您的子类可能会丢失该行为，从而导致子类不再可以替换父类。这对我来说似乎是有道理的，但如果有人能详细说明这一点/提供一些信息，说明什么时候不回super是合适的，那就太好了。

2） 子类的限制性不应小于父类。这个例子是：如果您有一个只接受正整数的父类，那么您可以创建一个同时接受正整数和负整数的子类。因此，孩子应该代替父母工作得很好，但在这种情况下，孩子不能委托给super。

我认为这是有道理的，但是LSP上的信息似乎恰恰相反：一个先决条件不能被孩子强化。两者对我来说似乎都有意义，但利斯科夫只是说先决条件不能加强，后置不能削弱。有人能帮我解释一下吗？

Answer 1

Liskov替换原则要求在需要基类型时可以使用子类型。为此，必须遵守基本类型的约定。对于具有方法f、前置条件、后置条件和不变量I的基类B，这意味着

• 调用方代码仅保证在可能使用对象时预保持。如果Pre保持不变，则前提条件也必须保持不变。逻辑上，Pre表示派生方法的前置条件。这意味着您可以扩大前提条件，因为前提条件-

我会考虑显式地将基类实现称为代码气味（构造函数除外）。使用te、板方法模式（或C中的非虚拟接口）来强制执行基类契约要好得多。在Python中，这看起来像：

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

Answer 2

1） 在这种情况下，什么时候不回电话给super是合适的

通常（但并非总是）这种情况意味着类层次结构设计有问题。

如果子方法接受正确的输入类型并返回正确的输出类型，则不调用超类实现不会违反LSP。它只表明问题的可能性。

下面是一个不调用super方法的绝对有效的示例：

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

这里的CatOwner:：findAPet（）返回一个Cat（一个Animal子类），这在LSP方面是有效的，我们不调用父实现。

考虑到调用父实现并不能保证您不会陷入与不调用它时相同的问题。

考虑这个例子：

 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）“前提条件不能在一个子类型中加强”。这也意味着前置条件（与输入参数相关的期望）可以保持不变或被削弱。在你提到的例子中，前提条件实际上被削弱了，所以没有冲突：

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

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

不完全正确的是第一句话：“子类不应该比父类限制更少”。当我们谈论前置条件（输入参数）时，子类的限制性较小，这就是示例中所示的。