“重构行为可以使责任的分配更为合理,使代码的维护更加轻松。 重构之后风格会迥异于过程化风格-后者也许是某些人习惯的风格。”
“重构的节奏一般是测试,小修改,测试,小修改,测试,小修改..”
如果没有重构,程序的设计会逐渐腐败变质。 当人们只为短期目的或是在完全理解整体设计之前就贸然修改代码,程序将逐渐失去自己的结构。代码结构的流失是累积性的。
关于 “对象应该直接访问其中的数据,抑或应该通过访问函数来访问” 这一问题,争论的声音从来不曾停止。
间接访问变量
public class AccountDetails {
private String email;
public String getEmail() {
return email;
}
}public class AccountDetails {
private String email;
public String getEmail() {
return isBackUpEmail() ? null : email;
}
private isBackUpEmail() {
...
}
}间接访问变量的好处:
public class AccountDetails {
private String email;
private BigData bigData;
public BigData getBigData() {
if(bigData) {
bigData = fetchFromDB();
}
return bigData;
}
..
}直接访问变量
public class AccountDetails {
public String email;
}直接访问变量的好处:
究竟选择哪种方式呢?
面临选择时, 1. 按照团队中其他人的意愿来做。 2. 就我自己而言,我比较喜欢先使用直接访问方式,直到这种方式给我带来麻烦为止,此时我就会转而使用间接访问方式。重构给了我改变主意的自由。 Example: 如果你想访问超类中的一个字段,却又想在子类中将对这个变量的访问改为一个计算后的值,这就是最该使用SelfEncapsulateField(自封装字段)的时候。“字段自我封装”只是第一步。完成自我封装之后,你可以在子类中根据自己的需要随意覆写取值/设值函数。
public class ApplicationInfo {
private UUID id;
private List<Txxxxt> txxxxts;
...
public void setTxxxxts(List<Txxxxt> txxxxts) {
this.txxxxts = txxxxts
}
}public class ApplicationInfo {
private UUID id;
private List<Txxxxt> txxxxts;
...
public List<Txxxxt> getTxxxxts() {
return txxxxts
}
}public class Txxxxt {
...
// 自己实现clone方法
public Object clone() {
..
}
}public class ApplicationInfo {
private UUID id;
private List<Txxxxt> txxxxts;
...
//伪代码
public void setTxxxxts(List<Txxxxt> txxxxts) {
txxxxts.foreach( t-> this.txxxxts.add(t.clone))
}
}