其他
Java 帝国之函数式编程
（微信公众号“码农翻身”注： 请参考文章《Java 一个帝国的诞生》 《Java帝国之Java Bean(上)》 《Java帝国之Java Bean (下）》）
可以最近出现了一点新情况， 一群函数式编程的狂热份子不停的到总部来游行， 要求帝国向LISP学习， 支持函数式编程， 他们的理由也很充分：
“很多语言都支持函数式编程了，比如 Ruby , Python...
“人家微软的C#很早就支持了...”
这样的声音虽然不是主流，但越来越多也让我不胜其烦， 我把我最得力的助手小码哥叫来商量对策：
“小码， 外边那一群狂热分子叫嚣的函数式编程到底是什么东西？”
“唉， 老大， 其实我也不知道函数式编程的确切定义， 我只知道LISP是函数式编程的鼻祖，并且像LISP这样的语言学习起来很难，和我们的面向对象完全是两个世界， 但奇怪的是很多掌握了LISP的人都无可救药的爱上了她。”
“那它肯定有什么过人之处 ！” 我说
“像C,C++，Java， 用他们编程是一种命令式的风格， 告诉计算机如何如何做， 而用LISP编程是一种声明式的风格，就像SQL一样， 只是描述我要什么， 不去具体的描述怎么去做”
“听起来很不错啊 ” 我觉得一门语言能用声明式的方式来编程， 对程序员绝对是福音啊。
“此外， 面向对象编程更多的是对数据进行抽象， 而函数式编程是对行为进行抽象， 在LISP世界里，函数是一等公民， 函数可以当做参数传递给另外一个函数， 函数也可以作为另外一个函数的返回值。” “只用函数进行编程， 听起来不可思议啊！”
“是啊， 所以如果你学过面向对象的语言，像咱们Java, 再去学LISP, 会感到一片迷茫， 无所适从， 真气浑身乱窜， 好久才能平息下来。 ”
小码想了一会说： “有点难度， 因为Java 有一个特点，就是强类型的。”
“强类型？ ，这是什么意思？ “我问他
“是啊， 强类型， 简单的说无论任何变量都得有个类型， 并且不能变。” 小码哥没料到我还不知道这个概念， 开始兴致勃勃的给我普及。
”比如你可以声明一个变量Person p = new Person();可是如果你想让p指向另外一个对象 ： p = new House();
我们伟大的java编译器立刻就能告诉你错误： ‘类型不匹配， 不能把House转化成 Person'
强类型的好处是显而易见的， 我们在编译期间就可以消灭大部分的错误，并且还可以在你用IDE编程的时候做出很‘智能’的提示， 帮你自动补全代码。" 46 32709 46 15287 0 0 3050 0 0:00:10 0:00:05 0:00:05 3050
“与之相对的就是弱类型，例如在Ruby 中一个变量根本不需要声明类型：
p = Person.newp = House.new
这是没有任何问题的， 变量p 可以指向任何对象， 但是也丧失了提前发现错误的可能性， 很多错误只能在运行时暴露出来。
def do_something(p) p.walk(); // 假设walk只是Person独有的方法。end
系统检查不出来你到底是传递进去一个什么类型的对象， 如果p 指向一个House, House是不能walk的， 那在运行时就会报错： undefined method `walk' for #<House:0x00000002f40590>”
“但是弱类型也有好处， 例如 p = Animal.new 这个Animal 也有一个walk()方法。 那在调用do-something方法的时候完全没有问题！ ”
我有点懂了： “是不是说由于Java 是强类型的， 如果想支持函数式编程， 我们也得给这些函数找个类型 ？”
小码哥说： “是啊，不过这有点难度”
”咱们能不能重新的设计下Java 的类型系统 ？“ 我有点不甘心
“肯定不行， 我们Java 帝国为了吸引程序员，并且为了维稳， 曾经对外郑重的承诺过： 帝国要保持向后兼容性，你就是用Jdk 1.1编译的代码， 在我们jdk 8中也能运行， 要是为了函数式编程，改动太大，估计很多程序员就要抛弃我们了。”
“不管如何， 你得想想办法，在Java 中加上函数式编程， 帝国已经这么大了， 再加一点东西也没什么大不了的。”
我给了小码哥三天时间。
我接过纸一看， 上面写着：
() -> System.out.println("Hello Lambda");s-> s.toUpperCase();(x,y) -> x +y ;
“这看起来像是个函数啊？ 还起个这么时髦的名字Lambda !”
“对，Lambda可以说就是匿名函数， 我定义的语法是这样的， 箭头(->) 左边是函数的参数列表， 右边是方法体”
我看了看， 确实是， 第一个表达式 没有参数， 函数体是打印"Hello Lambda"
第二个函数有一个参数 , 函数体似乎是把这个参数变成大写字符。
第三个函数有两个参数， 函数体是把两个参数相加
“小码，既然它们是函数， 按照函数式编程风格， 就能把这些函数当做参数传递给另外一些函数了？ ”
“那是自然， 我给你举个例子“ 小码哥说
例如我们有这么个接口：public interface StringFuction{ public String apply(String s); }还有这么个函数：public String run (StringFuction f){ return f.apply("Ｈello Ｗorld");}
现在就可以把“匿名函数”当做参数传递给另外一个函数了
run (s -> s.toUpperCase()) ;
返回值就是大写字符串： HELLO WORLD
如果我们传递进去一个别的Lambda 表达式：run (s -> s.toLowerCase()) ;
返回值就是小写字符串： hello world
”我有个问题， 上次你说过咱们Java 都是强类型的， 所有的东西都得有类型， 那这个Lambda表达式s -> s.toUpperCase() 的类型是什么？ ”
小码哥说： “唉， 为了这个问题， 我可是费劲了， 我搞了个‘类型推断’， 由编译器智能的推断出s -> s.toUpperCase()的类型， 其实在上面的例子中， 这个Lambda表达式的类型就是StringFunction!"
“注意”小码哥接着说， “这个StringFunction 的apply方法接收一个字符串参数， 然后返回另外一个字符串的值。
所以当我们用s -> s.toUpperCase() 去调用的时候， 就会知道 s 就是apply的参数， s.toUpperCase()其实就是这个方法的实现了， 这个方法的返回值也是String ”
“奥，我明白了， 其实就是我们之前的匿名类嘛，我们完全可以这么写“run(new StringFuction(){ public String apply(String s) { return s.toUpperCase(); }});
"对的，本质就是这样， 对于Lambda表达式，我们只是会做更多的类型推断，如果你这么调用 : " run(s -> s.length())；
“那编译就不通过了， 因为这个匿名函数的返回值是int , 它不符合接口(StringFunction）的方法(apply)的语义， 接受一个字符串, 然后返回一个字符串。 ”
“那个函数接口的方法名称（apply）重要吗？” 我接着问
“不重要， 关键是它的输入类型和返回值， 至于名称，尽可能的好一点吧”
“唉，小码，我有点懂了， 为了维护Java 的强类型， 还得定义一个函数接口， 然后编译器会把这些匿名函数（Lambda表达式） 和这个接口做匹配， 但是你让程序员们定义函数接口， 太麻烦了吧？ ”
小码哥不慌不忙 ： “这个问题我考虑过了，我已经对咱的JDK做了增强， 特别引入了一个叫java.util.function 的包， 里边现成的函数接口足够大部分人用了”
说着， 小码哥给我展示了一个文档：
(1) Function函数接口： 传入一个类型为T的参数， 返回一个类型为R 的参数
public interface Function<T,R>{ R apply(T t); ......}
(2) Predicate<T> 函数接口 ：传入一个类型为Ｔ 的参数， 返回boolean
public interface Predicate<T> { boolean test(T t); ......}
(3) Consumer<T>函数接口 ： 传入一个类型为T的参数，没有返回值， 执行你自定义的操作public interface Consumer<T> { void accept(T t); ......}
例如s -> s.length() 就可以匹配 (1) x -> x>5 就可以匹配 (2) s -> System.out.println(s) 就可以匹配 (3)
我不仅暗暗赞叹：还是抽象大法好。
"小码，我明白你的苦心， 这些确实都是高度的抽象啊"
“老大， 这是没办法的事啊， 想想我们java 帝国那么多工具，框架， 咱必须得保持向后兼容性啊。 所以一定得坚持强类型， 即使是匿名函数， 也得给它找个类型，即函数接口 ！“
“但是有了这么东西还是不够， 似乎没有体现出像SQL那样‘声明式’编程的好处啊？ ”
“确实不够， 我们得把类库好好改改， 真正体现函数式编程的特性， 我打算引入一个叫做Stream的概念。”
(未完待续)
你看到的只是冰山一角， 更多精彩文章，尽在“码农翻身” 微信公共号