如果Field>CharField>EmailField，EmailField是否用CharField打破了Liskov替换原理？

Question

假设我正在用Form类编写一个webapp，Form类可以有几个Fields。你知道吗

Field本身是一个抽象类。它包含一个抽象的validators属性，该属性是它将调用以确定字段内容是否有效的方法列表。这些验证器由实例方法Field.run_validators(value)调用调用

CharField是允许任意文本的Field子类。只要给定长度为非零的字符串，该字段就始终有效。你知道吗

EmailField是带有附加要求的CharField子类。此字段仅在value通过某种测试集时有效。（例如'@' in value）。你知道吗

我的问题是：EmailField是否打破了关于CharField的LSP？应该改为兄弟班吗？尽管Field通过允许子类提供自己的validators来定义可变性，但TextField并没有显式地扩展这种可变性。你知道吗

我一直试图找到更多关于LSP的解释，但它们都重用了相同的矩形/正方形示例。你知道吗

给出：

def transmogulate(field):
    """field must be a TextField instance."""
    assert isinstance(field, TextField)
    instance.run_validators("hello")

使用CharField时，transmogulate(my_text_field)将毫无问题地运行。但是如果my_text_field是EmailField的一个实例，它总是会引发ValidationError。这是否违反了LSP？还是我的推理完全颠倒了？（这种情况经常发生）

同样，你也可以愉快地想象run_validators()返回False，而不是在某种程度上改变分析时引发异常；我只是想让我的示例尽可能接近源材料。你知道吗

Answer 1

我认为只要EmailField提供与CharField相同的方法（看起来是这样的），设计就可以了。如果它仍然像鸭子一样呱呱叫，它就会跟着LSP。子类可以有不同的实现或行为。你知道吗