### Move Field(搬移值域)
(譯注:本節大量保留class,method,source,target等字眼)
你的程序中,某個field(值域〕被其所駐class之外的另一個class更多地用到。
在target class 建立一個new field,修改source field的所有用戶,令它們改用此new field。

**動機(Motivation)**
在classes之間移動狀態(states)和行為,是重構過程中必不可少的措施。隨著系統發展,你會發現自己需要新的class,并需要將原本的工作責任拖到新的class中。這個星期中合理而正確的設計決策,到了下個星期可能不再正確。這沒問題;如果你從來沒遇到這種情況,那才有問題。
如果我發現,對于一個field(值域),在其所駐class之外的另一個class中有更多函數使用了它,我就會考慮搬移這個field。上述所謂「使用」可能是通過設值/取值(setting/getting)函數間接進行。我也可能移動該field的用戶(某函數),這取決于是否需要保持接口不受變化。如果這些函數看上去很適合待在原地,我就選擇搬移field。
使用Extract Class 時,我也可能需要搬移field。此時我會先搬移field,然后再搬移函數。
**作法(Mechanics)**
- 如果field的屬性是public,首先使用Encapsulate Field 將它封裝起來。
- 如果你有可能移動那些頻繁訪問該field的函數,或如果有許多函數訪問某個field,先使用Self Encapsulate Field 也許會有幫助。
- 編譯,測試。
- 在target class中建立與source field相同的field,并同時建立相應的設值/取值 (setting/getting)函數。
- 編譯target class。
- 決定如何在source object中引用target object。
- 一個現成的field或method可以助你得到target object。如果沒有,就看能否輕易建立這樣一個函數。如果還不行,就得在source class中新建一個field來存放target object。這可能是個永久性修改,但你也可以暫不公開它,因為后續重構可能會把這個新建field除掉。
- 刪除source field。
- 將所有「對source field的引用」替換為「對target適當函數的調用」。
- 如果是「讀取」該變量,就把「對source field的引用」替換為「對target取值函數(getter)的調用」;如果是「賦值」該變量,就把對source field的引用」替換成「對設值函數(setter)的調用」。
- 如果source field不是private,就必須在source class的所有subclasses中查找source field的引用點,并進行相應替換。
- 編譯,測試。
**范例(Examples)**
下面是Account class的部分代碼:
~~~
class Account...
private AccountType _type;
private double _interestRate;
double interestForAmount_days (double amount, int days) {
return _interestRate * amount * days / 365;
}
~~~
我想把表示利率的_interestRate搬移到AccountType class去。目前已有數個函數引用了它,interestForAmount_days() 就是其一。下一步我要在AccountType中建立_interestRate field以及相應的訪問函數:
~~~
class AccountType...
private double _interestRate;
void setInterestRate (double arg) {
_interestRate = arg;
}
double getInterestRate () {
return _interestRate;
}
~~~
這時候我可以編譯新的AccountType class。
現在,我需要讓Account class中訪問此_interestRate field的函數轉而使用AccountType對象,然后刪除Account class中的_interestRate field。我必須刪除source field,才能保證其訪問函數的確改變了操作對象,因為編譯器會幫我指出未正確獲得修改的函數。
~~~
private double _interestRate;
double interestForAmount_days (double amount, int days) {
return _type.getInterestRate() * amount * days / 365;
}
~~~
**范例:使用Self Encapsulate(自我封裝)**
如果有很多函數已經使用了_interestRate field,我應該先運用Self Encapsulate Field:
~~~
class Account...
private AccountType _type;
private double _interestRate;
double interestForAmount_days (double amount, int days) {
return getInterestRate() * amount * days / 365;
}
private void setInterestRate (double arg) {
_interestRate = arg;
}
private double getInterestRate () {
return _interestRate;
}
~~~
這樣,在搬移field之后,我就只需要修改訪問函數(accessors)就行了 :
~~~
double interestForAmountAndDays (double amount, int days) {
return getInterestRate() * amount * days / 365;
}
private void setInterestRate (double arg) {
_type.setInterestRate(arg);
}
private double getInterestRate () {
return _type.getInterestRate();
}
~~~
如果以后有必要,我可以修改訪問函數(accessors)的用戶,讓它們使用新對象。 Self Encapsulate Field 使我得以保持小步前進。如果我需要對做許多處理,保持小步前進是有幫助的。特別值得一提的是:首先使用Self Encapsulate Field 使我得以更輕松使用Move Method 將函數搬移到target class中。如果待移函數引用了field的訪問函數(accessors),那么那些引用點是無須修 改的。
- 譯序 by 侯捷
- 譯序 by 熊節
- 序言
- 前言
- 章節一 重構,第一個案例
- 起點
- 重構的第一步
- 分解并重組statement()
- 運用多態(Polymorphism)取代與價格相關的條件邏輯
- 結語
- 章節二 重構原則
- 何謂重構
- 為何重構
- 「重構」助你找到臭蟲(bugs)
- 何時重構
- 怎么對經理說?
- 重構的難題
- 重構與設計
- 重構與性能(Performance)
- 重構起源何處?
- 章節三 代碼的壞味道
- Duplicated Code(重復的代碼)
- Long Method(過長函數)
- Large Class(過大類)
- Long Parameter List(過長參數列)
- Divergent Change(發散式變化)
- Shotgun Surgery(散彈式修改)
- Feature Envy(依戀情結)
- Data Clumps(數據泥團)
- Primitive Obsession(基本型別偏執)
- Switch Statements(switch驚悚現身)
- Parallel Inheritance Hierarchies(平行繼承體系)
- Lazy Class(冗贅類)
- Speculative Generality(夸夸其談未來性)
- Temporary Field(令人迷惑的暫時值域)
- Message Chains(過度耦合的消息鏈)
- Middle Man(中間轉手人)
- Inappropriate Intimacy(狎昵關系)
- Alternative Classes with Different Interfaces(異曲同工的類)
- Incomplete Library Class(不完美的程序庫類)
- Data Class(純稚的數據類)
- Refused Bequest(被拒絕的遺贈)
- Comments(過多的注釋)
- 章節四 構筑測試體系
- 自我測試代碼的價值
- JUnit測試框架
- 添加更多測試
- 章節五 重構名錄
- 重構的記錄格式
- 尋找引用點
- 這些重構準則有多成熟
- 章節六 重新組織你的函數
- Extract Method(提煉函數)
- Inline Method(將函數內聯化)
- Inline Temp(將臨時變量內聯化)
- Replace Temp with Query(以查詢取代臨時變量)
- Introduce Explaining Variable(引入解釋性變量)
- Split Temporary Variable(剖解臨時變量)
- Remove Assignments to Parameters(移除對參數的賦值動作)
- Replace Method with Method Object(以函數對象取代函數)
- Substitute Algorithm(替換你的算法)
- 章節七 在對象之間搬移特性
- Move Method(搬移函數)
- Move Field(搬移值域)
- Extract Class(提煉類)
- Inline Class(將類內聯化)
- Hide Delegate(隱藏「委托關系」)
- Remove Middle Man(移除中間人)
- Introduce Foreign Method(引入外加函數)
- Introduce Local Extension(引入本地擴展)
- 章節八 重新組織數據
- Self Encapsulate Field(自封裝值域)
- Replace Data Value with Object(以對象取代數據值)
- Change Value to Reference(將實值對象改為引用對象)
- Replace Array with Object(以對象取代數組)
- Replace Array with Object(以對象取代數組)
- Duplicate Observed Data(復制「被監視數據」)
- Change Unidirectional Association to Bidirectional(將單向關聯改為雙向)
- Change Bidirectional Association to Unidirectional(將雙向關聯改為單向)
- Replace Magic Number with Symbolic Constant(以符號常量/字面常量取代魔法數)
- Encapsulate Field(封裝值域)
- Encapsulate Collection(封裝群集)
- Replace Record with Data Class(以數據類取代記錄)
- Replace Type Code with Class(以類取代型別碼)
- Replace Type Code with Subclasses(以子類取代型別碼)
- Replace Type Code with State/Strategy(以State/strategy 取代型別碼)
- Replace Subclass with Fields(以值域取代子類)
- 章節九 簡化條件表達式
- Decompose Conditional(分解條件式)
- Consolidate Conditional Expression(合并條件式)
- Consolidate Duplicate Conditional Fragments(合并重復的條件片段)
- Remove Control Flag(移除控制標記)
- Replace Nested Conditional with Guard Clauses(以衛語句取代嵌套條件式)
- Replace Conditional with Polymorphism(以多態取代條件式)
- Introduce Null Object(引入Null 對象)
- Introduce Assertion(引入斷言)
- 章節十一 處理概括關系
- Pull Up Field(值域上移)
- Pull Up Method(函數上移)
- Pull Up Constructor Body(構造函數本體上移)
- Push Down Method(函數下移)
- Push Down Field(值域下移)
- Extract Subclass(提煉子類)
- Extract Superclass(提煉超類)
- Extract Interface(提煉接口)
- Collapse Hierarchy(折疊繼承關系)
- Form Template Method(塑造模板函數)
- Replace Inheritance with Delegation(以委托取代繼承)
- Replace Delegation with Inheritance(以繼承取代委托)
- 章節十二 大型重構
- 這場游戲的本質
- Tease Apart Inheritance(梳理并分解繼承體系)
- Convert Procedural Design to Objects(將過程化設計轉化為對象設計)
- Separate Domain from Presentation(將領域和表述/顯示分離)
- Extract Hierarchy(提煉繼承體系)
- 章節十三 重構,復用與現實
- 現實的檢驗
- 為什么開發者不愿意重構他們的程序?
- 現實的檢驗(再論)
- 重構的資源和參考資料
- 從重構聯想到軟件復用和技術傳播
- 結語
- 參考文獻
- 章節十四 重構工具
- 使用工具進行重構
- 重構工具的技術標準(Technical Criteria )
- 重構工具的實用標準(Practical Criteria )
- 小結
- 章節十五 集成
- 參考書目