类的继承层次结构的宽度和深度

最近在项目开发中，各位兄弟对于现有的架构有所诟病，主要是继承的问题，层次比较深，层次之间没有很明确的功能划分，造成一定的混乱。我来承担工作，想出一套新的方案，满足大家平时开发的需求。

先总结下现在项目的问题，一个是层次深，一个是抽象的不好；大家有时候可能为了省事，就直接在一个比较高的基类里写入了一个少部分子类才会用到功能，等等；最终造成一种情况就是大家做一个功能时候要添加或者修改一个地方的时候查找的成本比较大，另外继承多了以后跳来跳去的成本，阅读理解成本比较高，尤其对于新来的开发同学也是难理解。

我想方案的整体思路也就是减少继承，增加组合来实现了，但是对于继承这个问题，肯定是避免不了的，那到底继承到什么程度是大家可以接受的，在网上找到一个关于这方面的经验值，转载一下：

原文地址：http://book.51cto.com/art/201111/302506.htm

关于继承层次结构的宽度和深度，我们能说些什么呢？对于包含关系，我们声称，包含层次结构的宽度应当限制在6个类之内。这对继承是否合理呢？不合理。包含需要这条经验原则，这是因为类的额外的数据成员增加了类的方法的复杂性。但在我们的继承层次结构中给水果增加一个新的派生类型并没有给已经存在的类增加复杂性，因为每个派生类都是互相独立的，并且基类也应当独立于所有的派生类（经验原则5.2）。如果关于继承层次结构的宽度有什么经验原则的话，那么经验原则就是层次结构越宽越好（假定这些继承关系都是正确的）。一个宽的继承层次结构意味着很多类都利用了基类所表示的抽象。每个继承链接都消除了重复的设计和实现努力。但是，值得指出的是，我们在本章中讨论的很多继承陷阱都表现为宽的继承层次结构。

经验原则5.4

在理论上，继承层次体系应当深一点，越深越好。

这条经验原则的潜台词是，对抽象有了很深的分类法，那么新的派生类就可以从这个层次中尽可能深的类派生，从而利用更加细化的抽象。例如，让猕猴桃类从环太平洋热带水果类（这个类继承自热带水果类，热带水果类又继承自水果类）继承，要比直接从水果类继承更好。这样，随着继承层次的深入，猕猴桃类就可以表示越来越多的抽象。

经验原则5.5

在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。

有些项目的设计者在设计他们的面向对象系统的时候使用了"越深越好"的原则，但结果却发现实现者迷失在深深的继承层次结构之中（在这些案例中大概在12和17层之间）。这些开发者重新设计了他们的系统，减少了抽象细化，获得的继承层次结构大概只有5到7层深。所有的项目的开发者都发现，这样的深度更好。类似于关于包含层次结构的宽度的经验原则，数字6被认为是普通人可以保留在短期记忆中的事物的数目。有的设计者指出，这个问题的原因是缺乏工具。如果设计者有一个图形用户界面，可以通过这个界面点击一个派生类，显示出这个类所有继承而来的数据和接口，那么那条理论上的经验原则显然是这两条经验原则中更合适的。而没有了这样的工具，则意味着这条实践上的经验原则更合适。