sprinboot中编程式事务_函数式编程中的副作用处理

在Side Effects in Functional Programming一文中，有用户提问：

在函数式编程的教材中，如下的行为是称之为副作用的：

• 修改一个变量
• 修改一个对象的字段值
• 抛出异常
• 在控制台显示信息、从控制台接收输入
• 在屏幕上显示（GUI）
• 读写文件、网络、数据库。

我很奇怪，如果函数式编程中，我们没有任何输入、输出等有副作用的操作，能编写什么样的程序呢？如果能，又是怎么做到的？

这个回答很有意思：

完整的回答这个问题可能需要写一本书（不用太长），这里的关键是：函数式编程是一种隔离应用逻辑（表达）与实际运行时解释的方法。 你的“函数式代码”用来表达（但不执行）所需要达成的执行效果，返回某种形式的数据结构来描述这个计算结果。然后，我们会在一个解释器中来执行该结果，后者不是函数式的。 完全的纯函数式编程是不可能的，一段纯函数式代码，出了会让CPU产生热量，不会产生其他副作用，我们还需要一个解释器来真实的进行IO操作，如读写文件、网络等。将两者隔离会带来很多的优势：纯函数式代码，更易于测试，引用透明性会让代码可读性提升，提高开发阶段的效率，减少BUG，提高产品质量。同时，函数式编程，相比命令式编程，可以让很多复杂的代码便得更简单。比如：Tired of Null Pointer Exceptions? Consider Using Java SE 8's Optional! 因此，在函数式语言中，处理副作用的方式就是隔离副作用，使用纯函数式的代码，来计算”副作用“，并将其表示为一个”值“，然后将该值交给一个解释器来执行，这个可以参考

• Hello Monad-1
• Hello Monad-2
• Hello Monad-3

在Hello Monad系列文章中描述：

通过隔离，尽量让纯函数式部分占比最大化，而让有副作用的部分限制在较小的比例中。（尽管如此，在很多应用中，这一块还是占有相当大的比例。）

这个回答与我之前思考的CERS 计算与副作用分离的设计模式是非常一致的。后续，我将继续思考如何进行副作用的隔离、表达。所以，对于事务类数据库类应用而言，一个很大的挑战就是，如何设计一个合适的IO表达形式，来反应复杂的数据交互逻辑？