1.什么是继承
A继承B,说明A是B的一种,并且B的所有行为对A都有意义
eg:A=WOMAN B=HUMAN
A=鸵鸟 B=鸟 (不行),因为鸟会飞,但是鸵鸟不会。
2.什么是组合
若在逻辑上A是B的“一部分”(a part of),则不允许B从A派生,而是要用A和其它东西组合出B。
例如眼(Eye)、鼻(Nose)、口(Mouth)、耳(Ear)是头(Head)的一部分,所以类Head应该由类Eye、Nose、Mouth、Ear组合而成,不是派生而成
3.继承的优点和缺点
优点:
容易进行新的实现,因为其大多数可继承而来。
易于修改或扩展那些被复用的实现。
缺点:
破坏了封装性,因为这会将父类的实现细节暴露给子类。
“白盒”复用,因为父类的内部细节对于子类而言通常是可见的。
当父类的实现更改时,子类也不得不会随之更改。
从父类继承来的实现将不能在运行期间进行改变。
4.组合的优点和缺点
优点:
容器类仅能通过被包含对象的接口来对其进行访问。
“黑盒”复用,因为被包含对象的内部细节对外是不可见。
封装性好。
实现上的相互依赖性比较小。(被包含对象与容器对象之间的依赖关系比较少)
每一个类只专注于一项任务。
通过获取指向其它的具有相同类型的对象引用,可以在运行期间动态地定义(对象的)组合。
缺点:
导致系统中的对象过多。
为了能将多个不同的对象作为组合块(composition block)来使用,必须仔细地对接口进行定义。
5.两者的选择
is-a关系用继承表达,has-a关系用组合表达
继承体现的是一种专门化的概念而组合则是一种组装的概念
另外确定是组合还是继承,最清楚的方法之一就是询问是否需要新类向上映射,也就是说当我们想重用原类型作为新类型的内部实现的话,我们最好自己组合,如果我们不仅想重用内部实现而且还想重用接口的话,那就用继承。
6.法则:优先使用(对象)组合,而非(类)继承
下面引用一个例子来解释一下:
C++的“继承”特性可以提高程序的可复用性。正因为“继承”太有用、太容易用,才要防止乱用“继承”。我们要给“继承”立一些使用规则:
一、如果类A 和类B 毫不相关,不可以为了使B 的功能更多些而让B 继承A 的功能。
不要觉得“不吃白不吃”,让一个好端端的健壮青年无缘无故地吃人参补身体。
二、如果类B 有必要使用A 的功能,则要分两种情况考虑:
(1)若在逻辑上B 是A 的“一种”(a kind of ),则允许B 继承A 的功能。如男人(Man)是人(Human)的一种,男孩(Boy)是男人的一种。那么类Man 可以从类Human 派生,类Boy 可以从类Man 派生。示例程序如下:
class Human
{
…
};
class Man : public Human
{
…
};
class Boy : public Man
{
…
};
(2)若在逻辑上A 是B 的“一部分”(a part of),则不允许B 继承A 的功能,而是要用A和其它东西组合出B。例如眼(Eye)、鼻(Nose)、口(Mouth)、耳(Ear)是头(Head)的一部分,所以类Head 应该由类Eye、Nose、Mouth、Ear 组合而成,不是派生而成。示例程序如下:
class Eye
{
public:
void Look(void);
};
class Nose
{
public:
void Smell(void);
};
class Mouth
{
public:
void Eat(void);
};
class Ear
{
public:
void Listen(void);
};
// 正确的设计,冗长的程序
class Head
{
public:
void Look(void) { m_eye.Look(); }
void Smell(void) { m_nose.Smell(); }
void Eat(void) { m_mouth.Eat(); }
void Listen(void) { m_ear.Listen(); }
private:
Eye m_eye;
Nose m_nose;
Mouth m_mouth;
Ear m_ear;
};
如果允许Head 从Eye、Nose、Mouth、Ear 派生而成,那么Head 将自动具有Look、Smell、Eat、Listen 这些功能:
// 错误的设计
class Head : public Eye, public Nose, public Mouth, public Ear
{
};
上述程序十分简短并且运行正确,但是这种设计却是错误的。这就开头所说的很多程序员经不起“继承”的诱惑而犯下设计错误。
转自:
http://blog.chinaunix.net/uid-23943797-id-2646376.html
http://www.cnblogs.com/BeyondAnyTime/archive/2012/05/20/2510770.html