avatar
oop还是跟fp是对立的# Programming - 葵花宝典
k*7
1
长期提供审稿推荐机会:生物/医学统计 方向期刊
请感兴趣的同学站内给我发信提供你的
1 姓名
2 EMAIL (institutional or professional email preferred)
3 个人主页链接(最好包含publication list信息)
只需要这些信息就可以,不需要CV等其他的信息
如果合适我会向杂志编辑推荐。祝好运!
avatar
d*o
2
【 以下文字转载自 PhotoGear 讨论区 】
发信人: duobo (绿绿绿绿绿绿), 信区: PhotoGear
标 题: 请问有在nyc/nj的朋友吗?
发信站: BBS 未名空间站 (Sun Sep 7 11:04:38 2014, 美东)
想给宝宝拍片。有没有便宜一点的摄影师?谢谢!
avatar
z*e
3
fp为了保证func的复用,尽量抹杀object的存在
因为class/object这种东西是特殊的数据结构
会导致func跟这种特殊的结构绑定
就很难复用,比如go(USACity la)和go(ChineseCity gz)
是不一样的,因为参数的结构不一样,这就限制了其复用
所以最后fp为了能够重用,写的func参数都是map, list,sring,int这些
而map&list注定对于一个object描述的力度是有限的
限制少木有错,但是就容易包含有各种错误等等
所以为了让func独立出去,稳定其1st class的地位
注定要削弱class/object的存在感
而oop则反过来,提倡并鼓励使用class/object
像java这种,则强迫func寄托在object下面
虽然你也可以定义全局的Util,但是毕竟static方法是很少滴
object才是1st class的地位,这样做的好处就是
不依赖func,而依赖每个object自身
每个class自己有啥问题,自己搞定,当然会有各种搞不定
搞不定没关系,异常catch住,然后收拾掉就好
不要影响其他object就行,当然这样做的结果就是
如果object无法重用,则下面的func都无法重用
所以要重用的话,必需先让object有办法重用起来
当然这么看,也可以说这两个不冲突
把fp想成是制作一堆巨大的static方法
其他的oop该怎么做还是怎么做
不过一般而言,static部分是可以托管的
spring就是其中一种托管办法,顺手抄个轮子就好了
没有必要自己去折腾,也木有时间,自己写还要维护,麻烦
所以用scala写类库,定义dsl,然后包装成jars丢出去
其他人用java就可以直接调用这些jars,是非常合理的
能解释为啥spark等用scala写
avatar
k*7
4
长期提供审稿推荐机会:生物/医学统计 方向期刊
请感兴趣的同学站内给我发信提供你的
1 姓名
2 EMAIL (institutional or professional email preferred)
3 个人主页链接(最好包含publication list信息)
只需要这些信息就可以,不需要CV等其他的信息
如果合适我会向杂志编辑推荐。祝好运!
avatar
l*g
5
一般要300吧。这位同好的,你可以参考下~~~
http://jing.photography/?page_id=32
我给别人拍了一次,结果新妈不太满意。过后我蛮内疚的。
经验,构思,技术是100跟300得差距。所以,想好看点,就想办法怎么再凑齐剩下的
200吧。加油,加油。
avatar
N*n
6
W/ generic OOP is able to decouple funcs from classes already. If it's
needed it's there. OOP funcs don't have to be bound to a class.
It just has to be a real generic like that of C#, rather than type
erasure garbage JAVA does.

【在 z****e 的大作中提到】
: fp为了保证func的复用,尽量抹杀object的存在
: 因为class/object这种东西是特殊的数据结构
: 会导致func跟这种特殊的结构绑定
: 就很难复用,比如go(USACity la)和go(ChineseCity gz)
: 是不一样的,因为参数的结构不一样,这就限制了其复用
: 所以最后fp为了能够重用,写的func参数都是map, list,sring,int这些
: 而map&list注定对于一个object描述的力度是有限的
: 限制少木有错,但是就容易包含有各种错误等等
: 所以为了让func独立出去,稳定其1st class的地位
: 注定要削弱class/object的存在感

