Apply Functional Programming Principles
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 Fas 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.
应用函数式编程原则
函数式编程最近再次获得了主流编程社区的关注。部分原因是因为函数式编程的模式能很好的适应行业向多核发展带来的挑战。然而，尽管这很重要，却并不是你需要了解函数式编程的主要原因。
掌握函数式编程能显著提高你的代码在其他上下文中的质量。如果你能深刻的理解和应用函数式编程，你的程序设计就能呈现出非常高度的引用透明。引用透明性是我们非常想要的特性：它保证了无论代码在何时何地被调用，相同的输入都会得到相同的输出结果。就是说，对比共享状态，函数赋值依赖更少，理想情况是完全没有。
命令式编程的一大缺陷就是公共变量，每个阅读到公共变量的人都要深入挖掘为什么变量的值在当前情景下不是自己预期的那个。良好的命名和排版能降低这种缺陷，至少能大幅缩小要检索的范围。但造成代码缺陷的根本原因还是程序设计中对变量的滥用。
就这个问题我们无法从行业获得太多帮助，面向对象的编程方法有意无意的助长了这样的设计。他们经常会展示这样的范例：范例由图表和长期存在的对象组成，他们高兴地将这种对象称为赋值方法，这可能是一种危险的设计。但是，通过巧妙的测试驱动开发的设计，特别是确保做到“模拟职责，而不是对象”，就能通过设计消除不必要的可变性。
最终的结果就是按照职责划分了更多更小的方法，它们接受传入的参数，而不是共享变量。这样的设计缺陷更少，更重要的是易于调试，因为这样的设计容易定位何处引入了错误，而不是去推测发生错误的代码段。这使你的程序的引用透明程度大幅提高，要让这种意识深入骨髓，最好的办法莫过于学习一门将这种设计作为规范的函数式编程语言。
当然，这种做法也并不是适用于所有的情景。例如，在面向对象系统中，这种模式应用在领域模型开发（用来分解商业规则的复杂度）的效果一般要好于用户界面开发。
掌握了函数式编程的规范你就能明智地将本课的内容应用在其他领域。你的对象系统获得了引用透明带来的好处并且功能上比你预想要更加契合。事实上，甚至有人断言，函数式编程和面向对象设计的终点是殊途同归，是计算机行业的阴阳两极。
后记：因前段时间事情较多，没有顾上更新。这是系列文章的第2篇，篇幅和难度较第1篇都有增大，因本人能力所限，翻译质量不是很高，希望看到的朋友能够多提出意见。