更好的设计以避免违反 Liskov 替换原则

如何解决更好的设计以避免违反 Liskov 替换原则

我遇到了 Liskov 替换原则的问题，我不太确定解决它的最佳方法是什么。

有问题的代码

class BaseModel:
    def run(self,base_model_input: BaseModelInput) -> BaseModelOutput:
        """Throws NotImplemented or @abstractmethod"""
        pass

class SpecificModel(BaseModel):
    def run(self,specific_input: SpecificModelInput) -> SpecificModelOutput:
        # do things...

我很清楚为什么这不是一个很好的代码，为什么它违反了 Liskov 替换原则。我想知道如何更好地设计我的系统来首先避免这个问题。

从根本上说，我有一个 BaseModel 类，它的作用类似于接口，提供了一些扩展类必须实现的方法，例如 run。但是扩展类也处理特定的输入/输出，它们也是基本输入/输出类的扩展（即 SpecificModelInput 继承自 BaseModelInput 并添加了一些字段和功能，与输出相同）>

这里有什么更好的方法？

解决方法

正如我在评论中所说：如果你真的可以将输入和输出限制为基本输入和基本输出的子类型，我认为这个模型没有任何问题

如果违反您的意思是在限制输入选项时，子类不能再在基类可以使用的任何地方使用，我会说这是您将 Liskov 替换原则作为教条 它应该非常 好 建议。

看，Liskov..principle 是一个很好的指导方针，有点简单，因为它会让你对继承应该是什么有一个很好的感觉。

但在现实世界中，限制输入参数（和属性类型）并不是在所有情况下都需要考虑的问题。无论如何，有一个具体的例子对我们很有用：想想一个抽象的“Vehicle”类和一个“board”方法，它允许你登上“Transportables”——具体的“Transportables”和一些“Transportable”允许的子类是人、狗、杂货袋、钢琴和大象。如果您的“Vehicle”类是“Ship” - 它可以接受所有这些。如果您的车辆类别是汽车，那么其中一些已经过时了。

这似乎是您的用例。

所以，当然，你在这里违反了原则。解释它的大多数地方的措辞是“如果您在超类出现的任何地方替换子类的实例，则程序不应中断”。 因此，最正确的做法是以任何输入可能或可能不起作用的方式修改超类契约，并允许它引发运行时异常（或返回一个表示错误的对象），即使输入有效。

每个调用该方法的人都应该处理“不工作”状态——通过上面的例子很容易看出，如果我在一个不相关的类中有一个调用 vehicle.board 的方法，它应该负责查看它不是试图将大象放入车内。如果在所有调用方法的地方都进行了这些检查，则原理成立！

如果对您的任何任务进行工程设计都是过度的，在这种情况下，我会说“...实用性胜过纯度”，只需设置注释以使静态类型检查器静音。

当然，告诉静态类型检查器是另一回事 - 我认为在评论中链接的答案中指出使用泛型可以做到：How do I annotate the type of a parameter of an abstractmethod,when the parameter can have any type derived from a specific base type?