Favor Composition Over Inheritance

又到了老生常談時間，話說我看這個topic也不下數十次了，但從沒完全吸收過，加減記一下好了

至少未來在設計時要參考直接看網站比翻pdf快。

• Composition

顧名思義，就是透過組合的方式產生一個新的Class，而這新的Class所擁有的各種function，

其實都算是源自於其他被組合的Class中所原有的各種功能，只是透過delegating機制，讓Composition Class

可以好好加以善用這些funciton，有時候我們會稱為這樣的模式為 Aggregation or Containment.

在GoF(Aggregation) / UML(Aggregation) / Coad(Containment)

到底要怎麼選擇用繼承或者用組合的方式來設計domain obj，這裡有幾個參考的標準，若符合以下標準，則可以使用繼承

的方式來進行

1. 子類別是一個特殊的父類別，而非只是扮演一個父類別的角色


2. An instance of a subclass never needs to become an object of another class


3. 子類別中不需要去覆寫(override)父類別的functions，或者否定(nullifies)父類別中的定義


4. 如果父類別本身幾乎就近乎只是(merely)一個Utility Class，那就也沒有繼承的必要了


5. For a class in the actual Problem Domain, the subclass specializesa role, transaction or device
   這一句我不太清楚到底該怎麼翻譯才好，以下是個人假想的：
   子類別主要會專注角色(role) ，或者是物件之間的關係傳遞交易(transaction)，或甚至是擔任一個裝置(device)介面

底下來個使用Composition的案例印證,在合適的時機使用繼承搭配組合關係，讓系統設計得更具有彈性