N******K
发帖数: 10202 | 1 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试 |
a****e
发帖数: 9589 | 2 其实这个问题一直困扰着叔20年，遗产税税率那么高，继承有屌用
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
|
g*****g
发帖数: 34805 | 3 LOL，你的代码都是跑完就扔的，当然是好办法。
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
|
r***y
发帖数: 4379 | |
r***y
发帖数: 4379 | 5 登录了一下, 让goodbug 抢先了30s... |
r***s
发帖数: 737 | 6 have you ever heard of code clone and the problems associated with it?
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
|
w******w
发帖数: 126 | 7 Never use inheritance if you can. keep using has a instead of is a. lol |
b*******s
发帖数: 5216 | 8 一定程度上你是对的，继承是一种强耦合关系，层次一多特性一多维护并不省事。而派
生类一旦复杂，基类作为接口的本意也模糊了。
多继承太复杂，很难用，同理
想想aws要是大量用oo继承来实现会是什么样的灾难
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
|
g*****y
发帖数: 7271 | 9 Out of all the issues, I hate copy/paste (code duplication) the most.
Maybe you did not see how copy/paste can be abused?
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
|
N******K
发帖数: 10202 | 10 我设计图像滤波器类 用了很多继承 因为我很清楚各个类是干啥的
但是设计一些新的类 用于实现探索性质的算法 经常要大改 搞继承 是自找麻烦
当算法比较成熟后 可以把各个类合并一下
当然 公司里的项目 很少是探索性质 一开始就知道怎么搞 和我说的不是一回事
【在 b*******s 的大作中提到】
: 一定程度上你是对的，继承是一种强耦合关系，层次一多特性一多维护并不省事。而派
: 生类一旦复杂，基类作为接口的本意也模糊了。
: 多继承太复杂，很难用，同理
: 想想aws要是大量用oo继承来实现会是什么样的灾难
|
|
|
w******w
发帖数: 126 | 11 多重继承太evil 了。 这个就是为啥java 用implement 多个 interface 来代替多重继
承了。 继承就是个贼船，上去了就下不来了。 比较恶心，就我个人观点看来OO 核心
就是封装。多态，继承都是扯。哪里有变化哪里就有封装！ 如果实在喜欢继承的话，
能保证以后需求的一定时间不改变的话，也可以用继承。否则的话，尽量少用继承，继
承耦合度太紧 太紧了。到了后来你会有牵一发而动全身的痛苦的！ 我记得用functor
还有 boost 的那个bind 啥的 在大部分情况下我们可以组合自己的functionality 而
不用继承。不用继承的话，那么那些design pattern 貌似也木有啥大用场了。 本来那
些design pattern的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
有点花架子的感觉！ ^_^ |
l******t
发帖数: 55733 | |
k****i
发帖数: 1072 | 13 composition over inheritance; DI
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
|
b*******s
发帖数: 5216 | 14 bind is now a bit of stl :)
love it
functor
【在 w******w 的大作中提到】
: 多重继承太evil 了。 这个就是为啥java 用implement 多个 interface 来代替多重继
: 承了。 继承就是个贼船，上去了就下不来了。 比较恶心，就我个人观点看来OO 核心
: 就是封装。多态，继承都是扯。哪里有变化哪里就有封装！ 如果实在喜欢继承的话，
: 能保证以后需求的一定时间不改变的话，也可以用继承。否则的话，尽量少用继承，继
: 承耦合度太紧 太紧了。到了后来你会有牵一发而动全身的痛苦的！ 我记得用functor
: 还有 boost 的那个bind 啥的 在大部分情况下我们可以组合自己的functionality 而
: 不用继承。不用继承的话，那么那些design pattern 貌似也木有啥大用场了。 本来那
: 些design pattern的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
: 有点花架子的感觉！ ^_^
|
l*********s
发帖数: 5409 | 15 OO很好呀，可以正大光明的把复杂的问题搞的加倍复杂，提高马工岗位安全性 |
d*******r
发帖数: 3299 | 16 "就我个人观点看来OO 核心就是封装。多态，继承都是扯"
那 C 的 structure, JS 的 JSON 也有封装了，只是没有 public/private 强制控制
access 的权限.
functor
【在 w******w 的大作中提到】
: 多重继承太evil 了。 这个就是为啥java 用implement 多个 interface 来代替多重继
: 承了。 继承就是个贼船，上去了就下不来了。 比较恶心，就我个人观点看来OO 核心
: 就是封装。多态，继承都是扯。哪里有变化哪里就有封装！ 如果实在喜欢继承的话，
: 能保证以后需求的一定时间不改变的话，也可以用继承。否则的话，尽量少用继承，继
: 承耦合度太紧 太紧了。到了后来你会有牵一发而动全身的痛苦的！ 我记得用functor
: 还有 boost 的那个bind 啥的 在大部分情况下我们可以组合自己的functionality 而
: 不用继承。不用继承的话，那么那些design pattern 貌似也木有啥大用场了。 本来那
: 些design pattern的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
: 有点花架子的感觉！ ^_^
|
w******w
发帖数: 126 | 17 你说对了， 向伟大的C语言致敬！至于 JS 咱木有写过不好发表意见！
C++ 在某些特殊场合根本不用，还就是C语言呢。 就那个exception 你就不可控。有的
场合确实不敢用OO的语言， C 清晰可控！ ^_^
【在 d*******r 的大作中提到】
: "就我个人观点看来OO 核心就是封装。多态，继承都是扯"
: 那 C 的 structure, JS 的 JSON 也有封装了，只是没有 public/private 强制控制
: access 的权限.
:
: functor
|
g*****g
发帖数: 34805 | 18 OO里，Java的那套才是王道。interface+ DI, 没啥不能解决的。Spring Security是很
经典的一个框架，继承很复杂，代码很精炼。 |
M*P
发帖数: 6456 | 19 copypaste其实对data science很有用。
★ 发自iPhone App: ChineseWeb 7.8
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
|
w***x
发帖数: 105 | 20 继承本质上就是线性关系的表达，但现实中很多是图的结构，非用linear模拟graph，
实际上是很糟糕的思想。 |
|
|
b*******s
发帖数: 5216 | 21 OO is only good for scenarios require huge amt of interactions
【在 g*****g 的大作中提到】
: OO里，Java的那套才是王道。interface+ DI, 没啥不能解决的。Spring Security是很
: 经典的一个框架，继承很复杂，代码很精炼。
|
d*******r
发帖数: 3299 | 22 我懂你说那种 C style, Linux kernel 里很多
其实我用 JS/Node.js 差不多也是这么用的，有时确实不想写严谨的 OOP
【在 w******w 的大作中提到】
: 你说对了， 向伟大的C语言致敬！至于 JS 咱木有写过不好发表意见！
: C++ 在某些特殊场合根本不用，还就是C语言呢。 就那个exception 你就不可控。有的
: 场合确实不敢用OO的语言， C 清晰可控！ ^_^
|
d*******r
发帖数: 3299 | 23 大牛说说 Java 里 interface+ DI 需要用很多继承吗?
只用过其他语言里的 DI, 感觉这个 pattern 跟继承就不是一个路数的呀
【在 g*****g 的大作中提到】
: OO里，Java的那套才是王道。interface+ DI, 没啥不能解决的。Spring Security是很
: 经典的一个框架，继承很复杂，代码很精炼。
|
d*******r
发帖数: 3299 | 24 我同意这个. 总感觉继承的描述能力很有限.
线性依赖/复用下来，像是个 tree; 但是现实世界的依赖关系，更像个 graph.
所以我一般更爱用组合, 如果一定要 OOP 的话.
【在 w***x 的大作中提到】
: 继承本质上就是线性关系的表达，但现实中很多是图的结构，非用linear模拟graph，
: 实际上是很糟糕的思想。
|
D***n
发帖数: 6804 | 25 所以Objective-C里面的Protocol/Delegate/Catagory 三者组合起来是个更优秀的解决
方案。可以在运行时动态绑定继承的对象。
【在 d*******r 的大作中提到】
: 我同意这个. 总感觉继承的描述能力很有限.
: 线性依赖/复用下来，像是个 tree; 但是现实世界的依赖关系，更像个 graph.
: 所以我一般更爱用组合, 如果一定要 OOP 的话.
|
g*****g
发帖数: 34805 | 26 这两者是独立的，要不要继承还是那个is-a的问题。DI的好处是把dependency graph简
化，从而减少了很多纯粹为了传递产生的耦合。
composition over inheritance带来一定的灵活性，但同时boiler plate代码也多一些
。所以具体问题具体分析，如果继承关系勉强，只是为了复用方法，显然应该用
composition.
【在 d*******r 的大作中提到】
: 大牛说说 Java 里 interface+ DI 需要用很多继承吗?
: 只用过其他语言里的 DI, 感觉这个 pattern 跟继承就不是一个路数的呀
|
d*******r
发帖数: 3299 | 27 知道了，多谢
【在 g*****g 的大作中提到】
: 这两者是独立的，要不要继承还是那个is-a的问题。DI的好处是把dependency graph简
: 化，从而减少了很多纯粹为了传递产生的耦合。
: composition over inheritance带来一定的灵活性，但同时boiler plate代码也多一些
: 。所以具体问题具体分析，如果继承关系勉强，只是为了复用方法，显然应该用
: composition.
|
k**********g
发帖数: 989 | 28 上面神马解释都有大牛反覆说明了。大牛们用的语言当然是高大上的洋文。
https://isocpp.org/wiki/faq/multiple-inheritance
My summary:
(1) in C++, abstract base class is the equivalent of interface in other OOP
languages.
(2) If you must use multiple inheritance and some sibling classes are non-
abstract, try to keep the join class (most-derived class) as simple as
possible. (This is in addition to writing the sibling classes and join class
correctly, which is the main theme of that FAQ.) If you don't want to deal
with the trickiness of non-abstract multiple inheritance, then use
composition instead.
澄清，我用的是佯文，不是洋文。 |
k**********g
发帖数: 989 | 29
我也是做图像处理的。
个人认为，图像处理是适合用『functional decomposition』的特殊场合，是pattern
而不是anti-pattern。
此外，图像处理的效能优化，最终是必须由面向图像（就是面向二维、三维数组）的特
殊优化编译器进行。例如MIT Halide，Stanford Darkroom等。
所以，有些图像类库声称C 模板能达到编译器才能做到的优化效果，在我看来是扯淡，
或只是短暂的方案（stop-gap measure）。反正今日通用的C++ 编译器，遇上较复杂的
模版，都会引发编译器的内部缺陷。
【在 N******K 的大作中提到】
: 我设计图像滤波器类 用了很多继承 因为我很清楚各个类是干啥的
: 但是设计一些新的类 用于实现探索性质的算法 经常要大改 搞继承 是自找麻烦
: 当算法比较成熟后 可以把各个类合并一下
: 当然 公司里的项目 很少是探索性质 一开始就知道怎么搞 和我说的不是一回事
|
c****p
发帖数: 6474 | 30 这段代码里面如果出了问题你要改的话就爽死你。
理论上这和用hard coded value还是macro是一个道理。
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
|
