《31天重构》6:下置类属性

相对于上一种重构方式“提升类属性”，现在是“下置类属性”，即当一个父类中的某个属性字段不是对于每一个子类都必需时，就应该将其下置到具体使用到该属性的子类中去，以避免该属性被所有子类继承下来。

重构前的代码例子：

abstract class Task{
	protected String resolution;
}

class BugTask extends Task {
	
}

class FeatureTask extends Task {
	
}

  在这个例子中，我们知道 FeatureTask 类不需要具有表明 resolution （解决方案）的类属性，它只为 BugTask 类所必需（代码中有 Bug 还不改的话会是怎样的后果？）。因此，只需要很简单地将 resolution 属性下置到子类 BugTask 中即可。 

重构后的代码：

abstract class Task{
	//protected String resolution;
}

class BugTask extends Task {
	private String resolution;
}

class FeatureTask extends Task {
	
}

 
小结：在前面这几种重构方式中，我认为都是与抽象出共性，或者是确定特殊子类的特殊行为、属性相关的。这四种重构方式，都表明了在设计时最好先分析、评判好各个类的职责（行为、方法）、个性（属性、字段），这样就能够避免在后期引起一系列麻烦的重构。

在我看来，虽然文章中说的是重构，但我更偏向于将这几种方式作为设计时必须考虑到的，而不是简单地将其遗留到重构这一阶段才进行考虑。

百度百科中关于“重构与设计”的说法：“重构与设计是互补的,程序应该是先设计,而在开始编码后,设计上的不足可以用重构来弥补。设计应该是适度的设计,而不必过度的设计。如果能很容易的通过重构来适应需求的变化,那么就不必过度的设计,当需求改变时再重构代码。”

虽然说“设计上的不足可以用重构来弥补”，但是我记得上次在写一个简单的程序时，就是因为在父类中设计了一个所有子类都可共享的属性，最后在程序准备运行观察效果时发现就是这个共享的属性带来了一系列问题。当时我觉得自己不是在重构，几乎是在重写、修改相当一部分的代码了，消耗的时间也可想而知…

原文链接：http://www.lostechies.com/blogs/sean_chambers/archive/2009/08/06/refactoring-day-6-push-down-field.aspx