什么时候需要动态多态（与静态多态相比）？

Question

我来自函数式语言（例如 Haskell），我非常喜欢 typeclasses 来实现多态性，这也是一种实现即席重载的结构化方法。

但是，最近我开始了解 OOP 对实际问题进行建模的方式，我很好奇为什么我们需要在 OOP 语言中使用 动态多态性（例如作为Java）。根据我的经验，大多数函数调用都可以在编译时解决，因为许多函数式语言不支持 subtyping。

所以我的问题是，在什么样的情况下我们必须使用动态多态而不是编译时多态？我的猜测是：

• 当我们使用包含对象的子类型系统时，我们无法确定其实际类型（例如，我们有一个包含许多不同类型对象的容器。但是，在这种情况下，为什么不尝试代数数据类型 或 联合类型 来模拟容器的元素类型？）。
• 我们只有对象，不知道它的方法的真实名称，所以我们必须使用 vptr 表来帮助我们。

Answer 1

在 Haskell 中，我们将“动态多态性”替换为高阶函数。

考虑以下问题：我们要定义一个表示谓词的类型。当我们实现列表时，我们最终将使用这种类型的 Predicate，以便我们可以定义过滤器函数。我们希望能够轻松定义相等谓词、小于谓词，并能够通过用“and”连接两个谓词来组合它们。

一个合理的 Java 尝试应该是这样的。

interface Predicate<T> {
    public abstract boolean predicate(T x);
}

class EqualsPredicate<T> implements Predicate<T> {
    private final T value;

    public EqualsPredicate(T value) {
        this.value = value;
    }

    @Override
    public boolean predicate(T x) {
        return this.value.equals(x);
    }
}

class LessPredicate<T implements Comparable<T>> implements Predicate<T>{
    private final T value;

    public LessPredicate(T value) {
        this.value = value;
    }

    @Override
    public boolean predicate(T x) {
        return this.value.compareTo(x) < 0;
    }
}

class AndPredicate<T> implements Predicate<T> {
    private final Predicate<T> p1;
    private final Predicate<T> p2;

    public AndPredicate(Predicate<T> p1, Predicate<T> p2) {
        this.p1 = p1;
        this.p2 = p2;
    }

    @Override
    public boolean predicate(T x) {
        return p1.predicate(x) && p2.predicate(x);
    }
}

在 Haskell 中，这个难题的答案是显而易见的。我们只是定义

type Predicate t = t -> Bool

makeEqualsPredicate :: Eq t => t -> Predicate t
makeEqualsPredicate = (==)

makeLessPredicate :: Ord t => t -> Predicate t
makeLessPredicate = (<)

makeAndPredicate :: Predicate t -> Predicate t -> Predicate t
makeAndPredicate p1 p2 x = p1 x && p2 x
-- or, even more succinctly, makeAndPredicate = liftA2 (&&)

Java 允许通过子类化“动态分派”方法。 Haskell 允许通过高阶函数“动态调度”函数。

但是等等，你说。 Predicate 是一个只有一种方法的接口。如果我们想要有两个方法，我们应该怎么做？

好吧，如果一个接口有一个方法对应一个函数，那么一个接口有两个方法一定对应一对函数。这就是所谓的“组合优于继承”的 OOP 原则。

所以我们总是可以用 Haskell 风格的高阶函数替换 Java 风格的动态多态性。

事实上，您实际上在现代 Java 中也看到了这种观察结果。从 Java 8 开始，您可以使用一种方法将注释 @FunctionalInterface 添加到接口，这允许您使用 lambdas 创建该接口的实例。所以你可以用 Java 8 编写

@FunctionalInterface
interface Predicate<T> {
    public abstract boolean predicate(T x);

    public static Predicate<J> makeEqualsPredicate(J t) {
        return (x) -> t.equals(x);
    }

    public static Predicate<J implements Comparable<J>> makeLessPredicate(J t) {
        return (x) -> t.compareTo(x) < 0;
    }

