※ 引述《internaltide (internaltide)》之铭言：
: 看了一些设计模式跟物件导向的书，都会提到一个观念就是
: 多用合成，少用继承
: 之后，自己在写程式时有尝试着多使用合成去取代继承
: 但是发现被合成物件(物件C、D)要取得合成物件(物件A)的资料时都会很不方便
: 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 的东西。
然后看来你的认知有一个大问题。当谈及 继承 vs 合成，说的完全
不是你的在说的情况。在说以合成取代继承是类似长这样的东西:
class A {...}
class B extends A {.....} // 继承
class C { // 合成
private A a;
....
}
当然这种情况之下, A 通常会有某种interface, 而 C
也会提供这种 interface 并利用内部的 A instance 来
达成。
可是你在说的是
class A {
private C c;
}
这完全是不相干的话题。
至于你的情况下 C 怎样用到 A 的东西，这涉及你设计的问题，
很难一概而论。当然最常做的是 C 也存著 A 的 reference 然后
C 经此 ref access 包含着自己的那个 A。但更常见的做法是做
好设计，让 C 能不需要知道自己是被 A 所包含而单纯做好自己的
工作就够。
Alien