由学习《软件设计重构》所想到的代码review

Posted 2022-09-24 小程故事多_80

我们接第一篇 由学习《软件设计重构》所想到的代码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()，这种造成的情况是将来可能在代码中的其他地方也会出现。

• 重构建议：

1、如果条件检查中的多个实现调用方法相同，可引入相关的接口来抽象共同的协议。
2、如果代码中包含可转换为类的条件语句，可采用重构手法“提取层次结构”来创建一个类层次结构，其中每个类都表示条件检查中的一种情形。

二、未归并层次结构

• 问题点：

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的关系。

四、小结

在第二篇中我们重点介绍了关于类层次结构方面的坏味道，那么我们将在第三篇中介绍关于封装类方面的故事。