【Java重构系列】重构31式之搬移方法

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/LoveLion/article/details/18092559

重构第二式：搬移方法 (Refactoring 2: Move Method)

      

       毋容置疑，搬移方法(Move Method)应该是最常用的重构手段之一，正因为太常用而且较为简单，以至于很多人并不认为它是一种很有价值的重构，但事实并非如此，在最初的代码诞生之后，有些方法可能会被放在一些不合适的地方，例如，一个方法被其他类使用比在它所在的类中的使用还要频繁或者一个方法本身就不应该放在某个类中时，我们应该考虑将它移到更合适的地方。搬移方法，顾名思义就是将方法搬移至合适的位置，如将方法搬移到更频繁地使用它的类中。与搬移方法相似的还有一种重构手段是搬移字段(Move Field)，即搬移属性。

       在《重构：改善既有代码的设计》一书中，多种坏味都需要使用搬移方法来进行重构，例如依恋情结(Feature Envy)、霰弹式修改(Shotgun Surgery)、平行继承结构(Parallel Inheritance Hierarchies)、异曲同工的类(Alternative Classes with DifferentInterfaces)、狎昵关系(Inappropriate Intimacy)、纯稚的数据类(Data Class)等，通过搬移方法(Move Method)或者搬移字段(Move Field)，可以让某些代码待在更合适的位置。因此，Martin Fowler在《重构》一书中指出，“搬移方法”是重构理论的支柱（Moving methods is the bread and butter of refactoring.），可见该重构的重要性。

       下面举一个例子来加以说明：

【重构实例】

       在某银行系统中包含一个银行账户类BankAccount和账户利息类AccountInterest，重构之前的代码如下：

package sunny.refactoring.two.before;

class BankAccount {
	private int accountAge;
	private int creditScore;
	private AccountInterest accountInterest;
	
	public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest) {
		this.accountAge = accountAge;
		this.creditScore = creditScore;
		this.accountInterest = accountInterest;
	}
	
	public int getAccountAge() {
		return this.accountAge;
	}
	
	public int getCreditScore() {
		return this.creditScore;
	}
	
	public AccountInterest getAccountInterest() {
		return this.accountInterest;
	}
	
	public double calculateInterestRate() {
		if (this.creditScore > 800) {
			return 0.02;
		}
		
		if (this.accountAge > 10) {
			return 0.03;
		}
		
		return 0.05;
	}
}

class AccountInterest {
	private BankAccount account;
	
	public AccountInterest(BankAccount account) {
		this.account = account;
	}
	
	public BankAccount getAccount() {
		return this.account;
	}
	
	public double getInterestRate() {
		return account.calculateInterestRate();
	}
	
	public boolean isIntroductoryRate() {
		return (account.calculateInterestRate() < 0.05);
	}
}

       在上述代码中，很明显，AccountInterest使用calculateInterestRate()方法更为频繁，它更希望得到该方法，因此，我们需要成人之美，，将calculateInterestRate()方法从BankAccount类搬移到AccountInterest类中。

       重构之后的代码如下：

package sunny.refactoring.two.after;

class BankAccount {
	private int accountAge;
	private int creditScore;
	private AccountInterest accountInterest;
	
	public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest) {
		this.accountAge = accountAge;
		this.creditScore = creditScore;
		this.accountInterest = accountInterest;
	}
	
	public int getAccountAge() {
		return this.accountAge;
	}
	
	public int getCreditScore() {
		return this.creditScore;
	}
	
	public AccountInterest getAccountInterest() {
		return this.accountInterest;
	}
}

class AccountInterest {
	private BankAccount account;
	
	public AccountInterest(BankAccount account) {
		this.account = account;
	}
	
	public BankAccount getAccount() {
		return this.account;
	}
	
	public double getInterestRate() {
		return calculateInterestRate();
	}
	
	public boolean isIntroductoryRate() {
		return (calculateInterestRate() < 0.05);
	}
	