    public Predicate<T> makeAndPredicate(Predicate<T> other) {
        return (x) -> this.predicate(x) && other.predicate(x);
    }
}

Answer 2

在很多人的帮助下，目前我在反映了很多设计后得到了一些我想要的答案。由于 Rust 对静态和动态多态性都有很好的支持，我将在这个答案中使用 Rust 来证明我的观点。

我现在对动态调度有两点：用户友好的可扩展性和更小的编译大小。

第 1 点：用户友好的可扩展性

很多人认为动态调度适合你有一个容器来收集各种对象（当然，不同类型）的情况。例如：

trait MyTrait {
  fn method(&self, ...) -> ReturnType;
}

type MyContainer = Vec<Box<MyTrait>>;

fn main() {
  ...
  //the_container : MyContainer
  the_container.iter().map(... { x.method(...) } ...) //only demo code
}

在上面的代码中，在编译时，我们只知道元素是trait objects，这意味着程序将使用vptr-like策略来查找哪个方法在main函数中执行表达式时使用。

但是，还有另一种方法可以实现几乎相同的功能：

enum MyContainerTypes {
  Type0 A,
  Type1 B,
  ...
}

impl MyTrait for MyContainerType {
  fn method(&self, ...) -> ReturnType {
    match self {
      Type0 a => {...},
      Type1 b => {...},
      ...
    }
  }
}

type MyContainer = Vec<MyContainerType>;

fn main() {
  ...
  //my_container : MyContainer
  my_container.iter().map(... { x.method(...) } ...); //demo
}

通过这种方式，不需要动态多态性，但是，请考虑以下情况：您是已设计库的用户，并且您无权访问更改定义，例如enums图书馆内。现在你想创建自己的ContainerType 类型并且你想重用现有逻辑的代码。如果您使用动态调度，工作很简单：只需创建另一个您的自定义容器类型的impl，一切都很好。不幸的是，如果您使用的是静态版本的库，那么实现这个目标可能会有点困难......

第 2 点：较小的编译大小

像 Rust 这样的语言可能需要多次编译一个泛型函数，每种类型都编译一次。这可能会使二进制文件变大，这种现象在 C++ 圈子中称为代码膨胀。 让我们考虑一个更简单的情况：

trait MyTrait {
  fn method(&self, ...) -> ReturnType;
}

fn f(x: MyTrait) { ... } //MyTrait is unsized, this is unvalid rust code
fn g<T: MyTrait>(x: T) { ... }

如果你有很多函数如g，编译后的大小可能会越来越大。然而，这应该不是一个大问题，因为我们大多数人现在都可以忽略代码大小以获得充足的内存。

结论

简而言之，虽然静态多态比动态多态有很多优势，但动态调度还有一些地方可以做得更好。就我个人而言，我真的很喜欢 Haskell-like 处理多态性的方式（这也是我喜欢 Rust 的原因）。我认为这不是最终的最佳和完整答案，欢迎讨论！

组合策略

突然想到为什么不将静态和动态策略结合起来呢？为了让用户进一步扩展我们的模型，我们可以留一个小洞供用户稍后填写，例如：

trait Custom {
  fn method(&self) -> ReturnType;
}

enum Object {
  A(Type0),
  B(Type1),
  ...
  Hole(Box<dyn Custom>)
}

不过这样一来，像clone这样的一些操作可能实现起来有点困难，但我觉得这还是一个有趣的想法。

更新

Haskell 的 存在类型 也具有与 OOP 语言中的动态多态性类似的功能和实现：

data Obj = forall a. (Show a) => Obj a

xs :: [Obj]
xs = [Obj 1, Obj "foo", Obj 'c']

doShow :: [Obj] -> String
doShow [] = ""
doShow ((Obj x):xs) = show x ++ doShow xs

我还发现这个存在类型可以用来隐藏类型的一些细节，提供更干净的界面供用户使用。

编辑

感谢@MarkSaving。 第 2 点的代码有一个错误，dyn trait 对象没有调整大小，因此应该改为引用或装箱的 dyn：

fn f(x: Box<dyn MyTrait>) { ... }