就OOP程序员所能理解的（没有任何功能编程背景）而言，什么是monad？
它解决了什么问题，最常用的地方是什么？
使现代化
为了澄清我所寻求的理解，假设您正在将一个具有monad的FP应用程序转换为OOP应用程序。如何将monad的职责移植到OOP应用程序？
当前回答
我想说，与monads最接近的OO类比是“命令模式”。
在命令模式中，将普通语句或表达式包装在命令对象中。命令对象公开执行包装语句的执行方法。所以，语句被转换为可以随意传递和执行的第一类对象。可以组合命令，以便通过链接和嵌套命令对象来创建程序对象。
命令由单独的对象调用程序执行。使用命令模式（而不仅仅是执行一系列普通语句）的好处是，不同的调用程序可以将不同的逻辑应用于如何执行命令。
命令模式可用于添加（或删除）宿主语言不支持的语言功能。例如，在没有异常的假设OO语言中，可以通过向命令公开“try”和“throw”方法来添加异常语义。当命令调用throw时，调用程序会回溯到命令列表（或树），直到最后一次“try”调用。相反，您可以通过捕获每个单独命令抛出的所有异常，并将它们转换为错误代码，然后传递给下一个命令，从而从语言中删除异常语义（如果您认为异常是坏的）。
甚至更花哨的执行语义（如事务、非确定性执行或延续）也可以用本机不支持的语言实现。如果你仔细想想，这是一个非常强大的模式。
实际上，命令模式并没有像这样作为通用语言特性使用。将每个语句转换为单独的类的开销将导致无法忍受的样板代码。但原则上，它可以用于解决与在fp中使用monad解决的问题相同的问题。
其他回答
我分享了我对蒙纳斯的理解，这在理论上可能并不完美。Monad是关于上下文传播的。Monad就是，您为某些数据（或数据类型）定义一些上下文，然后定义该上下文将如何在整个处理管道中与数据一起传递。定义上下文传播主要是定义如何合并多个上下文（相同类型）。使用Monads还意味着确保这些上下文不会意外地从数据中剥离。另一方面，可以将其他无上下文数据带入新的或现有的上下文中。然后，可以使用这个简单的概念来确保程序的编译时正确性。
看到我对“什么是monad？”的回答了吗
它从一个激励性的例子开始，通过这个例子，导出一个monad的例子，并正式定义“monad”。
它假设不了解函数式编程，并且使用带有函数（参数）：=表达式语法的伪代码和最简单的表达式。
这个C++程序是伪代码monad的一个实现。（仅供参考：M是类型构造函数，feed是“绑定”操作，wrap是“返回”操作。）
#include <iostream>
#include <string>
template <class A> class M
{
public:
A val;
std::string messages;
};
template <class A, class B>
M<B> feed(M<B> (*f)(A), M<A> x)
{
M<B> m = f(x.val);
m.messages = x.messages + m.messages;
return m;
}
template <class A>
M<A> wrap(A x)
{
M<A> m;
m.val = x;
m.messages = "";
return m;
}
class T {};
class U {};
class V {};
M<U> g(V x)
{
M<U> m;
m.messages = "called g.\n";
return m;
}
M<T> f(U x)
{
M<T> m;
m.messages = "called f.\n";
return m;
}
int main()
{
V x;
M<T> m = feed(f, feed(g, wrap(x)));
std::cout << m.messages;
}
按照OOP程序员将理解（没有任何功能编程背景），什么是莫纳德？它解决了什么问题是最常用的地方吗？是最常用的地方吗？
就OO编程而言，monad是一个接口（或者更可能是一个mixin），由一个类型参数化，具有两个方法，return和bind，它们描述：
如何注入值以获得注入值的一元值类型如何使用从非一元值。
它解决的问题与您期望的任何接口的问题类型相同，“我有很多不同的类，它们做不同的事情，但似乎以一种具有潜在相似性的方式来做这些不同的事情。即使这些类本身不是比‘Object’类本身更接近的子类，我如何描述它们之间的相似性？”
更具体地说，Monad“接口”与IEnumerator或IIterator相似，因为它采用的类型本身也采用的类型。然而，Monad的主要“点”是能够连接基于内部类型的操作，甚至可以连接到具有新的“内部类型”的点，同时保持-甚至增强-主类的信息结构。
我想说，与monads最接近的OO类比是“命令模式”。
在命令模式中，将普通语句或表达式包装在命令对象中。命令对象公开执行包装语句的执行方法。所以，语句被转换为可以随意传递和执行的第一类对象。可以组合命令，以便通过链接和嵌套命令对象来创建程序对象。
命令由单独的对象调用程序执行。使用命令模式（而不仅仅是执行一系列普通语句）的好处是，不同的调用程序可以将不同的逻辑应用于如何执行命令。
命令模式可用于添加（或删除）宿主语言不支持的语言功能。例如，在没有异常的假设OO语言中，可以通过向命令公开“try”和“throw”方法来添加异常语义。当命令调用throw时，调用程序会回溯到命令列表（或树），直到最后一次“try”调用。相反，您可以通过捕获每个单独命令抛出的所有异常，并将它们转换为错误代码，然后传递给下一个命令，从而从语言中删除异常语义（如果您认为异常是坏的）。
甚至更花哨的执行语义（如事务、非确定性执行或延续）也可以用本机不支持的语言实现。如果你仔细想想，这是一个非常强大的模式。
实际上，命令模式并没有像这样作为通用语言特性使用。将每个语句转换为单独的类的开销将导致无法忍受的样板代码。但原则上，它可以用于解决与在fp中使用monad解决的问题相同的问题。
为什么我们需要单子？
我们只想使用函数编程。（毕竟是“功能编程”-FP）。然后，我们遇到了第一个大问题。这是一个程序：f（x）=2*xg（x，y）=x/y我们怎么能说首先要执行什么？我们如何使用不超过个函数来形成一个有序的函数序列（即程序）？解决方案：组合函数。如果你先要g，然后要f，只需写f（g（x，y））。好的，但是。。。更多问题：某些函数可能会失败（即g（2,0），除以0）。我们在FP中没有“例外”。我们如何解决它？解决方案：让我们允许函数返回两种东西：而不是g:Real，Real->Real（函数从两个实数转换为实数），让我们允许g:Real、Real->Real|Nothing（函数从一个实数转换成（实数或零））。但函数应该（更简单地）只返回一件事。解决方案：让我们创建一种要返回的新类型的数据，一种“装箱类型”，它可能包含一个真实的数据，也可能只是一个空数据。因此，我们可以有g：真实，真实->可能真实。好的，但是。。。f（g（x，y））现在发生了什么？f还没有准备好使用“也许真的”。而且，我们不想改变我们可以与g连接的每一个函数，以使用Maybe Real。解决方案：让我们有一个特殊的函数来“连接”/“组合”/“链接”函数。这样，我们就可以在幕后调整一个函数的输出，以支持下一个函数。在我们的例子中：g>>=f（连接/合成g到f）。我们希望>>=获取g的输出，检查它，如果它是Nothing，则不要调用f并返回Nothing；或者相反，提取装箱的实数并用它来馈送f。（此算法只是Maye类型的>>=的实现）。出现了许多其他问题，可以使用相同的模式来解决：1。使用“框”来编码/存储不同的含义/值，并具有像g这样的函数来返回这些“框值”。2.让作曲家/链接器g>>=f帮助将g的输出连接到f的输入，这样我们就不必改变f。使用该技术可以解决的显著问题有：具有函数序列中的每个函数（“程序”）可以共享的全局状态：解StateMonad。我们不喜欢“不纯函数”：对相同输入产生不同输出的函数。因此，让我们标记这些函数，使它们返回一个标记/装箱的值：IOmonad。
完全幸福！！！！
