Monad是继承层次结构的可行替代方法吗？

我将使用像monads这样的语言不可知的描述，首先描述monoid：

甲独异是（大约）的一组需要一些类型作为参数并返回相同的类型的功能。

甲单子是（大约）的一组需要的功能封装器类型作为参数并返回相同的包装类型。

注意这些是描述，而不是定义。随意攻击该描述！

因此，在OO语言中，monad允许以下操作组合：

Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()

请注意，monad定义并控制这些操作的语义，而不是所包含的类。

传统上，在OO语言中，我们将使用类层次结构和继承来提供这些语义。因此，我们将有一个Bird带有方法takeOff()，flyAround()和的类land()，而Duck将继承这些方法。

但是后来我们遇到了不能飞的鸟，因为penguin.takeOff()失败了。我们必须求助于异常抛出和处理。

另外，一旦我们说企鹅是a Bird，我们就会遇到多重继承问题，例如，如果我们也有的层次结构Swimmer。

本质上，我们试图将类归类（对“分类论”的人道歉），并按类别而不是单个类来定义语义。但是，与层次结构相比，monad似乎是一种更清晰的机制。

因此，在这种情况下，我们将有一个Flier<T>单子，如上面的示例：

Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()

...而且我们永远不会实例化一个Flier<Penguin>。我们甚至可以使用静态类型来防止这种情况的发生，也许使用标记接口。或运行时功能检查以纾困。但是，实际上，程序员切勿将企鹅放入Flier，从同样的意义上讲，它们切勿除以零。

而且，它更普遍适用。飞行器不必一定是鸟。例如Flier<Pterodactyl>或Flier<Squirrel>，而不更改这些单个类型的语义。

一旦我们通过容器上的可组合函数对语义进行了分类（而不是按类型层次结构进行分类），它就解决了“某种行为，某种行为不适合”特定类的旧问题。它还轻松明确地为一个类提供了多种语义，例如Flier<Duck>和Swimmer<Duck>。似乎我们一直在通过按类层次结构对行为进行分类来应对阻抗不匹配的问题。Monad优雅地处理它。

因此，我的问题是，就像我们倾向于偏爱组成而非继承一样，偏爱单子而不是继承是否也有意义？

（顺便说一句，我不确定是应该在这里还是在Comp Sci中使用，但这似乎更像是一个实际的建模问题。但是也许在那儿会更好。）

简短的答案是“ 否”，单子不能代替继承层次结构（也称为子类型多态性）。您似乎正在描述参量多态性，monad会利用它，但并非唯一这样做。

据我了解，单子从本质上讲与继承无关。我要说的是，这两个东西或多或少是正交的：它们旨在解决不同的问题，因此：

1. 它们可以在至少两种意义上协同使用：
   • 查看Typeclassopedia，它涵盖了Haskell的许多类型类。您会注意到它们之间存在类似继承的关系。例如，Monad源自Applicative，而Applicative本身又来自Functor。
   • 作为Monad实例的数据类型可以参与类层次结构。记住，Monad更像是一个接口-为给定类型实现它可以告诉您有关数据类型的一些信息，但不是全部。
2. 试图用一个做另一件事将是困难和丑陋的。

最后，尽管这与您的问题有关，但您可能有兴趣了解monad确实有一些难以置信的强大构图方式。阅读有关monad变压器的更多信息。但是，这仍然是一个活跃的研究领域，因为我们（而且我的意思是，比我聪明100000倍的人）还没有找到构成Monad的好方法，而且似乎有些Monad并不是随意编写的。

现在来提您的问题（对不起，我希望这对您有所帮助，而不是让您感到难过）：我觉得我有很多可疑的前提，我会尝试阐明一些前提。

1. monad是将容器类型作为参数并返回相同容器类型的一组函数。

   不，这是Monad在Haskell中：参数化类型m a，其实现为return :: a -> m a和(>>=) :: m a -> (a -> m b) -> m b，并满足以下定律：

   return a >>= k  ==  k a
   m >>= return  ==  m
   m >>= (\x -> k x >>= h)  ==  (m >>= k) >>= h
   

   有些Monad实例不是容器（(->) b），有些容器不是（也不能做成）Monad实例（Set由于类型类的限制）。因此，“容器”的直觉是可怜的。见这为更多的例子。

2. 因此，在OO语言中，monad允许以下操作组合：

     Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()
   

   一点都不。该示例不需要Monad。它所需要的只是具有匹配输入和输出类型的函数。这是另一种编写方法，强调了它只是函数应用程序：

   Flier<Duck> m = land(flyAround(takeOff(new Flier<Duck>(duck))));
   

   我相信这是一种称为“流利接口”或“方法链接”的模式（但我不确定）。

3. 请注意，monad定义并控制这些操作的语义，而不是所包含的类。

   也是monad的数据类型可以（并且几乎总是如此！）具有与monad无关的操作。这是一个Haskell示例，它由三个[]与monad没有任何关系的函数组成：[]“定义和控制操作的语义”，而“ contained class”没有，但这不足以构成monad：

   \predicate -> length . filter predicate . reverse
   

4. 您已经正确地指出，使用类层次结构为事物建模存在一些问题。但是，您的示例并未提供任何证据表明monad可以：

   • 做好继承擅长的工作
   • 做好继承不善的工作

因此，我的问题是，就像我们倾向于偏爱组成而非继承一样，偏爱单子而不是继承是否也有意义？

在非OO语言中，是的。在更传统的面向对象语言中，我会拒绝。

问题是大多数语言都没有类型专门化，这意味着您不能制作Flier<Squirrel>并且Flier<Bird>具有不同的实现。您必须做类似的事情static Flier Flier::Create(Squirrel)（然后为每种类型重载）。反过来，这意味着您每次添加新动物时都必须修改此类型，并且可能要复制大量代码才能使其起作用。

哦，而且在几种语言（例如C＃）中public class Flier<T> : T {}是非法的。它甚至不会建立。大多数（如果不是全部）OO程序员期望Flier<Bird>仍然是Bird。