avatar
k*7
7
长期提供审稿推荐机会:生物/医学统计 方向期刊
请感兴趣的同学站内给我发信提供你的
1 姓名
2 EMAIL (institutional or professional email preferred)
3 个人主页链接(最好包含publication list信息)
只需要这些信息就可以,不需要CV等其他的信息
如果合适我会向杂志编辑推荐。祝好运!
avatar
c*o
8
everything in Scala is a Object, and Scala can be pure FP.
avatar
z*e
9
那不行,我没有办法跟m$ couple起来
钱很重要,不能两个人分,要不然不用开源了
这个也要decoupling

【在 N********n 的大作中提到】
: W/ generic OOP is able to decouple funcs from classes already. If it's
: needed it's there. OOP funcs don't have to be bound to a class.
: It just has to be a real generic like that of C#, rather than type
: erasure garbage JAVA does.

avatar
z*e
10
那这个object太general了
没啥用,也就做点clone,hashcode,equals这些

【在 c******o 的大作中提到】
: everything in Scala is a Object, and Scala can be pure FP.
avatar
c*o
11
the good about OO is its encapsulation, the bad of OO is the dynamic part (
including inheritance, polymorphism etc.)
For internal state, if you want to use it in parallel/distributed env, you
will have to make it explicit to outside, or just make it immutable anyway.

【在 z****e 的大作中提到】
: 那这个object太general了
: 没啥用,也就做点clone,hashcode,equals这些

avatar
b*g
12
Indeed for complicate concurrency system, FP is better. But concurrency is
way overrated. 99% of web apps are some sort of CRUD and no synchronization
is necessary, or contention can only happen in DB. Even for the 1%, it's
probably one or a few micro services in infrastructure that really needs it.

【在 c******o 的大作中提到】
: the good about OO is its encapsulation, the bad of OO is the dynamic part (
: including inheritance, polymorphism etc.)
: For internal state, if you want to use it in parallel/distributed env, you
: will have to make it explicit to outside, or just make it immutable anyway.

avatar
z*e
13
就是get方法嘛
fp纯粹的异步也有问题
很多环境需要同步
哪怕是一个棋牌乐,一局也需要你同步
一般的website还是偏简单了

【在 c******o 的大作中提到】
: the good about OO is its encapsulation, the bad of OO is the dynamic part (
: including inheritance, polymorphism etc.)
: For internal state, if you want to use it in parallel/distributed env, you
: will have to make it explicit to outside, or just make it immutable anyway.

avatar
a*e
14
你这个理解有点片面。
首先,go(USACity la)和go(ChineseCity gz) 这种,至少在 Haskell 和 Scala 里完
全不是问题,因为有 typeclass 可以做 type-based dispatch,这叫做 ad-hoc
polymorphism。我相信你的原意是说 parametric polymorphism 和 OOP 有冲突,但这
不是 FP 和 OOP 有冲突的原因。而且 OOP 里面也可以毫无偏差地实现 parametric
polymorphism,所以针对 parametric polymorphism,FP 和 OOP 没有冲突。
FP 和 OOP 真正不同的地方在于:
在 FP 里面,type is closed,function is extensible (to handling more types).
在 OOP 里面,function is closed,type is extensible (to have more functions
)。
也就是说 OOP 是 extend objects,而 FP 是 extend functions (也即 ad-hoc
polymorphism)。其实两者并无绝对的冲突,也可以共容(见 OCaml 和 Scala),不同
的概念适用不同的场合而已。
实际使用中,反而是对 mutability 的态度上分歧比较大。但这和是否 FP 或 OOP 其
实没有关系。
另外一个比较宽泛的问题是关于谁更 modular 的争论,但是 Haskell typeclass 本身
也有这方面的问题,一直被 SML 的死忠派诟病,也就不多说了。

