两个“不合理继承 ”的判定标识

继承作为面向对象编程中的一项重大特性，其有着独特的威力——代码复用、功能扩展、运行多态  这些都与继承有着密切的关系。

 

代码复用：

将一组平行类中的相同或相似功能提取到父类，利用继承父类、重用父类代码，可大大减少的代码量。

 

功能扩展：

如果某个类已经拥有了 A、B、C 功能，这时想添加一项功能D，但却不想或者不能修改该类，则可以新建子类、利用继承，获得A、B、C 功能，并在子类中添加 D功能，即可实现目标。

 

运行多态：

继承的关键字：C#用冒号、Java用extends，其有两种形式的用法。

1）当作占位符去使用：【关于这一点仔细思考静态语言和动态语言的差异性就能理解了】

2）搭建继承体系

 

无论是以上的那种用法，其和面向对象编程的另一个特性——多态，它们之间的亲密度可以用“如胶似漆”去形容，在很多情况下继承中都会存在多态的“影子”。

 

以上三点可以作为继承的优点，但是有利必有弊：

1）子类将强制继承父类的全部非私有功能。

2）父类中任何修改都有可能会影响到全部子类。

3）如果继承体系过长，很容易造成代码冗余。

4）等等。

 

当然如果继承体系搭建的很合理、足以应对需求变化，

那从当前角度出发考虑问题(PS:人没有足够强的预知能力)，上述的缺点是可以忽略的。

 

但是往往继承体系搭建的并不合理，也就是通常意义上的滥用继承。

我想许多人在继承的使用方面都会经历以下的几个阶段：

1）不会使用继承

2）滥用继承，即遇到任何可以搭建继承体系的代码都会去使用继承【当然这个描述有点极端了】。

3）少用继承

4）使用组合代替继承

5）继承与组合+ 封装完美协作

 

PS:

工厂方法和模板方法是继承的典型用法。

状态模式和装饰者模式是组合 + 封装的极致体现。

 

本文标题为《两个“不合理继承”的判定标识》，现在进入正题，当然前面的铺垫在我看来是必不可少的，且正文篇幅也不是足够大：

 

如果满足如下的这个条件，即可判定为“不合理的继承”，背景条件，有如下代码

 

public class Base{

protected int id;

 

public int getId() {

return id;

}

}

 

public class A extends Base{

// 在此类中可以自由访问 id

}

 

现状：

Base类：封装了 Base类、或者说是封装了id ，使id的访问收到保护。

A类：扩展了Base 类，但是在 A 中可以自由访问 id。

 

判定条件：如何在A类中自由访问id是不合理的，则可以判定为不合理继承，即破坏了封装的继承是不合理的。

往往破坏了封装的继承实际上使用组合更合理，往往破坏了封装的继承的两个类实际上是两个独立的职责，也就是违反了单一职责原则。

 

 

此判定方式是利用封装的特性去盘判定的，此外利用现实世界和继承体系是否冲突也可以作为判定条件，案例如：

 

有普通游戏玩家和职业游戏玩家两个类，但是不应该建立一个“所有人都玩游戏”的父类，而可以建立一个“所有玩游戏的人”的父类。进而搭建继承体系。因为：不是所有人都玩游戏，这与“真实世界”相冲突了。

 

当然还有许多其他类型的不合理继承的，比如不能满足特殊业务需求等等，总之：继承没有对与错，而是合理与不合理，而是否合理最终的判定条件是要视情况而定，以上只是列举了两种简易的判别方式。

 

————————————————————————————————————————————————————————————

续写：2013-11-28

————————————————————————————————————————————————————————————

不合理继承的“危害”：

1）造成结构混乱，增加代码复杂度，加大学习成本、尤其是“新人”，同时给代码命名也带来一定困扰。

2）增加维护复杂度、无论是修改功能还是添加新功能，牵一发而动全身：在维护一项功能的时候，会牵扯出许多其他的功能，给测试带来不必要的麻烦。