### Change Unidirectional Association to Bidirectional(將單向關聯改為雙向)
兩個classes都需要使用對方特性,但其間只有一條單向連接(one-way link)。
添加一個反向指針,并使修改函數(modifiers)能夠同時更新兩條連接。(譯注:這里的指針等同于句柄(handle),修改函數(modifier)指的是改變雙方關系者)

**動機(Motivation)**
開發初期,你可能會在兩個classes之間建立一條單向連接,使其中一個可以引用另一個class。隨著時間推移,你可能發現referred class 需要得到其引用者(某個object)以便進行某些處理。也就是說它需要一個反向指針。但指針乃是一種單向連接,你不可能反向操作它。通常你可以繞道而行,雖然會耗費一些計算時間, 成本還算合理,然后你可以在referred class中建立一個專職函數,負責此一行為。 但是,有時候,想繞過這個問題并不容易,此時你就需要建立雙向引用關系(two-way reference),或稱為反向指針(back pointer)。如果你不習慣使用反向指針,它們很容易造成混亂;但只要你習慣了這種手法,它們其實并不是太復雜。
「反向指針」手法有點棘手,所以在你能夠自在運用它之前,應該有相應的測試。通常我不花心思去測試訪問函數(accessors),因為普通訪問函數的風險沒有高到需要測試的地步,但本重構要求測試訪問函數,所以它是極少數需要添加測試的重構 手法之一。
本重構運用反向指針(back pointer)實現雙向關聯(bidirectionality)。其他技術(例如連接對象,link object)需要其他重構手法。
**作法(Mechanics)**
- 在class中增加一個值域,用以保存「反向指針」。
- 決定由哪個class (引用端或被引用端)控制關聯性(association)。
- 在「被控端」建立一個輔助函數,其命名應該清楚指出它的有限用途。
- 如果既有的修改函數(modifier)在「控制端」,讓它負責更新反向指針。
- 如果既有的修改函數(modifier)在「被控端」,就在「控制端」建立一個控制函數,并讓既有的修改函數調用這個新建的控制函數。
**范例(Example)**
下面是一段簡單程序,其中有兩個classes:表示「定單」的Order 和表示「客戶」的Customer。Order引用了Customer,Customer則并沒有引用Order:
~~~
class Order...
Customer getCustomer() {
return _customer;
}
void setCustomer (Customer arg) {
_customer = arg;
}
Customer _customer;
~~~
首先,我要為Customer添加一個值域。由于一個客戶可以擁有多份定單,所以這個新增值域應該是個群集(collection)。我不希望同一份定單在同一個群集中出現一次以上,所以這里適合使用set:
~~~
class Customer {
private Set _orders = new HashSet();
~~~
現在,我需要決定由哪一個class負責控制關聯性(association)。我比較喜歡讓單一class來操控,因為這樣我就可以將所有「關聯處理邏輯」集中安置于一地。我將按照下列步驟做出這一決定:
1.
如果兩者都是reference objects,而其間的關聯是「一對多」關系,那么就由「擁有單一 reference 」的那一方承擔「控制者」角色。以本例而言,如果一個客戶可擁有多份定單,那么就由Order class (定單)來控制關聯性。
1.
如果某個對象是另一對象的組成(component),那么由后者負責控制關聯性。
1.
如果兩者都是reference objects,而其間的關聯是「多對多」關系,那么隨便其中哪個對象來控制關聯性,都無所謂。
本例之中由于Order負責控制關聯性,所以我必須為Customer添加一個輔助函數,讓Order可以直接訪問 _orders(訂單〕群集。Order的修改函數(modifier)將使用這個輔助函數對指針兩端對象進行同步控制。我將這個輔助函數命名為friendOrders() ,表示這個函數只能在這種特殊情況下使用。此外,如果Order和Customer位在同一個package內,我還會將friendOrders ()聲明為「package可見度」(譯注:亦即不加任何修飾符的缺省訪問級別),使其可見程度降到最低。
但如果這兩個classes不在同一個package內,我就只好把friendOrders() 聲明為public 了。
~~~
class Customer...
Set friendOrders() {
/** should only be used by Order when modifying the association */
return _orders;
}
~~~
現在,我要改變修改函數(modifier),令它同時更新反向指針:
~~~
class Order...
void setCustomer (Customer arg) ...
if (_customer != null) _customer.friendOrders().remove(this);
_customer = arg;
if (_customer != null) _customer.friendOrders().add(this);
}
~~~
classes 之間的關聯性是各式各樣的,因此修改函數(modifier )的代碼也會隨之有所差異。如果_customer 的值不可能是null ,我可以拿掉上述的第一個null 檢查, 但仍然需要檢查引數(argument)是否為null 。不過,基本形式總是相同的:先讓對方刪除「指向你」的指針,再將你的指針指向一個新對象,最后讓那個新對象把 它的指針指向你。
如果你希望在Customer 中也能修改連接(link),就讓它調用控制函數:
~~~
class Customer...
void addOrder(Order arg) {
arg.setCustomer(this);
}
~~~
如果一份定單也可以對應多個客戶,那么你所面臨的就是一個「多對多」情況,重構后的函數可能是下面這樣:
~~~
class Order... //controlling methods
void addCustomer (Customer arg) {
arg.friendOrders().add(this);
_customers.add(arg);
}
void removeCustomer (Customer arg) {
arg.friendOrders().remove(this);
_customers.remove(arg);
}
class Customer...
void addOrder(Order arg) {
arg.addCustomer(this);
}
void removeOrder(Order arg) {
arg.removeCustomer(this);
}
~~~
- 譯序 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 )
- 小結
- 章節十五 集成
- 參考書目