结构（鸭子）类型与 LSP 兼容吗？

Question

Does structural sub-typing make it impossible to use LSP in some cases? For example, say I have a Python* setup with nominal typing like

class Foo(ABC):
    def frobnicate(self) -> int:
        """ frobnicate in a general fashion """

class SubFoo(Foo):
    def frobnicate(self) -> int:
        """ frobnicate in a particular fashion """

def bar(f: SubFoo) -> int:
    return f.frobnicate()

I can be sure in bar that I have a SubFoo and because of LSP I know that calling it will "frobnicate in a particular fashion". That's all fine. Now suppose I use structural sub-typing instead (note the Protocol )

class Foo(Protocol):
    def frobnicate(self) -> int:
        """ frobnicate in a general fashion """

class SubFoo(Foo, Protocol):
    def frobnicate(self) -> int:
        """ frobnicate in a particular fashion """

def bar(f: SubFoo) -> int:
    return f.frobnicate()

I can't be sure in bar I have a SubFoo because a Foo also satisfies that protocol, and so I may, heaven forbid, "frobnicate in a general fashion". That is, LSP doesn't apply because there's no difference between subtypes and supertypes.

*I've used Python as an example cos that's what I know. This is a language agnostic question, but I realise it may be due to Python specifics

Answer 1

LSP is a statement of consistency, not implementation.

Subtype Requirement: Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T.

Note how LSP is merely about types and subtypes in general – not nominal , structural or other subtypes in specific.

Paraphrased, one can say that "whatever a type guarantees, its subtype must guarantee as well". Since structural types are only about structure – expressed as type guarantees – this is trivially satisfied.

---

A structural type defines subtyping only in terms of structure. For example, Foo defines the structural type:

{frobnicate: (Self) -> int}

Notably, this says that frobnicate exists, takes a Foo and returns an int . It does not say anything about how that happens, or what relation there is between input and output.
Importantly, Foo does not say whether to frobnicate in a general or specific fashion. The implementation, docstring, or similar is not part of the type.

Likewise, SubFoo defines the exact same structural type:

{frobnicate: (Self) -> int}

As far as LSP is concerned, both substitutions SubFoo <: Foo and Foo <: SubFoo are valid: Foo and SubFoo differ only in ways not captured by structural typing, and thus not guaranteed by either type.