简体   繁体   English

不违反 Liskov 替代原则的替代方案

[英]Alternative that doesn't violate the Liskov substitution principle

Considering the following structure of classes:考虑以下类的结构:

from abc import ABC, abstractmethod


class ModelSettings(ABC):
    ...

class BlueModelSettings(ModelSettings):
    ...

class RedModelSettings(ModelSettings):
    ...


class Model(ABC):
    @abstractmethod
    def compute(self, settings: ModelSettings):
        ...

class BlueModel(Model):
    def compute(self, settings: BlueModelSettings):
        ...

class RedModel(Model):
    def compute(self, settings: RedModelSettings):
        ...

MyPy is complaining that the implementations of compute in BlueModel and RedModel violate the Liskov substitution principle. MyPy 抱怨BlueModelRedModel中的compute实现违反了 Liskov 替换原则。 I understand this and also understand why it makes sense.我理解这一点,也理解它为什么有意义。

My question is, instead of the above structure, what would be another approach that would satisfy the following requirements:我的问题是,除了上述结构之外,还有什么方法可以满足以下要求:

  • base model has a contract that compute should receive settings, not apples or oranges基本模型有一个合同, compute应该接收设置,而不是苹果或橘子
  • but each specific model should accept only settings relevant to its own model kind但每个特定模型应该只接受与其自己的模型类型相关的设置

In a way, I essentially want that a subclass' method argument is stricter than what its base class stipulates, which goes directly against the Liskov principle.在某种程度上,我本质上希望子类的方法参数比它的基类规定的更严格,这直接违背了 Liskov 原则。 Which is what's telling me there might be a more suitable approach.这就是告诉我可能有更合适的方法。

Note:笔记:

  • Model is library code so it can't know of eg BlueModelSettings which is client code Model是库代码,因此它不知道例如BlueModelSettings是客户端代码

You need your Model to be generic in the type of settings .您需要您的Modelsettings类型中是通用的。

T = TypeVar('T', bound=ModelSettings)

class Model(ABC, Generic[T]):
    @abstractmethod
    def compute(self, settings: T):
        ...

class BlueModel(Model[BlueModelSettings]):
    def compute(self, settings: BlueModelSettings):
        ...

class RedModel(Model[RedModelSettings]):
    def compute(self, settings: RedModelSettings):
        ...

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 Liskov 替换原则 - The Liskov substitution principle 需要明白理解liskov替代原则 - Need clarity in Understanding liskov substitution principle 避免违反Liskov替代原则的密码敏捷性的Pythonic解决方案 - Pythonic solution to cryptographic agility that avoids violating Liskov's substitution principle Mypy 产生不兼容的签名错误但满足 Liskov 替换原则 - Mypy produces incompatible signature error but Liskov Substitution Principle is satisfied 工厂类方法是否违反了Liskov替代原理? - Do factory class methods break the Liskov substitution principle? 如果“字段”>“ CharField”>“ EmailField”,EmailField是否打破Chars的Liskov替换原则? - If Field > CharField > EmailField, does EmailField break Liskov Substitution Principle with CharField? 更好的设计以避免违反里氏替换原则 - Better design in order to avoid violating Liskov Substitution principle Python 理解里氏替换原理 - Python understanding Liskov Substiution Principle 重载(而不是压倒一切)是否违反了 Liskov 替换原则? - Does overloading (not overriding) break the Liskov subsitution principle? Heroku中的某人可以确认我的备份脚本没有违反他们的条款吗? - Can someone from Heroku confirm my backup script doesn't violate their terms?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM