面向对象 vs. 函数式编程

10-11-04 banq
                   

Object oriented vs. functional programming — The Endeavour

OO makes code understandable by encapsulating moving parts.

OO通过切分封装能够更加易懂

FP makes code understandable by minimizing moving parts.

而FP通过最小化切分使得代码更加易懂。

前者试图将状态隐藏于对象接口之后,而后者试图通过尽可能的纯函数功能将状态切分再细直至最小化。(banq:两者侧重点还是不太一样)

大多数习惯于面向对象程序员喜欢将在OO基础上引入FP,但是作者认为:可能丧失一些纯函数式语言的独特特点,纯函数式语言更加易于调试,能够并行执行,这取决于他们没有副作用(side effects)

以下是我理解:因为将行为封装在对象中的方式带来最大问题就是行为功能的副作用,也就是某个对象的方法执行其主要功能作用外,必然带来其副作用,需要程序员非常小心应付,经常不经意就带来副作用,这样编程就很累,相反,如果我们直接从方法功能入手,就自然避免副作用,打个比喻:某个老板A手下有一个人才B很能干,可以独当一面,如果B一直位于A封装边界内,A可能让其偶尔做一些其不擅长的时间,这就是B的副作用;而如果让B独立新公司,完全放手,则对其没有牵制,也就没有副作用。

该文提出:100%纯函数式是否需要?James Hague认为不需要,只要85%就可以,权衡利弊,左右取之于中,提出functional in the small and OO in the large观点,我个人理解就是:在宏观战略Large方面使用面向对象;而在战术small方面使用函数式编程。

由于函数式编程在外观上类似以前面向过程编程中函数,所以,这个帖子也可以看成面向对象和面向过程分裂之后的再次组合的一个方式。

                   

3
SpeedVan
2010-11-05 15:55

那么scala等一系列语言出现,正好印证这一方向?

weidagang2046
2010-11-05 16:48

>>因为将行为封装在对象中的方式带来最大问题就是行为功能的副作用,也就是某个对象的方法执行其主要功能作用外,必然带来其副作用

“副作用”的意思不是意料之外的行为,而是函数或方法的执行会改变程序的状态。比如:person.getAge()是无副作用的,因为它不改变程序的状态,因而没有并发、多线程等问题。

uda1341
2010-11-05 18:56

面向对象和函数式编程不是百分之几按照比例分配的问题,是如何结合的问题。CLOS在这方面应该算是做得相当不错的了。对副作用的处理方式,haskell的IO monad也是一个很好的解决方法。

按照我现在的想法,面向对象的概念需要由函数式语言给出形式描述,而不是人为规定,这才是正确的方法,就像CLOS里面做的那样。

SpeedVan
2010-11-06 02:39

百分比只是形象说法而已,只是说明以后对象行为的实现可能会大量用FP实现而已,而宏观上则采用OO的而已。(难道JDK7正预示未来,嘛,没所谓,工具而已)

在我之前看到的文章里,也有介绍过OO中设计模式本来就跟函数式思维相似,而他们其实是相通的。为啥C++能写出OO风格,OO能写出函数式风格,也就这个道理。不过也因为动静差异,造就很多不同的地方。(个人感觉而已,引用文章:http://blog.csdn.net/shendl/archive/2008/01/24/2064218.aspx)

[该贴被SpeedVan于2010-11-06 02:40修改过]

3Go 1 2 3 下一页