面向对象：类组合还是类继承？

 

类组合还是类继承？假设我们有一张表A，有多个画面用到。比如10个画面用到。由于每个画面功能不一样，但A表的大多数字段所以字段都是共用的。这种情况下，怎么写自己的INFO类呢？大概有3种方案方案1：每个画面都写一个自己的INFO类。方案2：先写一个表A的INFO类，然后每个画面的INFO类里面加一个表A的INFO类作为属性。也就是类组合。方案3：先写一个表A的INFO类，然后每个画面的INFO类都继承于表A的INFO类。也就是类继承。 我们稍微分析一下，方案1首先被淘汰掉，因为代码量大，增加了工作量和维护成本。那方案2和方案3呢？都是面向对象的思想，究竟哪种好呢？这还得了解一下类组合和类继承的优缺点。■类组合的优点：   --容器类仅能通过被包含对象的接口来对其进行访问。   --  “黑盒”复用，因为被包含对象的内部细节对外是不可见。   -- 封装性好。   -- 实现上的相互依赖性比较小。被包含对象与容器对象之间的依赖关系比较少   -- 每一个类只专注于一项任务。   -- 通过获取指向其它的具有相同类型的对象引用，可以在运行期间动态地定义（对象的）组合。■类组合的缺点：   -- 导致系统中的对象过多。   -- 为了能将多个不同的对象作为组合块（composition block）来使用，必须仔细地对接口进行定义。 ■类继承的优点：   --  容易进行新的实现，因为其大多数可继承而来。   --  易于修改或扩展那些被复用的实现。■类继承的缺点：   --  破坏了封装性，因为这会将父类的实现细节暴露给子类。   --  “白盒”复用，因为父类的内部细节对于子类而言通常是可见的。   --  当父类的实现更改时，子类也不得不会随之更改。   --  从父类继承来的实现将不能在运行期间进行改变。 Coad规则仅当下列的所有标准被满足时，方可使用继承：   ▲子类表达了“是一个…的特殊类型”，而非“是一个由…所扮演的角色”。   ▲子类的一个实例永远不需要转化（transmute）为其它类的一个对象。   ▲子类是对其父类的职责（responsibility）进行扩展，而非重写或废除（nullify）。   ▲子类没有对那些仅作为一个工具类（utility class）的功能进行扩展。   ▲对于一个位于实际的问题域（Problem Domain）的类而言，其子类特指一种角色（role），交易（transaction）或设备（device）。   组合与继承都是重要的重用方法，在面向对象开发的早期继承被过度使用。实际上究竟是用组合还是继承是要根据实际情况来判断的，用组合的好处多还是用继承的好处多，或者两者集合起来用。  因此综合上面的优缺点，上面的那个例子用继承好处多，因为这个地方只是一个单纯的一张表的操作。如果是设计多张表的话，使用类组合更好一些，因为类组合封装性好，不容易出错。这个地方就需要我们具体问题具体分析了。