函数式编程FP

前言

（Functional programming，FP）也许能解决你遇到的某些开发问题。如果你正考虑在工作中使用函数式编程，不妨来这儿了解一些你需要知道的知识。

　　正文

　　近几年来，函数式编程（Functional programming，简称FP，下同）语言及其思想异军突起。这部分要归因于各种各样包含这种思想的语言日趋主流（如Ruby），并且开发人员们正在学习如何更好地利用它们的功能特性。它还为.NET平台（特别是C#）越来越适应许多FP思想推波助澜，使混合编程模型（hybrid model）增多。为了更进一步，现在Java平台（拥有Scala）和.NET平台（拥有F#）同时拥有支持面向对象和FP模式的全功能性语言；在.NET 4中，F#获得了与C＃和VB。NET同等的重视。现在，大多数开发人员有能力学习掌握FP语言及其理念，但什么时候这样做才有意义呢？

　　如果你正在考虑使用FP，你需要牢记这些事情：

• FP代码没有“副作用（side effects）。”
• FP中没有字面值（literal value），简单的功能只返回相同值。
• 许多FP语言具有“惰性计算（lazy evaluation）”机制，即函数不进行计算，直到需要用到它们的返回值。在这种情况下，如果你定义“x”的值为“y + 5”，“x”的值仍是未定义的，直到您尝试使用“x”的值，此时执行返回到它的定义，计算其值并提供给调用者。这是福音（更好的性能），同时也是祸端（在某些情况值不确定）。
  

　　然而FP语言的这些特性都不应被视为障碍，因为它们代表了思想上的根本转变。利用FP语言，你或许能出乎意料地提高代码的编写过程和代码质量。但是，如果使用FP语言，你必须考虑到是否存在超脱工程（overengineering）或超脱思想（overthinking）的问题，特别是当代码的其他维护者可能需要学习一个新的语言的时候。

　　根据我的经验（在产品代码中使用FP的时间有限），我认为FP技术和语言在算法编码方案（algorithmic coding scenarios）方面表现抢眼。也许我的成见是基于FP的“一切都基于函数”的做法，但我发现FP的确在那方面表现得非常好。例如数学就与FP很投缘。几个月前，我看到一个F#代码例子，作者将其中的测量可变单元定义为提供转换功能的函数，因此可以十分自然地在代码中增加10米和45英寸。另一种令人对对FP实力印象深刻的例子是Xbox Live排名系统，用F#替代C#重写后，代码行数只有原先的10%，而运行速度却达到了原先的95％。同样，它是一个算法编码的例子。

　　FP丧失的优势在于基本的“库粘接代码（library glue code）”和创建结构类的能力，而这些正是现代主流软件开发经验的组成部分。如果您的代码包含了很多看上去就像结构的类，并且绝大多数“算法代码（algorithm code）”可归并为各个对象的属性和方法，那么使用FP就不值得了，除非你的项目非要使用它不可。

　　总结

　　总之，FP不一定是解决你开发工作中所面临的所有挑战问题的答案，但是值得考虑一下，看看它能否在工作中有用武之地。