02使用函数编程原则
Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because emergent properties of the functional paradigm are well positioned to address the challenges posed by our industry's shift toward multi-core. However, while that is certainly an important application, it is not the reason this piece admonishes you to know thy functional programming.
函数式编程最近重新受到主流编程界的关注。部分是因为函数型范式的 新兴属性 能够很好地应对我们业向多核转变所带来的挑战。虽然这是一个重要的方面，但这并不是本文告诫你要 了解你的函数编程 的原因。
Mastery of the functional programming paradigm can greatly improve the quality of the code you write in other contexts. If you deeply understand and apply the functional paradigm, your designs will exhibit a much higher degree of referential transparency.
掌握函数编程范式可以大大提高在其他环境中编写的代码的质量。如果你深入理解和应用函数型范式，你的设计将展现更高程度的 引用透明性 。
Referential transparency is a very desirable property: It implies that functions consistently yield the same results given the same input, irrespective of where and when they are invoked. That is, function evaluation depends less — ideally, not at all — on the side effects of mutable state.
引用透明性是一个非常理想的属性：它意味着，任何时间，在给定相同输入的情况下，函数始终会产生相同的结果。也就是说，函数输出更少的依赖于（理想情况下，一点也不依赖于）可变状态的副作用。
A leading cause of defects in imperative code is attributable to mutable variables. Everyone reading this will have investigated why some value is not as expected in a particular situation. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability.
过程式编码产生缺陷的主要原因是可变量。在读这篇文章的每个人，都会有过这样的经验：为什么在特定情况下有些输出不符合预期。可见性语义可以帮助减少这些隐藏的缺陷，或者至少可以大大缩小定位问题所需查找的范围。但实际上，真正问题很可能是过度使用了可变性设计。
And we certainly don't get much help from industry in this regard. Introductions to object orientation tacitly promote such design, because they often show examples composed of graphs of relatively long-lived objects that happily call mutator methods on each other, which can be dangerous. However, with astute test-driven design, particularly when being sure to "Mock Roles, not Objects", unnecessary mutability can be designed away.
在这方面，我们当然得不到工业界的多大帮助。面向对象设计方式无形中促进了这种设计，因为它们经常使用由相对长寿的对象的图形组成的例子，这些对象愉快地彼此调用可变方法，而对潜在的危险浑然不觉。但是，通过精妙的测试驱动设计，特别是当确保"模拟角色，而不是对象"时，不必要的可变性可以被去除。
The net result is a design that typically has better responsibility allocation with more numerous, smaller functions that act on arguments passed into them, rather than referencing mutable member variables. There will be fewer defects, and furthermore they will often be simpler to debug, because it is easier to locate where a rogue value is introduced in these designs than to otherwise deduce the particular context that results in an erroneous assignment. This adds up to a much higher degree of referential transparency, and positively nothing will get these ideas as deeply into your bones as learning a functional programming language, where this model of computation is the norm.
最终的结果是这样的设计：它通常具有更好的责任分配，而且有更多、更小的函数；这些函数通过传递给它们的参数，而不是通过引用可变成员变量来完成任务。缺陷会更少，而且调试起来也更简单，因为在这些设计中定位异常值的位置比推断导致错误分配的特定上下文更容易。这增加了更高程度的参考透明性，肯定没有什么比学习一种函数式编程语言更能深入你的内心，而这种计算模式是常态。
Of course, this approach is not optimal in all situations. For example, in object-oriented systems this style often yields better results with domain model development (i.e., where collaborations serve to break down the complexity of business rules) than with user-interface development.
当然，这种方法并非在所有情况下都是最佳的。例如，在面向对象的系统中，与用户界面开发相比，这种风格通常在领域模型开发(即协作用于分解业务规则的复杂性)中会产生更好的结果。
Master the functional programming paradigm so you are able to judiciously apply the lessons learned to other domains. Your object systems (for one) will resonate with referential transparency goodness and be much closer to their functional counterparts than many would have you believe. In fact, some would even assert that the apex of functional programming and object orientation are merely a reflection of each other, a form of computational yin and yang.
掌握函数编程范式，以便能够明智地将学到的经验应用到其他领域。你的对象系统(例如)将与参考透明性的优点产生共鸣，并且比许多人想象的更接近它们的功能对等体。事实上，有些人甚至断言函数编程和面向对象 仅仅是彼此的反映 ，是计算机中阴与阳共存的一种表现形式。
Last updated