12
返回列表 发新帖
楼主: techDiscussion
跳转到指定楼层
上一主题 下一主题
收起左侧

functional programming 和 object oriented 概念真的要分开吗?

🔗
lalxyy 2020-11-19 07:05:20 | 只看该作者
全局:
本帖最后由 lalxyy 于 2020-11-18 18:10 编辑

个人感觉FP和OOP都属于指导代码实现方式的设计思想,二者本身并不互斥,也没有 “重复性” 一说。因为implementation的目标是最终交付代码,并不在于严格使用某种编程思想才能达到这一目的,Java等等语言的syntax也是博采众长,利用各种编程思想的优势对自身进行补充,而非死守OOP不放(尤其是Java 8引入的stream API,是一个很好的例子)。

OOP的概念对于抽象代码各个部分的功能分配和代码复用是非常有用的。OOP的三个原则中,继承这一原则为思考代码针对某一功能(比如子类)的公共部分和私有部分切割提供了很好的切入点,即将各个代码块的共有逻辑置于父类中,把各个模块的私有逻辑置于子类中。固然这样做有很多缺点(尤其是私有逻辑和共有逻辑频繁相互call的时候,这种代码很难写得易于维护;Java长期不支持多继承,导致一些代码复用做不到,在Java 8 Interface开始才能提供抽象方法的默认实现)。多态则是为low coupling提供了可行性,即各部分逻辑之间的调用可以力求做到parameter最小化,只需要传入的object提供本部分代码所需要的方法实现即可,这一条对于实现模块间low coupling有一定帮助。

FP背后的思想其实是非常优秀的,单是执行过程中不可变参数(determinism)这一特性足以规避开发过程中很多由于思路不清晰、忘记在哪里动了已定义的变量导致的bug。而且从Lisp等一些语言来讲,FP的函数因为不需要和外部变量交互,实现并行多进程/多线程/coroutine简直轻而易举,不需要考虑任何资源竞争/锁的问题。在一些对于这两点有很强需求的业务场景中,比如data pipeline,这些思想非常实用。而且FP这种 “把函数当成对象” 的思维在21世纪初是非常超前的,在2011-15年之后主流语言和新语言才引入这些特性(Swift的Closure,Java的单一方法Interface,Python的单行lambda,C++11的lambda)并且让链式处理成为了可能。

其实我更看好能够在各个设计思想中博采众长、给予开发者最大自由度的语言。目前Java、Python等语言都在博采众长。软件开发工作的最终目的是交付,而对于具体实施过程而言,完全不必要如此刻板,甚至从互斥的角度去考虑问题。学习优秀的编程思想应该是帮助开发者解决system design问题的钥匙,而不是画地为牢死死抱住某种design不放。

评分

参与人数 3大米 +5 收起 理由
ripxd + 2 给你点个赞!
clairefig + 2 你为什么可以发语音?
CommieCoyote + 1 赞一个

查看全部评分

回复

使用道具 举报

🔗
ChantToGreen 2020-11-19 07:08:35 | 只看该作者
全局:
fp更接近计算的本质
回复

使用道具 举报

🔗
uuisafresh 2020-11-19 08:34:53 | 只看该作者
全局:
我的理解,在Python里面你是可以局部fp的,但那无非是吧function当做对象,本质依然还是oop。在haskell,所有东西都是function,模式匹配,你的思考模式从oop的一行一行变成了吧问题拆分成递归,拆分成了最小表达式和一个很长的pipe,而每一个表达式你都必须在写的时候知道他的signature,所有参数的类型,就是args->output。同时object不再是封装用,而是模式匹配使用。在oop里面一个object可以是member(data/function)的封装,在haskell里面object是类型,是数据的包裹,是function模式匹配用的,object没有行为,只有数据和长度。拆分成独立更小的function对于unittest是很方便的,但是一旦整体出错,纠错可能会很绕。同时懂的人会很懂,不懂得人要花一段时间上手。实际上很多oop语言都提供了局部fp的支持,这给某些适合递归解决的问题提供方便,比如写parser,状态转移。
回复

