a*y
2 楼
【 以下文字转载自 Parenting 讨论区 】
发信人: ayready (人马座), 信区: Parenting
标 题: 有熟悉上海的吗？
发信站: BBS 未名空间站 (Wed Oct 31 23:20:26 2012, 美东)
带2岁小孩到上海住几天，主要要签证。美国大使馆附近有什么2岁小孩玩的地方吗？如
果没有，哪里有？我住那。
发信人: ayready (人马座), 信区: Parenting
标 题: 有熟悉上海的吗？
发信站: BBS 未名空间站 (Wed Oct 31 23:20:26 2012, 美东)
带2岁小孩到上海住几天，主要要签证。美国大使馆附近有什么2岁小孩玩的地方吗？如
果没有，哪里有？我住那。
e*G
3 楼
挺搞的
N*w
4 楼
加底座键盘能到 16hr 续航。。。
IPS 屏
肯下本钱啊
http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
IPS 屏
肯下本钱啊
http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
N*K
5 楼
为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
s*e
6 楼
我老板拿过。
我们去年差点拿到。
【在 w********s 的大作中提到】
: 值得花时间去申请吗？有人拿到过吗？
我们去年差点拿到。
【在 w********s 的大作中提到】
: 值得花时间去申请吗？有人拿到过吗？
e*y
7 楼
还是可以跟底座脱离的transformer好, slider没啥意思, 太厚太重
ASUS says the Transformer will run between $400 and $700 and the Slider from
$500 to $800. Expect them in April and May respectively.
4月份, $400, 很不错
【在 N****w 的大作中提到】
: 加底座键盘能到 16hr 续航。。。
: IPS 屏
: 肯下本钱啊
: http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
ASUS says the Transformer will run between $400 and $700 and the Slider from
$500 to $800. Expect them in April and May respectively.
4月份, $400, 很不错
【在 N****w 的大作中提到】
: 加底座键盘能到 16hr 续航。。。
: IPS 屏
: 肯下本钱啊
: http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
a*e
8 楼
其实这个问题一直困扰着叔20年，遗产税税率那么高，继承有屌用
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
e*g
9 楼
看你跟谁做
我们这里好几个拿到的
【在 w********s 的大作中提到】
: 值得花时间去申请吗？有人拿到过吗？
我们这里好几个拿到的
【在 w********s 的大作中提到】
: 值得花时间去申请吗？有人拿到过吗？
a*a
10 楼
什么系统？
【在 N****w 的大作中提到】
: 加底座键盘能到 16hr 续航。。。
: IPS 屏
: 肯下本钱啊
: http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
【在 N****w 的大作中提到】
: 加底座键盘能到 16hr 续航。。。
: IPS 屏
: 肯下本钱啊
: http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
g*g
11 楼
LOL，你的代码都是跑完就扔的，当然是好办法。
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
C*5
12 楼
啥意思？要找牛人合作才行吗？
【在 e****g 的大作中提到】
: 看你跟谁做
: 我们这里好几个拿到的
【在 e****g 的大作中提到】
: 看你跟谁做
: 我们这里好几个拿到的
e*y
13 楼
这一波当然都是honeycomb
【在 a***a 的大作中提到】
: 什么系统？
【在 a***a 的大作中提到】
: 什么系统？
r*y
14 楼
擦...
民间科学家通常是宇宙无敌的...
民间科学家通常是宇宙无敌的...
e*g
15 楼
你得在qatar有合作者，
你一个人有啥用。
【在 C********5 的大作中提到】
: 啥意思？要找牛人合作才行吗？
你一个人有啥用。
【在 C********5 的大作中提到】
: 啥意思？要找牛人合作才行吗？
a*a
16 楼
what's this
【在 e***y 的大作中提到】
: 这一波当然都是honeycomb
【在 e***y 的大作中提到】
: 这一波当然都是honeycomb
r*y
17 楼
登录了一下, 让goodbug 抢先了30s...
C*5
18 楼
是潜规则吗？好象没看见说是一定要QATAR的合作者。多谢！
e*y
19 楼
在本版混连android3.0都不认识, 发包子平谢罪把
【在 a***a 的大作中提到】
: what's this
【在 a***a 的大作中提到】
: what's this
r*s
20 楼
have you ever heard of code clone and the problems associated with it?
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
a*a
21 楼
我不是刚混了一个月而已。。
【在 e***y 的大作中提到】
: 在本版混连android3.0都不认识, 发包子平谢罪把
【在 e***y 的大作中提到】
: 在本版混连android3.0都不认识, 发包子平谢罪把
w*w
22 楼
Never use inheritance if you can. keep using has a instead of is a. lol
w*g
23 楼
这个分辩率看1080p无码高清够么。
【在 N****w 的大作中提到】
: 加底座键盘能到 16hr 续航。。。
: IPS 屏
: 肯下本钱啊
: http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
【在 N****w 的大作中提到】
: 加底座键盘能到 16hr 续航。。。
: IPS 屏
: 肯下本钱啊
: http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
b*s
24 楼
一定程度上你是对的，继承是一种强耦合关系，层次一多特性一多维护并不省事。而派
生类一旦复杂，基类作为接口的本意也模糊了。
多继承太复杂，很难用，同理
想想aws要是大量用oo继承来实现会是什么样的灾难
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
生类一旦复杂，基类作为接口的本意也模糊了。
多继承太复杂，很难用，同理
想想aws要是大量用oo继承来实现会是什么样的灾难
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
f*m
25 楼
为啥transformer 比slider便宜那么多？$400 vs. $500，硬件不是一样么？要是能用
full
blown google doc, citrix，那就很有吸引力了
are-here-for-those-that-can/
http://www.blogcdn.com/www.engadget.com/media/2011/01/slidertra
d.jpg
【在 N****w 的大作中提到】
: 加底座键盘能到 16hr 续航。。。
: IPS 屏
: 肯下本钱啊
: http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
full
blown google doc, citrix，那就很有吸引力了
are-here-for-those-that-can/
http://www.blogcdn.com/www.engadget.com/media/2011/01/slidertra
d.jpg
【在 N****w 的大作中提到】
: 加底座键盘能到 16hr 续航。。。
: IPS 屏
: 肯下本钱啊
: http://www.engadget.com/2011/01/04/asus-eee-pad-slider-and-tran
g*y
26 楼
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 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
Maybe you did not see how copy/paste can be abused?
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
N*w
27 楼
当然够了
除非你总用显微镜看屏幕。。。
或者你
接 HDMI 电视。。。hehe
【在 w*****g 的大作中提到】
: 这个分辩率看1080p无码高清够么。
除非你总用显微镜看屏幕。。。
或者你
接 HDMI 电视。。。hehe
【在 w*****g 的大作中提到】
: 这个分辩率看1080p无码高清够么。
N*K
28 楼
我设计图像滤波器类 用了很多继承 因为我很清楚各个类是干啥的
但是设计一些新的类 用于实现探索性质的算法 经常要大改 搞继承 是自找麻烦
当算法比较成熟后 可以把各个类合并一下
当然 公司里的项目 很少是探索性质 一开始就知道怎么搞 和我说的不是一回事
【在 b*******s 的大作中提到】
: 一定程度上你是对的，继承是一种强耦合关系，层次一多特性一多维护并不省事。而派
: 生类一旦复杂，基类作为接口的本意也模糊了。
: 多继承太复杂，很难用，同理
: 想想aws要是大量用oo继承来实现会是什么样的灾难
但是设计一些新的类 用于实现探索性质的算法 经常要大改 搞继承 是自找麻烦
当算法比较成熟后 可以把各个类合并一下
当然 公司里的项目 很少是探索性质 一开始就知道怎么搞 和我说的不是一回事
【在 b*******s 的大作中提到】
: 一定程度上你是对的，继承是一种强耦合关系，层次一多特性一多维护并不省事。而派
: 生类一旦复杂，基类作为接口的本意也模糊了。
: 多继承太复杂，很难用，同理
: 想想aws要是大量用oo继承来实现会是什么样的灾难
g*a
29 楼
看起来很有吸引力啊
w*w
30 楼
多重继承太evil 了。 这个就是为啥java 用implement 多个 interface 来代替多重继
承了。 继承就是个贼船，上去了就下不来了。 比较恶心，就我个人观点看来OO 核心
就是封装。多态，继承都是扯。哪里有变化哪里就有封装！ 如果实在喜欢继承的话，
能保证以后需求的一定时间不改变的话，也可以用继承。否则的话，尽量少用继承，继
承耦合度太紧 太紧了。到了后来你会有牵一发而动全身的痛苦的！ 我记得用functor
还有 boost 的那个bind 啥的 在大部分情况下我们可以组合自己的functionality 而
不用继承。不用继承的话，那么那些design pattern 貌似也木有啥大用场了。 本来那
些design pattern的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
有点花架子的感觉！ ^_^
承了。 继承就是个贼船，上去了就下不来了。 比较恶心，就我个人观点看来OO 核心
就是封装。多态，继承都是扯。哪里有变化哪里就有封装！ 如果实在喜欢继承的话，
能保证以后需求的一定时间不改变的话，也可以用继承。否则的话，尽量少用继承，继
承耦合度太紧 太紧了。到了后来你会有牵一发而动全身的痛苦的！ 我记得用functor
还有 boost 的那个bind 啥的 在大部分情况下我们可以组合自己的functionality 而
不用继承。不用继承的话，那么那些design pattern 貌似也木有啥大用场了。 本来那
些design pattern的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
有点花架子的感觉！ ^_^
w*g
31 楼
己经让ip4惯坏了，现在看神马屏幕也不顺眼，10寸板要能做到200ppi以上我就满足鸟。
【在 N****w 的大作中提到】
: 当然够了
: 除非你总用显微镜看屏幕。。。
: 或者你
: 接 HDMI 电视。。。hehe
【在 N****w 的大作中提到】
: 当然够了
: 除非你总用显微镜看屏幕。。。
: 或者你
: 接 HDMI 电视。。。hehe
l*t
32 楼
全用mixin，人生快乐多
N*w
33 楼
哪家店来个 50% off 就呼啦呼啦都跳了 hehe
【在 g*****a 的大作中提到】
: 看起来很有吸引力啊
【在 g*****a 的大作中提到】
: 看起来很有吸引力啊
k*i
34 楼
composition over inheritance; DI
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
e*y
35 楼
估计transformer那个底座不是标配, 单买加$100
【在 f********m 的大作中提到】
: 为啥transformer 比slider便宜那么多？$400 vs. $500，硬件不是一样么？要是能用
: full
: blown google doc, citrix，那就很有吸引力了
:
: are-here-for-those-that-can/
: http://www.blogcdn.com/www.engadget.com/media/2011/01/slidertra
: d.jpg
【在 f********m 的大作中提到】
: 为啥transformer 比slider便宜那么多？$400 vs. $500，硬件不是一样么？要是能用
: full
: blown google doc, citrix，那就很有吸引力了
:
: are-here-for-those-that-can/
: http://www.blogcdn.com/www.engadget.com/media/2011/01/slidertra
: d.jpg
b*s
36 楼
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的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
: 有点花架子的感觉！ ^_^
love it
functor
【在 w******w 的大作中提到】
: 多重继承太evil 了。 这个就是为啥java 用implement 多个 interface 来代替多重继
: 承了。 继承就是个贼船，上去了就下不来了。 比较恶心，就我个人观点看来OO 核心
: 就是封装。多态，继承都是扯。哪里有变化哪里就有封装！ 如果实在喜欢继承的话，
: 能保证以后需求的一定时间不改变的话，也可以用继承。否则的话，尽量少用继承，继
: 承耦合度太紧 太紧了。到了后来你会有牵一发而动全身的痛苦的！ 我记得用functor
: 还有 boost 的那个bind 啥的 在大部分情况下我们可以组合自己的functionality 而
: 不用继承。不用继承的话，那么那些design pattern 貌似也木有啥大用场了。 本来那
: 些design pattern的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
: 有点花架子的感觉！ ^_^
e*y
37 楼
sears的拿到了没就开始yy下一个50%off了?
【在 N****w 的大作中提到】
: 哪家店来个 50% off 就呼啦呼啦都跳了 hehe
【在 N****w 的大作中提到】
: 哪家店来个 50% off 就呼啦呼啦都跳了 hehe
l*s
38 楼
OO很好呀，可以正大光明的把复杂的问题搞的加倍复杂，提高马工岗位安全性
h*s
39 楼
seriously世上有这种东西么？
【在 w*****g 的大作中提到】
: 这个分辩率看1080p无码高清够么。
【在 w*****g 的大作中提到】
: 这个分辩率看1080p无码高清够么。
d*r
40 楼
"就我个人观点看来OO 核心就是封装。多态，继承都是扯"
那 C 的 structure, JS 的 JSON 也有封装了，只是没有 public/private 强制控制
access 的权限.
functor
【在 w******w 的大作中提到】
: 多重继承太evil 了。 这个就是为啥java 用implement 多个 interface 来代替多重继
: 承了。 继承就是个贼船，上去了就下不来了。 比较恶心，就我个人观点看来OO 核心
: 就是封装。多态，继承都是扯。哪里有变化哪里就有封装！ 如果实在喜欢继承的话，
: 能保证以后需求的一定时间不改变的话，也可以用继承。否则的话，尽量少用继承，继
: 承耦合度太紧 太紧了。到了后来你会有牵一发而动全身的痛苦的！ 我记得用functor
: 还有 boost 的那个bind 啥的 在大部分情况下我们可以组合自己的functionality 而
: 不用继承。不用继承的话，那么那些design pattern 貌似也木有啥大用场了。 本来那
: 些design pattern的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
: 有点花架子的感觉！ ^_^
那 C 的 structure, JS 的 JSON 也有封装了，只是没有 public/private 强制控制
access 的权限.
functor
【在 w******w 的大作中提到】
: 多重继承太evil 了。 这个就是为啥java 用implement 多个 interface 来代替多重继
: 承了。 继承就是个贼船，上去了就下不来了。 比较恶心，就我个人观点看来OO 核心
: 就是封装。多态，继承都是扯。哪里有变化哪里就有封装！ 如果实在喜欢继承的话，
: 能保证以后需求的一定时间不改变的话，也可以用继承。否则的话，尽量少用继承，继
: 承耦合度太紧 太紧了。到了后来你会有牵一发而动全身的痛苦的！ 我记得用functor
: 还有 boost 的那个bind 啥的 在大部分情况下我们可以组合自己的functionality 而
: 不用继承。不用继承的话，那么那些design pattern 貌似也木有啥大用场了。 本来那
: 些design pattern的东西 就是繁花叠绕的 ， 貌似木有拳拳到肉的感觉！ :-) 有时候
: 有点花架子的感觉！ ^_^
w*g
41 楼
这三个参数你哪个不了解？
1080p兮？无码兮？高清兮？
【在 h*******s 的大作中提到】
: seriously世上有这种东西么？
1080p兮？无码兮？高清兮？
【在 h*******s 的大作中提到】
: seriously世上有这种东西么？
w*w
42 楼
你说对了， 向伟大的C语言致敬！至于 JS 咱木有写过不好发表意见！
C++ 在某些特殊场合根本不用，还就是C语言呢。 就那个exception 你就不可控。有的
场合确实不敢用OO的语言， C 清晰可控！ ^_^
【在 d*******r 的大作中提到】
: "就我个人观点看来OO 核心就是封装。多态，继承都是扯"
: 那 C 的 structure, JS 的 JSON 也有封装了，只是没有 public/private 强制控制
: access 的权限.
:
: functor
C++ 在某些特殊场合根本不用，还就是C语言呢。 就那个exception 你就不可控。有的
场合确实不敢用OO的语言， C 清晰可控！ ^_^
【在 d*******r 的大作中提到】
: "就我个人观点看来OO 核心就是封装。多态，继承都是扯"
: 那 C 的 structure, JS 的 JSON 也有封装了，只是没有 public/private 强制控制
: access 的权限.
:
: functor
e*y
43 楼
当然有, av业一向走在技术前沿
seriously世上有这种东西么？
【在 h*******s 的大作中提到】
: seriously世上有这种东西么？
seriously世上有这种东西么？
【在 h*******s 的大作中提到】
: seriously世上有这种东西么？
g*g
44 楼
OO里，Java的那套才是王道。interface+ DI, 没啥不能解决的。Spring Security是很
经典的一个框架，继承很复杂，代码很精炼。
经典的一个框架，继承很复杂，代码很精炼。
e*l
45 楼
向往一下，1280听起来很不错啊
M*P
46 楼
copypaste其实对data science很有用。
★ 发自iPhone App: ChineseWeb 7.8
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
★ 发自iPhone App: ChineseWeb 7.8
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
c*r
47 楼
你点进去楼主给的link就有答案了，1080p跟无码实在是没什么联系
【在 w*****g 的大作中提到】
: 这三个参数你哪个不了解？
: 1080p兮？无码兮？高清兮？
w*x
48 楼
继承本质上就是线性关系的表达，但现实中很多是图的结构，非用linear模拟graph，
实际上是很糟糕的思想。
实际上是很糟糕的思想。
h*s
49 楼
这三个都了解。但因为是weidong的帖子，所以你应该是指AV。AV界已经有1080屁的东
东了？
【在 w*****g 的大作中提到】
: 这三个参数你哪个不了解？
: 1080p兮？无码兮？高清兮？
东了？
【在 w*****g 的大作中提到】
: 这三个参数你哪个不了解？
: 1080p兮？无码兮？高清兮？
b*s
50 楼
OO is only good for scenarios require huge amt of interactions
【在 g*****g 的大作中提到】
: OO里，Java的那套才是王道。interface+ DI, 没啥不能解决的。Spring Security是很
: 经典的一个框架，继承很复杂，代码很精炼。
【在 g*****g 的大作中提到】
: OO里，Java的那套才是王道。interface+ DI, 没啥不能解决的。Spring Security是很
: 经典的一个框架，继承很复杂，代码很精炼。
d*r
51 楼
我懂你说那种 C style, Linux kernel 里很多
其实我用 JS/Node.js 差不多也是这么用的，有时确实不想写严谨的 OOP
【在 w******w 的大作中提到】
: 你说对了， 向伟大的C语言致敬！至于 JS 咱木有写过不好发表意见！
: C++ 在某些特殊场合根本不用，还就是C语言呢。 就那个exception 你就不可控。有的
: 场合确实不敢用OO的语言， C 清晰可控！ ^_^
其实我用 JS/Node.js 差不多也是这么用的，有时确实不想写严谨的 OOP
【在 w******w 的大作中提到】
: 你说对了， 向伟大的C语言致敬！至于 JS 咱木有写过不好发表意见！
: C++ 在某些特殊场合根本不用，还就是C语言呢。 就那个exception 你就不可控。有的
: 场合确实不敢用OO的语言， C 清晰可控！ ^_^
d*r
52 楼
大牛说说 Java 里 interface+ DI 需要用很多继承吗?
只用过其他语言里的 DI, 感觉这个 pattern 跟继承就不是一个路数的呀
【在 g*****g 的大作中提到】
: OO里，Java的那套才是王道。interface+ DI, 没啥不能解决的。Spring Security是很
: 经典的一个框架，继承很复杂，代码很精炼。
只用过其他语言里的 DI, 感觉这个 pattern 跟继承就不是一个路数的呀
【在 g*****g 的大作中提到】
: OO里，Java的那套才是王道。interface+ DI, 没啥不能解决的。Spring Security是很
: 经典的一个框架，继承很复杂，代码很精炼。
d*r
53 楼
我同意这个. 总感觉继承的描述能力很有限.
线性依赖/复用下来，像是个 tree; 但是现实世界的依赖关系，更像个 graph.
所以我一般更爱用组合, 如果一定要 OOP 的话.
【在 w***x 的大作中提到】
: 继承本质上就是线性关系的表达，但现实中很多是图的结构，非用linear模拟graph，
: 实际上是很糟糕的思想。
线性依赖/复用下来，像是个 tree; 但是现实世界的依赖关系，更像个 graph.
所以我一般更爱用组合, 如果一定要 OOP 的话.
【在 w***x 的大作中提到】
: 继承本质上就是线性关系的表达，但现实中很多是图的结构，非用linear模拟graph，
: 实际上是很糟糕的思想。
D*n
54 楼
所以Objective-C里面的Protocol/Delegate/Catagory 三者组合起来是个更优秀的解决
方案。可以在运行时动态绑定继承的对象。
【在 d*******r 的大作中提到】
: 我同意这个. 总感觉继承的描述能力很有限.
: 线性依赖/复用下来，像是个 tree; 但是现实世界的依赖关系，更像个 graph.
: 所以我一般更爱用组合, 如果一定要 OOP 的话.
方案。可以在运行时动态绑定继承的对象。
【在 d*******r 的大作中提到】
: 我同意这个. 总感觉继承的描述能力很有限.
: 线性依赖/复用下来，像是个 tree; 但是现实世界的依赖关系，更像个 graph.
: 所以我一般更爱用组合, 如果一定要 OOP 的话.
g*g
55 楼
这两者是独立的，要不要继承还是那个is-a的问题。DI的好处是把dependency graph简
化，从而减少了很多纯粹为了传递产生的耦合。
composition over inheritance带来一定的灵活性，但同时boiler plate代码也多一些
。所以具体问题具体分析，如果继承关系勉强，只是为了复用方法，显然应该用
composition.
【在 d*******r 的大作中提到】
: 大牛说说 Java 里 interface+ DI 需要用很多继承吗?
: 只用过其他语言里的 DI, 感觉这个 pattern 跟继承就不是一个路数的呀
化，从而减少了很多纯粹为了传递产生的耦合。
composition over inheritance带来一定的灵活性，但同时boiler plate代码也多一些
。所以具体问题具体分析，如果继承关系勉强，只是为了复用方法，显然应该用
composition.
【在 d*******r 的大作中提到】
: 大牛说说 Java 里 interface+ DI 需要用很多继承吗?
: 只用过其他语言里的 DI, 感觉这个 pattern 跟继承就不是一个路数的呀
d*r
56 楼
知道了，多谢
【在 g*****g 的大作中提到】
: 这两者是独立的，要不要继承还是那个is-a的问题。DI的好处是把dependency graph简
: 化，从而减少了很多纯粹为了传递产生的耦合。
: composition over inheritance带来一定的灵活性，但同时boiler plate代码也多一些
: 。所以具体问题具体分析，如果继承关系勉强，只是为了复用方法，显然应该用
: composition.
【在 g*****g 的大作中提到】
: 这两者是独立的，要不要继承还是那个is-a的问题。DI的好处是把dependency graph简
: 化，从而减少了很多纯粹为了传递产生的耦合。
: composition over inheritance带来一定的灵活性，但同时boiler plate代码也多一些
: 。所以具体问题具体分析，如果继承关系勉强，只是为了复用方法，显然应该用
: composition.
k*g
57 楼
上面神马解释都有大牛反覆说明了。大牛们用的语言当然是高大上的洋文。
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.
澄清，我用的是佯文，不是洋文。
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
58 楼
我也是做图像处理的。
个人认为，图像处理是适合用『functional decomposition』的特殊场合，是pattern
而不是anti-pattern。
此外，图像处理的效能优化，最终是必须由面向图像（就是面向二维、三维数组）的特
殊优化编译器进行。例如MIT Halide，Stanford Darkroom等。
所以，有些图像类库声称C 模板能达到编译器才能做到的优化效果，在我看来是扯淡，
或只是短暂的方案（stop-gap measure）。反正今日通用的C++ 编译器，遇上较复杂的
模版，都会引发编译器的内部缺陷。
【在 N******K 的大作中提到】
: 我设计图像滤波器类 用了很多继承 因为我很清楚各个类是干啥的
: 但是设计一些新的类 用于实现探索性质的算法 经常要大改 搞继承 是自找麻烦
: 当算法比较成熟后 可以把各个类合并一下
: 当然 公司里的项目 很少是探索性质 一开始就知道怎么搞 和我说的不是一回事
c*p
59 楼
这段代码里面如果出了问题你要改的话就爽死你。
理论上这和用hard coded value还是macro是一个道理。
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
理论上这和用hard coded value还是macro是一个道理。
【在 N******K 的大作中提到】
: 为了复用而搞多重继承 搞多了 各种模块就互相偶合起来 以后不好改 不好调试
相关阅读
An interview question. Thanks.what's wrong with the following codes?这个fast heapsort中文叫啥？一个c语言的问题一道面试题仙人指路 ----〉我该怎么办？ (转载)大包子求:大家知道这个网站怎么hack吗?问个perl Mechanize问题大家怎么应付这样的同事？有Matlab的代码，怎么样能转换成C/C++能用的库文件?大侠们救命啊：我的office 2003总是变灰，被锁，怎么办啊？谢谢！C#如何产生指数分布的数组有什么软件包可以解这种优化问题？Order of calling constructors刚才在水木被震撼了一下 how to do it ?=======Problem – coding in c++如何在gdb中遍历binary tree问个C++的简单问题Pattern matching请帮忙看看这个字符函数的错误在哪里