前言
对于一个程序员来讲如何来最直接的来衡量他的技术能力和产出呢？我想最直观的作法是看他的代码编写能力，就拿我经常接触的一些程序员来看，他们买了很多技术重构类书籍，但是看完后代码编写能力并没有显著提高。有人说可以用代码review工具啊，但是像市面上的这些代码review工具，只能帮助我们解决表面的bug和规范点，还无法帮助我们发现更深层次的设计问题。
上一篇《由学习《软件设计重构》所想到的代码review（一）》我结合《软件设计重构》这本书谈谈在进行代码review的时候，需要关注的哪些点，这一篇来继续说明在代码review中，有哪些属于“层次结构”中的坏味道。
注：通过上图咱们看到了在层次结构中有九大问题点，咱们就从中找出四个典型的问题点给与分析和解释。
一、缺失的层次结构
问题点：
public Insets getBorderInsets(Component c， Insets insets) { if(c instanceof AbstractButton) {
margin = ((AbstractButton)c).getMargin();
} else if(c instanceof JToolBar) {
margin = ((JToolBar)c).getMargin();
} else if(c instanceof JTextComponent) {
margin = ((JTextComponent)c).getMargin();
}
注：串接的if else语句显示的检查类型AbstractButton，JToolBar和JTextCompont并在各种条件下调用方法getMargin()，这种造成的情况是将来可能在代码中的其他地方也会出现。
重构建议：
-
如果条件检查中的多个实现调用方法相同，可引入相关的接口来抽象共同的协议。
-
如果代码中包含可转换为类的条件语句，可采用重构手法“提取层次结构”来创建一个类层次结构，其中每个类都表示条件检查中的一种情形。
二、未归并层次结构
问题点：
AbstractQueuedSynchronizer和AbstractQueuedLongSynchronizer类都是直接从AbstractOwnableSynchronizer派生而来的（这些类都包含在java.util.concurrent.locks包），这二个子类的很多代码都是重复的，每个类都包含2110行代码，但重复的代码多达1278行。
显然，这二个类的代码绝大部分是相同的，只是在AbstractQueuedLongSynchronizer中使用的是long而不是int，那么我们看这二个类的继承类图如下：
重构方案
对于AbstractOwnableSynchronizer，由于子类型中的方法定义相同，因此可采用重构手法上移，将相同的方法定义移到超类中。
三、支离破碎的层次结构
这种层次结构主要体现在，虽然超类和子类之间不存在is-a的关系，但是超类的方法对于子类来说是适用或者相关的。
问题点：
注：java.util.Date这个类不仅提供了日期功能，如getDate()，getYeah()等方法，还提供了getTime()，getHours()等时间方法，但是它的二个子类java.sql.Date不支持与时间有关的功能，而java.sql.Time不支持与日期有关的功能，于是java.sql.Date拒绝了从超类继承的所有与时间有关的方法，java.sql.Time拒绝了继承的所有与日期有关的方法。
看一段简单的代码：
java.util.Date date = new java.util.Date();
int dateValue = date.getDate(); //不报错，一切正常
date = new java.sql.Time(10,10,10);
dateValue = date.getDate(); //将引发IllegalArgumentException异常
重构方案：
超类和子类之间并不存在is-a的关系，它们在设计中使用继承只是为了能够利用抽象提供的功能，其实在相关类之间建立关联关系也可以达到这样的目的，采用重构手法”以委拖取代继承”，应用hash-a的关系取代is-a的关系。
总结
在第二篇中我们重点介绍了关于类层次结构方面的坏味道，那么我们将在第三篇中介绍关于封装类方面的故事。
来源：中生代技术
