Apply Functional Programming Principles运用函数式编程原则(97 Things Every Programmer Should Know 2/97)

Apply Functional Programming Principles

文章链接：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 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.

By Edward Garson

翻译

最近函数式编程再次引起了主流编程团体的兴趣.一部分原因是函数式范式的新特性能够比较好地解决一些挑战,这些挑战是我们的行业移向多核导致的.然而,尽管那是一个重要的应用,但是这不是劝告你了解函数式编程的原因.

掌握函数式编程范式可以极大地提升你写的代码的质量.如果你深切地理解和应用函数式编程范式,你的设计将会展示一个更高程度的引用透明性(函数对于相同的输入,返回相同的结果).

引用透明性是一个非常令人向往的属性:它意味着当被给予相同的输入时,函数将一致地产生相同的结果,而不用考虑何时何地被调用.也就是说,函数估值较少依赖,理想情况下完全不依赖易变状态的副作用.

在命令式代码(和它相对应的还有一种声明式代码)中，引起缺点的一个首要原因可归于易变的变量。读到这的每个人将研究为何一些值在一些情况下并非预想的那样.可见度语义学可以帮助去减少这些隐伏的缺点,或者至少彻底地压缩它们的空间,但是它们真正的罪犯实际上可能是采用无次序易变性的原生设计.

就这一点而言,我们没有从行业中得到很多的帮助.面向对象概论默默地助长了这样的设计,因为他们经常展示由相关长生命周期对象构成的例子,这些对象之间很开心的调用赋值方法,而这些可能是危险的.然而,随着TDD的引入,特别是当确信"扮演角色,而非对象"时,不必要的易变性可以在设计中被规避掉.

最后的结果是一种有更好责任分配的设计–有更多小的函数,通过参数进行传递,而不是引用易变的成员变量.这样将使程序中的问题减少，而且更容易去调试，因为这样更容易定位到凶猛的变量是在哪里被引入的，比起另外地推断导致错误赋值的特定的上下文。这些加起来可以达到一个更高程度的引用透明性，可以肯定地，没有什么比你学习一门函数编程语言更能够深入骨子里地得到这些思想了，在这些语言中计算的模型就是标准。

当然这个方式不是最好的解决方案。比如，在面向对象系统中,使用领域模型开发能够产生更好的结果(比如,这里合作服务去分解业务规则的复杂性)比着使用UI开发模式.

精通函数式编程范式,如此你就可以明智地应用学到的课程到其他的领域.你的对象系统将和引用透明性美德,并且也会超乎你想象的接近他们在函数式编程领域的具有同样功能的系统。实际上，有些人甚至会断言，从他们的最高处看下去，函数式编程和面向对象编程不过是相互之间的倒影，犹如阴与阳的一种计算形式。