第一道問題是
要選擇繼承，還是組合？
例如：
汽車要繼承引擎，
還是汽車要包含一個引擎成員？
汽車繼承引擎的話，
自然的就擁有發動、加油等功能，
跟日常看到的一樣。
但它們之間並沒有 is a 的關係…
又例如：
物件計數器
template 〈class T〉
class counter
{建構加一，解構減一}
如果要統計汽車物件數量，
要繼承好，還是包含好？
第二個問題：
以生產線模擬來說，
一台機台完成動作後
要通知下一台「輪到你了」
所以機台要「認識」其他機台。
class machine｛
machine *other；
｝
但這樣一來，
machine 裡有machine，
如果有個人想搞怪，
一直 new 下去，
這樣是不是就變成
machine = 生產線 ？
我可以接受一些 tree 結構採取
自己裡面有自己的指標設計，
但就很難接受一個
活生生的、現實的例子這樣作…
是我太欠缺美感，
還是太鑽牛角尖所致嗎？

找些 object-oriented design 的書來看，會有幫助http://www.sandimetz.com/products/ 可參考雖然是用 Ruby，不過這本評價蠻好的

說美感太抽象 我以為OO只是達成高內聚低耦合的方法之一應該思考的是如何寫 才能更容易擴充與維護

我也想高維護性，但老闆總是說能動就好還是較希望是 c++ 中文版好

嗯 那你應該先說服你老闆 不然他會覺得你浪費時間又沒產出

通常老闆都會覺得會動就好XD

應該是大部分人都覺得 程式能動就好，不是只有你老闆

那你可以接受將通知下一台的邏輯移到新的類別嗎?例如生產線類別,裡面很多機台,就負責把產出餵給下一台或許你可以參考 Domain Driven Design 的思路

OO不是要你模擬現實 也不用什麼美感只要考慮內聚力 耦合性 職責這堆東西就好了

不是 很多類別會是抽象的概念 而不是現實的"東西"推薦這本書 http://tinyurl.com/4j3d5h7

設計類別如果能對應到現實的概念,能幫助理解但如果不適合還硬套的話就只有反效果

謝謝