【在 z****e 的大作中提到】
: fp为了保证func的复用,尽量抹杀object的存在
: 因为class/object这种东西是特殊的数据结构
: 会导致func跟这种特殊的结构绑定
: 就很难复用,比如go(USACity la)和go(ChineseCity gz)
: 是不一样的,因为参数的结构不一样,这就限制了其复用
: 所以最后fp为了能够重用,写的func参数都是map, list,sring,int这些
: 而map&list注定对于一个object描述的力度是有限的
: 限制少木有错,但是就容易包含有各种错误等等
: 所以为了让func独立出去,稳定其1st class的地位
: 注定要削弱class/object的存在感

avatar
z*e
15
dispatch显然是错误的
随着class的数量上升
你这个dispatch会拼命增加
每增加一个,你就需要回去修改源代码
把你累死,最后还不如干脆就map,list算了
说到底就是不需要修改源代码的基础之上增加class是最优的
所以fp在这一块是非常非常受限
scala本身之所以不愿意抛弃oop也是出于这个考虑
任何switch, dispatch, if else这些都属于不合适的
最理想的就是想加就加,想拆就拆,而不用改动其他部分代码

).
functions

【在 a*****e 的大作中提到】
: 你这个理解有点片面。
: 首先,go(USACity la)和go(ChineseCity gz) 这种,至少在 Haskell 和 Scala 里完
: 全不是问题,因为有 typeclass 可以做 type-based dispatch,这叫做 ad-hoc
: polymorphism。我相信你的原意是说 parametric polymorphism 和 OOP 有冲突,但这
: 不是 FP 和 OOP 有冲突的原因。而且 OOP 里面也可以毫无偏差地实现 parametric
: polymorphism,所以针对 parametric polymorphism,FP 和 OOP 没有冲突。
: FP 和 OOP 真正不同的地方在于:
: 在 FP 里面,type is closed,function is extensible (to handling more types).
: 在 OOP 里面,function is closed,type is extensible (to have more functions
: )。

avatar
z*e
16
polymorphism只是一个折中的方案
在任何时候polymorphism都会随着规模的增加而线性增加
最后当项目大了之后,polymorphism这部分代码会变得很大很粗
不管是oop还是fp,都应该想办法避免polymorphism
所以你说可以做到polymorphism,没啥,应该想办法避开polymorphism
我觉得那次谁说的
oop和fp的区别仅仅是在于看你的封装是在object级别还是func级别
那句话是至理名言,oop和fp还是有冲突的部分的
因为object和func只要存在,就会互相影响

).
functions

【在 a*****e 的大作中提到】
: 你这个理解有点片面。
: 首先,go(USACity la)和go(ChineseCity gz) 这种,至少在 Haskell 和 Scala 里完
: 全不是问题,因为有 typeclass 可以做 type-based dispatch,这叫做 ad-hoc
: polymorphism。我相信你的原意是说 parametric polymorphism 和 OOP 有冲突,但这
: 不是 FP 和 OOP 有冲突的原因。而且 OOP 里面也可以毫无偏差地实现 parametric
: polymorphism,所以针对 parametric polymorphism,FP 和 OOP 没有冲突。
: FP 和 OOP 真正不同的地方在于:
: 在 FP 里面,type is closed,function is extensible (to handling more types).
: 在 OOP 里面,function is closed,type is extensible (to have more functions
: )。

avatar
a*e
17
你没搞明白 haskell typeclass 的语义和实现,这不怪你。增加新 typeclass
instance 不需要回去改代码,和 OO 里面的 class/object 的 method dispatch 实现
区别不大。

【在 z****e 的大作中提到】
: dispatch显然是错误的
: 随着class的数量上升
: 你这个dispatch会拼命增加
: 每增加一个,你就需要回去修改源代码
: 把你累死,最后还不如干脆就map,list算了
: 说到底就是不需要修改源代码的基础之上增加class是最优的
: 所以fp在这一块是非常非常受限
: scala本身之所以不愿意抛弃oop也是出于这个考虑
: 任何switch, dispatch, if else这些都属于不合适的
: 最理想的就是想加就加,想拆就拆,而不用改动其他部分代码

avatar
z*e
18
那你给个例子看看
给zkss?

