gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-04 17:20:23 30 4
gpt4 key购买 nike

我遇到了 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充当接口(interface)的类,提供一些方法,如 run扩展类必须实现。但是扩展类也处理特定的输入/输出,它们也是基本输入/输出类的扩展(即 SpecificModelInput 继承自 BaseModelInput 并添加了一些字段和功能,与输出相同)
这里有什么更好的方法?

最佳答案

正如我在评论中所述:如果您真的可以将输入和输出限制为基本输入和基本输出的子类型,那么我认为此模型没有任何问题
如果违反您的意思是在限制输入选项时,子类不能再在基类可以使用的任何地方使用,我会说在这种情况下,您将 Liskov 替换原则作为教条,这应该是非常好的建议。
看,Liskov..principle 是一个很好的指导方针,有点简单,因为它会让你对继承应该是什么有一个很好的感觉。
但在现实世界中,限制输入参数(和属性类型)并不是在所有情况下都需要考虑的问题。无论如何,有一个具体的例子对我们很有用:想想一个抽象的“Vehicle”类,它有一个“board”方法,它允许你登上“Transportables”——以及具体的“Transportables”和一些“Transportable”允许的子类是人、狗、杂货袋、钢琴和大象。如果您的“Vehicle”类是“Ship” - 它可以接受所有这些。如果您的车辆类别是汽车,那么其中一些已经过时了。
这似乎是您的用例。
所以,当然,你在这里违反了原则。大多数地方的解释是“如果你在父类(super class)出现的任何地方替换子类的实例,程序应该不会中断”。
因此,最正确的做法是以任何输入 的方式修改父类(super class)契约。五月可能不起作用 ,并允许它引发运行时异常(或返回一个表示错误的对象),即使输入有效。
每个调用该方法的人都应该处理“不工作”状态——通过上面的例子很容易看出,如果我在不相关的类中有一个方法调用 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?

关于python - 更好的设计以避免违反 Liskov 替换原则,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66551300/

30 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com