第一道问题是
要选择继承，还是组合？
例如：
汽车要继承引擎，
还是汽车要包含一个引擎成员？
汽车继承引擎的话，
自然的就拥有发动、加油等功能，
跟日常看到的一样。
但它们之间并没有 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

设计类别如果能对应到现实的概念,能帮助理解但如果不适合还硬套的话就只有反效果

谢谢