	//将calculateInterestRate()方法从BankAccount类搬移到AccountInterest类
    public double calculateInterestRate() {
		if (account.getCreditScore() > 800) {
			return 0.02;
		}
		
		if (account.getAccountAge() > 10) {
			return 0.03;
		}
		
		return 0.05;
	}
}

       通过重构，BankAccount类更加符合单一职责原则，它负责存储银行账户信息，而对账户的操作（例如计算利息等）方法则转移到其他经常使用且适合它的类中，这样让代码变得更加合理，也有助降低类之间的耦合度，增强代码的可扩展性和可维护性。

 

重构心得：

       搬移方法是一种非常实用的重构手段。在本实例中，我们是将方法搬移到被调用次数最多的那个类中，在实际代码重构过程中，还有很多其他涉及到需要搬移方法的场景。

       有一种代码味道叫做依恋情结(Feature Envy)，指的是一个方法对某个类的兴趣高过对自己所处类的兴趣，例如某个方法需要访问另一个类中大量的数据成员，此时，也非常适合使用搬移方法重构。让方法能够前往它的梦想王国不是件很有意义的事情吗？如果一个方法用到了多个类的功能，那么这个方法放在哪个类中更合适呢？常用的做法是判断哪个类拥有最多被此方法使用的数据，然后将这个方法和那些数据放在一起。在这种情况下，搬移方法的时机不是判断它被哪个类调用更多，而是判断它更需要哪个类提供的数据，这跟上面的重构实例有些区别。

       有时候搬移方法时，还需要将只被这个（或这些）方法使用的数据和其他方法一起搬移，需要认真检查方法中使用到的属性（字段）和其他方法，必要时同时执行搬移字段重构(Move Field)。

       如果搬移后的方法需要访问原有类中的属性或者方法，可以将原有类的对象作为参数传入新类，在这个过程中可能还需要修改原有类中某些属性或方法的可见性，毕竟它们已经分家了，原有的一些私有的东西是不能再直接访问的。

       如果在继承结构中，需要搬移的方法声明在抽象层中，此时要慎重使用本重构，如果太麻烦建议就不要搬移了，免得引入太多错误，毕竟我们要保证抽象层的相对稳定性。

       如果有需要，可以为搬移后的函数重新取一个名字，以提高代码的可读性。

       如果原有类还需要用到这个已经搬移走的方法，可以通过在原有类中提供一个委托方法的形式来实现，例如method() { TargetClass tc = new TargetClass (); tc.method();}，如果原有类中的多个方法（当然也不能太多，否则就没有必要搬走了）需要使用已搬移走的方法，也可以考虑在原有类中增加一个目标类（搬移之后所在类）的对象引用，通过该引用来调用搬走的方法。

       当一个类的职责太多时，为了分解类的职责，也可能需要将一些职责搬移到其他类中，此时也需要执行搬移方法重构。这样做，系统将更加满足单一职责原则，有利于提高代码的可复用性和易理解性。

       虽然搬移方法是一种简单的重构手段，但是在实际使用中很多人经常会遇到一个问题，如何确定和寻找重构时机？也就是不知道什么时候该用搬移方法来进行重构，特别是当系统较为复杂，类和方法个数非常多时，要准确识别出重构时机并不是一件简单的事情。

       希腊马其顿大学(University of Macedonia)学者Nikolaos Tsantalis和Alexander Chatzigeorgiou在搬移方法重构时机识别上开展了相关研究，并在软件工程国际顶级期刊IEEE Transactions on Software Engineering（PS：该期刊是Sunny的2014年目标之一，，加油！）上发表了他们的研究成果，在他们的重构时机识别过程中，使用了Jaccard距离(Jaccard distance)来计算一个待搬移的实体（方法或者属性）和一个类的距离，distance(A, B) = 1 – (|A∩B|/|A∪B|) = 1 – similarity(A,B)，将实体搬移到距离最小的类中，他们实现了一个名为JDeodorant的Eclipse插件来实现重构时机识别的半自动化。JDeodorant介绍URL：http://java.uom.gr/~jdeodorant/；JDeodorant安装URL：http://marketplace.eclipse.org/content/jdeodorant。关于这篇论文Sunny就不加详细说明了，爱学习且英语好的童鞋可以自己下载看看(Identification of Move Method Refactoring Opportunities)，。

  

【作者：刘伟  http://blog.csdn.net/lovelion】