oop - 为什么要避免子类型化？

Question

我看到 Scala 社区中的许多人建议避免“像瘟疫一样”进行子类型化。反对使用子类型的各种原因是什么？有哪些替代方案？

Answer 1

类型决定了组合的粒度，即可扩展性。

例如，一个接口(interface)，e.g. Comparable，它结合(从而合并)相等和关系运算符。因此，不可能仅在相等或关系接口(interface)之一上进行组合。

一般来说，substitution principle继承是不确定的。罗素悖论意味着任何可扩展的集合(即不枚举每个可能成员或子类型的类型)都可以包含自身，即是自身的子类型。但是为了识别(决定)什么是子类型而不是自身，必须完全枚举自身的不变量，因此它不再是可扩展的。这就是子类型可扩展性使继承无法确定的悖论。这个悖论必须存在，否则知识将是静态的，因此 knowledge formation wouldn't exist .

函数组合是子类型的满射替换，因为函数的输入可以替换它的输出，即任何期望输出类型的地方，都可以通过将输入类型包装在函数调用中来替换它。但是组合不会产生子类型的双射契约——访问函数输出的接口(interface)，不会访问函数的输入实例。

因而组成不必维持 future (即无界)不变量，因此可以是可扩展的和可判定的。子类型可以是 很多 在可证明可判定的地方更强大，因为它保持这种双射契约，例如对父类(super class)型的不可变列表进行排序的函数，可以对子类型的不可变列表进行操作。

所以结论是枚举每种类型(即它的接口(interface))的所有不变量，使这些类型正交(最大化组合粒度)，然后使用函数组合来完成那些不变量不正交的扩展。因此，仅当子类型可证明对父类(super class)型接口(interface)的不变量进行建模并且子类型的附加接口(interface)可证明与父类(super class)型接口(interface)的不变量正交时，子类型才适用。因此接口(interface)的不变量应该是正交的。

范畴论provides rules for the model每个子类型的不变量，即 Functor、Applicative 和 Monad，其中 preserve function composition on lifted types ，即参见前面提到的列表子类型化功能的示例。