【在 a*****e 的大作中提到】
: 你没搞明白 haskell typeclass 的语义和实现,这不怪你。增加新 typeclass
: instance 不需要回去改代码,和 OO 里面的 class/object 的 method dispatch 实现
: 区别不大。

avatar
z*e
19
你想说的是parametric polymorphism吧
也就是通过不同类型的class塞入方法参数,从而调用不同的方法吧?
这个还是需要通过源代码来修改
无论你怎么写,这个go方法你还是需要增加一部分新代码来配合你新增的那个class
随着class的增加,你的这个go方法会越发地膨胀
所以最后你会发现,还不如干脆全部map和list掉算了
为什么fp经常被用来做数据处理呢?
因为数据处理的class很少,几乎都是数字,不需要怎么描述性质的东西
比较容易搞,你要是不信,我们具体例子具体分析
从例子来说

【在 a*****e 的大作中提到】
: 你没搞明白 haskell typeclass 的语义和实现,这不怪你。增加新 typeclass
: instance 不需要回去改代码,和 OO 里面的 class/object 的 method dispatch 实现
: 区别不大。

avatar
a*e
20
纠正一下你的概念,parametric polymorphism 是指将 type 作为参数,通常理解为
forall 就可以了。
type class 是 ad-hoc polymorphism,是在 parametric 的基础上加上类型类(
typeclass)的限制,简单理解可以是把 typeclass 当作是 java class,类型的
instance 定义当作是 java sub-class 定义。都说了,和 java class 实现差别不大
,如果你认为差别很大,请举个具体例子。

【在 z****e 的大作中提到】
: 你想说的是parametric polymorphism吧
: 也就是通过不同类型的class塞入方法参数,从而调用不同的方法吧?
: 这个还是需要通过源代码来修改
: 无论你怎么写,这个go方法你还是需要增加一部分新代码来配合你新增的那个class
: 随着class的增加,你的这个go方法会越发地膨胀
: 所以最后你会发现,还不如干脆全部map和list掉算了
: 为什么fp经常被用来做数据处理呢?
: 因为数据处理的class很少,几乎都是数字,不需要怎么描述性质的东西
: 比较容易搞,你要是不信,我们具体例子具体分析
: 从例子来说

avatar
z*e
21
最简单例子,就不说场景
func1(Object1 obj1)
func2(Object2 obj2)
你觉得这两个是不是func1&obj1, func2&obj2两个紧密耦合了起来?
对比
obj1.func1
obj2.func2
其实是一回事
因为任何改动obj1的地方都会牵涉func1的改动
对吧?
对比
func1(Map map1)
func2(Map map2)
是不是就要更为松散呢?
这个时候你叠加func1&func2就很容易
当然一般这么理想是比较难做到的
多数时候还是这样
func1(Object obj)
func2(Object obj)
因为obj不变,所以func1(func2(obj))的叠加就很容易
但是如果obj在func1&func2中是不一样的
就变成紧耦合了,func和obj无法分离
所以fp不适合做这种一堆对象的场景,如果都是information
也就是map&list,就很容易了
沙发就在说这个,你回的一大通,我还以为你知道我在说啥呢

【在 a*****e 的大作中提到】
: 纠正一下你的概念,parametric polymorphism 是指将 type 作为参数,通常理解为
: forall 就可以了。
: type class 是 ad-hoc polymorphism,是在 parametric 的基础上加上类型类(
: typeclass)的限制,简单理解可以是把 typeclass 当作是 java class,类型的
: instance 定义当作是 java sub-class 定义。都说了,和 java class 实现差别不大
: ,如果你认为差别很大,请举个具体例子。

