FP免费Monad与OOP依赖注入

Question

我已经用函数样式(用F#)编写了我的第一个中等规模的项目，并且可以看到它的优点。主要挑战是实现“洋葱”建筑，即大而“聪明”的纯核/薄和“哑”的不纯壳。它花费了大部分时间，但也产生了最大的好处(更好的测试性、正确性、代码可重用性等)。我想知道更多。

我开始寻找将IO/效果从纯逻辑中分离出来的通用方法，并发现了很多关于免费单子的材料，主要是在Haskell (我知道F#没有HKT的，也没有本地的免费Monads )。

，从我所读到的，我是否正确地理解了：

• 自由单体并不是实现洋葱建筑的秘诀，相反，洋葱建筑是最大限度地利用自由单体的先决条件
• 与普通依赖注入相比，凌乱的、不受约束的代码之上的免费monad几乎没有什么优势。

例如，如果用于分支/决策的IO操作(由Free monad抽象或不抽象)的结果与其他逻辑不受任何约束地交织--简言之，如果函数没有简化为平面列表或非常简单的指令树，则可以由free的解释器进一步简化。

我是不是错过了一些最基本的东西？

以下是我可以参考的一篇文章：http://degoes.net/articles/modern-fp

在“享受洋葱”一段中，作者声称“我们能够进一步彻底解决我们节目的不同方面……最后，我们能够巩固那些本来会在整个节目中传播的知识……”--据称是免费的？

但是从文章中我可以看到，他首先仔细设计了洋葱和简洁的文件代数，然后才得到了上述的好处(不同的方面，解题/知识整合/优化一些复合操作的机会，如解释器中的重命名等)。当这一目标已经实现时，我仍然很难看到Free是“更好的解决方案”(来自“概要”的引用)，而不是DI容器。

Answer 1

大多数情况下，与洋葱结构相关的免费单体是一种很容易地交换洋葱外层的方法。在实践中，通常将纯解释器实现交换为单元测试，而将不纯实现转换为正常运行时。然而，它有时也用于交换不同的数据库或日志方法。

与OOP风格的依赖注入相比，它的主要优点是使用免费的monads，您在解释时只在世界的边缘注入一次依赖项。使用OOP风格，您必须在整个代码的程序规范部分中到处传递该依赖项。使用免费的monads，您的代码读起来更简洁，因为您没有额外的函数参数，它们只会将依赖项传递给较低层以启用单元测试。

即使您的代码是“不受约束的”，这种优势也不会消失，尽管纪律显然对任何范例中的代码都有好处。