※ 引述《adrianshum (Alien)》之铭言：
: ※ 引述《internaltide (internaltide)》之铭言：
: : ~
: : EX.
: : // 物件A
: : class objectA{
: [43]
: : public objectC; //合成的物件C
: : public objectD;
: : public function func1(){...}
: : public function func2(){...}
: : }
: : // 继承物件A的物件B
: : class objectB extend objectA{
: [43]
: : }
: : 可能同样的物件内容B跟C，但实际上当要取得物件A的资料时
: : 物件B可以很直觉的直接使用物件A的属性或间接使用方法来取得资料。
: : 但物件C就很麻烦了，变成我可能必须在A Class的建构式中时就要把资料
: : 想办法塞到C物件，搞到后来变成当D物件也需要相同资料时，我又得重复
: : 塞相同的资料到物件D。 晕!!
: : 后来，我都是直接在物件A设了一个名为shareResources的阵列并宣告为Static，
: : 再把所有共用资源都往那个阵列塞。
: : 然后，无论合成物件或继承物件都可以直接取用物件A的资料了。
: : 不晓得做法好不好，有没有大师提供更聪明的方法??
: 首先，当static 牵连到继承之类的话题，99% 都不会是正确的做法。
: 单想想，当你有两个 A instance, 你所谓 shared resource 放的是
: 哪个 A 的东西。
static牵连到继承有99%是错的做法? 不太懂...
属性被宣告为static时，不是就所有的A的实例所共用的了吗?
: 然后看来你的认知有一个大问题。当谈及 继承 vs 合成，说的完全
: 不是你的在说的情况。在说以合成取代继承是类似长这样的东西:
: class A {...}
: class B extends A {.....} // 继承
: class C { // 合成
: private A a;
: ....
: }
可能是因为强调合成物件要取资料的问题，所以例子focus的点有点偏掉了。
不过我的观念:
当一个物件跟另一个物件具有Has-a的关系时就是一种合成关系，
某物件需要寄信功能时，不继承mailClass而是设定它有一个属性mailer，
然后让mailer是mailClass的实例 =>这就叫合成取代继承
这样应该没错了吧 ^^
: 当然这种情况之下, A 通常会有某种interface, 而 C
: 也会提供这种 interface 并利用内部的 A instance 来
: 达成。
: 可是你在说的是
: class A {
: private C c;
: }
: 这完全是不相干的话题。
: 至于你的情况下 C 怎样用到 A 的东西，这涉及你设计的问题，
: 很难一概而论。当然最常做的是 C 也存著 A 的 reference 然后
: C 经此 ref access 包含着自己的那个 A。但更常见的做法是做
: 好设计，让 C 能不需要知道自己是被 A 所包含而单纯做好自己的
: 工作就够。
: Alien
嗯!! 让 C 能不需要知道自己是被 A 所包含而单纯做好自己的工作
物件导向设计是一条很遥远的路啊!!
谢谢 Alien囉!!