如何在FP中构造组件？

Question

在OOP中，我正在按组成的结构来构造代码，拥有很多组件，并且我对此感到满意...所有事情都整齐地放在盒子里：-)在纯FP中什么被认为是好的做法？

我猜只是一个公开组件有用的Haskell模块？我应该玩数据类型吗？

例如：在域驱动设计中：服务->存储库

• ServiceA（serviceX，serviceY，repo1，repo2，repo3）
• ServiceB（serviceA，serviceC，serviceZ，repo1，repo2，repo3）
• ServiceC（serviceA，serviceB）

纯FP中发生的变化是，我不需要所有这些对象的实例化，而现在我只拥有一些功能...心态大不相同... 在我当前的代码中，所有的依赖项都被隐藏了，就像我在代码中到处使用“静态函数”一样，这对于在OOP中进行测试非常不利...

在纯FP中，我应该怎么看？

Answer 1

功能方法没有什么不同。 简要地：

1. 总是从最通用的抽象到最具体的抽象。它也确实适用于OOP，但是FP对此更为明确。特别是，这意味着您要将通用的尚未部分应用的功能与使用这些功能的模块隔开。
2. 组成。最好使“原始”功能远离合成，尤其是较长的合成。您可以将其视为＃1的子项，尽管我将其归类为不重要的事情。 （警告！某些语言，例如F＃，会迫使新来者继续使用类似(|>)运算符之类的函数来构成函数。这不是您的方式：请勿对它们进行评估，否则您将无法实现我在这里所说的内容：请确保您的组合确实会产生新功能，您可以决定何时运行它。
3. 永远不要将IO或可变代码库（在Haskell中为IO monad）与纯代码库混合使用。
4. 在适当时定义类型的同义词和新类型。将您的（Haskell）模块配置为仅导出那些位，您希望供消费者使用，而不是整个模块（当然，此类模块非常简单的情况除外）。

Answer 2

亚历山大·格兰宁（Alexander Granin）开始写一本有关“功能设计与体系结构”的书，不幸的是他没有完成这本书，但他做了其中的一部分，绝对值得一读：Sources

您还将找到here的所有详细信息：

  

  
• 从FP的角度看建筑建模，需求分析，子系统设计；
  
• 域建模中的嵌入式和外部DSL；
  
• 单子作为具有效果的子系统；
  
• 免费monads作为功能接口；
  
• 其他类型的功能接口；
  
• FP中的控制反转（使用免费的monadic eDSL）；
  
• STM，IO Ref，MVars作为并发应用程序状态； <​​/ li>   
• 镜头；
  
• 子系统设计中的状态，读取器，写入器，RWS，ST monad；
  
• GUI和FP;
  
• UML，SOLID，GRASP等主流技术和方法的适用性；
  
• 与不纯子系统的交互。
  

我希望有人会花些时间来完成它:-)