avatar
a*e
22
我觉得你要说的是:
func1(Object obj)
func2(Object obj)
这种写法,你在 func1 和 func2 的 body 里面只知道对象是 Object,从而不能谈论
更多。
换成 OO 的方式, obj->func1() obj->func2(),只需要知道 Object class 里面有
func1 和 func2 两个成员函数,而不需要知道 obj 具体是 Object class 还是它的
sub class。通过 sub class 来 overload method 可以实现更多功能。
这是你的意思,对不对?
这种 OO 里面的做法换成用 Haskell:
class ObjectClass a where
func1 :: a -> ...
func2 :: a -> ...
type ObjectType1 = ...
type ObjectType2 = ...
instance ObjectClass ObjectType1 where
func1 = ...
func2 = ...
instance ObjectClass ObjectType2 where
func1 = ...
func2 = ...
obj1 :: ObjectType1
obj1 = ...
obj2 :: ObjectType1
obj2 = ...
main = ... func1(obj1) ... func2(obj2) ..
没有任何问题,和你上面 OO 的做法几乎是一样的,这里定义 ObjectType1 和
ObjectType2 的关于 ObjectClass 的 instance,就对应了 java 里面的 sub class。
Haskell typeclass 比 java class 要灵活多了,可以定义 ObjectType1 属于
ObjectClass 也可以定义 ObjectType1 属于 OtherClass,这类似 multi inheritance
。还可以定义 multi parameter type class,用多个 type 组合起来定义一个
instance,可以用来表达多个 type 之间的规则。

【在 z****e 的大作中提到】
: 最简单例子,就不说场景
: func1(Object1 obj1)
: func2(Object2 obj2)
: 你觉得这两个是不是func1&obj1, func2&obj2两个紧密耦合了起来?
: 对比
: obj1.func1
: obj2.func2
: 其实是一回事
: 因为任何改动obj1的地方都会牵涉func1的改动
: 对吧?

avatar
z*e
23
不是
我的意思是在这个时候,fp应该能够体现出比oop更为高效的地方才对
比如
func1(MyObject obj)
func2(MyObject obj)
func3(MyObject obj)
func4(MyObject obj)
func5(MyObject obj)
func6(MyObject obj)
...
这个时候,因为MyObject结构都是一样的
所以就很容易叠加各种函数
以及对函数做归类,整理,都很容易
但是如果这个时候MyObject的结构改变了
那你就得对这一通函数一顿改
麻烦死你,而且最痛苦的是
这些func可能放在不同的地方,那找起来就麻烦了
所以要控制数据结构数量
最好都是map&list,这样基本上没啥好改的
如果是oop
那是这样
MyObj1.func1
MyObj1.func2
MyObj2.func2
MyObj3.func3
...
本身func不是1st class,所以从属于object
而改动其中一个obj,不会影响到其他obj,所以加减obj就很容易
也很自然,你要改其中任何一个obj的结构也相对容易
尤其是如果这个obj的方法只负责处理自身属性的时候
那改动其中一个结构,几乎不会有太大的改动
是很容易的一件事
func和obj是多对多关联
看你用哪个作为标准整理了

【在 a*****e 的大作中提到】
: 我觉得你要说的是:
: func1(Object obj)
: func2(Object obj)
: 这种写法,你在 func1 和 func2 的 body 里面只知道对象是 Object,从而不能谈论
: 更多。
: 换成 OO 的方式, obj->func1() obj->func2(),只需要知道 Object class 里面有
: func1 和 func2 两个成员函数,而不需要知道 obj 具体是 Object class 还是它的
: sub class。通过 sub class 来 overload method 可以实现更多功能。
: 这是你的意思,对不对?
: 这种 OO 里面的做法换成用 Haskell:

avatar
T*x
24
这个有道理。

【在 z****e 的大作中提到】
: fp为了保证func的复用,尽量抹杀object的存在
: 因为class/object这种东西是特殊的数据结构
: 会导致func跟这种特殊的结构绑定
: 就很难复用,比如go(USACity la)和go(ChineseCity gz)
: 是不一样的,因为参数的结构不一样,这就限制了其复用
: 所以最后fp为了能够重用,写的func参数都是map, list,sring,int这些
: 而map&list注定对于一个object描述的力度是有限的
: 限制少木有错,但是就容易包含有各种错误等等
: 所以为了让func独立出去,稳定其1st class的地位
: 注定要削弱class/object的存在感

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。