使用道具 举报

🔗
Pizi-G 2020-11-19 12:58:15 | 只看该作者
全局:
我觉得 oo 和 functional 是从两个角度描述代码 (参考 https://en.wikipedia.org/wiki/Li ... g_languages_by_type)

oo 是结构是什么样的, 与其相对可以是 composition programming.
functional 是具体执行命令的时候有什么特性.

举个简化的例子, oo 里的 method  的具体操作, 可以是 pure functional, 也可以不是 functional. 同样 functional 的 code 可以存在于 oo 里, 也可以完全就如简单的 add(a, b) {return a + b} 就是.
回复

使用道具 举报

🔗
q3409tujgreia 2020-11-19 14:43:07 | 只看该作者
全局:
functor, applicative, monad这种概念是functional programming里独有的
回复

使用道具 举报

全局:
techDiscussion 发表于 2020-11-17 23:11:15
可以解释下您对fp的思维模式吗?
fp和oo的区别大佬们都讲了,我一个小透明不敢班门弄斧。之所以说我更喜欢fp是因为我入门的语言是c++,但在接触到OCaml和Haskell之后因为各种原因几乎没有再用过oo。我单纯喜欢fp的everything is function的思维逻辑,包括pattern match,recursion等。相比于oo我感觉fp的逻辑更严谨和条理更清晰,可读性更强(仅个人观点,我在oo上的经验非常少,这也可能是我为什么觉得oo难读,毕竟入门之后几乎没再用过,而且身边不同意我这个观点的朋友大有人在)但我觉得最重要的还是oo和fp各有各擅长的场景,在不同情况下善用才能发挥他们各自的优势。比方说写graphic作业的时候,oo真香
回复

使用道具 举报

🔗
clairefig 2020-11-23 20:49:44 | 只看该作者
全局:
lalxyy 发表于 2020-11-19 07:05
个人感觉FP和OOP都属于指导代码实现方式的设计思想,二者本身并不互斥,也没有 “重复 ...
你为什么可以发语音?
回复

使用道具 举报

🔗
cynthiameowmeow 2020-12-18 07:02:36 | 只看该作者
全局:
lalxyy 发表于 2020-11-19 07:05
个人感觉FP和OOP都属于指导代码实现方式的设计思想,二者本身并不互斥,也没有 “重复性” 一说。因为imple ...
FP这种 “把函数当成对象” 的思维在21世纪初是非常超前的

这。。。Lisp/Lisp Machine不高兴了啊...
回复

使用道具 举报

🔗
lalxyy 2020-12-18 07:26:49 | 只看该作者
全局:
cynthiameowmeow 发表于 2020-12-17 18:02
这。。。Lisp/Lisp Machine不高兴了啊...

哈哈我的观点的出发点都是从工业界经常使用的技术栈的角度出发的,很geek的技术栈没有考虑进去。21世纪初的桌面应用和网站还没有大规模引入FP的概念,那个年代网站领域Java EE还大行其道,还没有单独的前端工种,桌面应用也是VC++/Win32/Qt的天下。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册账号
隐私提醒:
  • ☑ 禁止发布广告,拉群,贴个人联系方式:找人请去🔗同学同事飞友,拉群请去🔗拉群结伴,广告请去🔗跳蚤市场,和 🔗租房广告|找室友
  • ☑ 论坛内容在发帖 30 分钟内可以编辑,过后则不能删帖。为防止被骚扰甚至人肉,不要公开留微信等联系方式,如有需求请以论坛私信方式发送。
  • ☑ 干货版块可免费使用 🔗超级匿名:面经(美国面经、中国面经、数科面经、PM面经),抖包袱(美国、中国)和录取汇报、定位选校版
  • ☑ 查阅全站 🔗各种匿名方法

本版积分规则

>
快速回复 返回顶部 返回列表