### Change Value to Reference(將實值對象改為引用對象)
你有一個class,衍生出許多相等實體(equal instances),你希望將它們替換為單一對象。
將這個value object (實值對象)變成一個reference object (引用對象)。

**動機(Motivation)**
在許多系統中,你都可以對對象做一個有用的分類:reference object和value objects。前者就像「客戶」、「帳戶」這樣的東西,每個對象都代表真實世界中的一個實物,你可以直接以相等操作符(==,用來檢驗同一性,identity)檢査兩個對象 是否相等。后者則是像「日期」、「錢」這樣的東西,它們完全由其所含的數據值來定義,你并不在意副本的存在;系統中或許存在成百上千個內容為"1/1/2000"的「日期」對象。當然,你也需要知道兩個value objects是否相等,所以你需要覆寫equals()和hashCode())。
要在reference object和value objects之間做選擇有時并不容易。有時候,你會從一個簡單的value objects開始,在其中保存少量不可修改的數據。而后,你可能會希望給這個對象加入一些可修改數據,并確保對任何一個對象的修改都能影響到所有引用此一對象的地方。這時候你就需要將這個對象變成一個reference object。
**作法(Mechanics)**
- 使用Replace Constructor with Factory Method。
- 編譯,測試。
- 決定由什么對象負責提供訪問新對象的途徑。
- 可能是個靜態字典(static dictionary)或一個注冊對象(registry object)。
- 你也可以使用多個對象作為新對象的訪問點(access point)。
- 決定這些reference object應該預先創建好,或是應該動態創建。
- 如果這些reference object是預先創建好的,而你必須從內存中將它們讀取出來,那么就得確保它們在被需要的時候能夠被及時加載。
- 修改factory method[5],令它返回reference object。
- 如果對象是預先創建好的,你就需要考慮:萬一有人索求一個其實并不存在的對象,要如何處理錯誤?
- 你可能希望對factory method使用Rename Method,使其傳達這樣的信息:它返回的是一個既存對象。
- 編譯,測試。
[5]譯注:此處之factory method不等同于GoF在《Design Patterns》書中提出的Factory Method。為避免混淆,讀者應該將此處的factory method理解為"Creational Method",亦即「用以創建某種實體」的函數,這個概念包含GoF的Factory Method,而又比Factory Method廣泛。
**范例(Example)**
在Replace Data Value with Object 一節中,我留下了一個重構后的程序,本節范例就從它開始。我們有下列的Customer class:
~~~
class Customer {
public Customer (String name) {
_name = name;
}
public String getName() {
return _name;
}
private final String _name;
}
~~~
它被以下的Ordre class使用:
~~~
class Order...
public Order (String customerName) {
_customer = new Customer(customerName);
}
public void setCustomer(String customerName) {
_customer = new Customer(customerName);
}
public String getCustomerName() {
return _customer.getName();
}
private Customer _customer;
~~~
此外,還有一些代碼也會使用Customer對象:
~~~
private static int numberOfOrdersFor(Collection orders, String customer) {
int result = 0;
Iterator iter = orders.iterator();
while (iter.hasNext()) {
Order each = (Order) iter.next();
if (each.getCustomerName().equals(customer)) result++;
}
return result;
}
~~~
到目前為止,Customer對象還是value object。就算多份定單屬于同一客戶,但每個Order對象還是擁有各自的Customer對象。我希望改變這一現狀,使得一旦同 一客戶擁有多份不同定單,代表這些定單的所有Order對象就可以共享同一個Customer對象。本例中這就意味:每一個客戶名稱只該對應一個Customer對象。
首先我使用 Replace Constructor with Factory Method。這樣,我就可以控制Customer對象的創建過程,這在以后會是非常重要的。我在Customer class中定義這個factory method:
~~~
class Customer {
public static Customer create (String name) {
return new Customer(name);
}
~~~
然后我把「對構造函數的調用」替換成「對factory method的調用」:
~~~
class Order {
public Order (String customer) {
_customer = Customer.create(customer);
}
~~~
然后我再把構造函數聲明為private:
~~~
class Customer {
private Customer (String name) {
_name = name;
}
~~~
現在,我必須決定如何訪問Customer對象。我比較喜歡通過另一個對象(例如Order class中的一個值域)來訪問它。但是本例并沒有這樣一個明顯的值域可用于訪問Customer對象。在這種情況下,我通過會創建一個注冊(登錄)對象,作為訪問點。為了簡化我們的例子,我把Customer對象保存在Customer class的一個static值域中,讓Customer class作為訪問點:
~~~
private static Dictionary _instances = new Hashtable();
~~~
然后我得決定:應該在接到請求時創建新的Customer對象,還是應該預先將它們創建好。這里我選擇后者。在應用程序的啟動代碼(start-up code)中,我先把需要使用的Customer對象加載妥當。這些對象可能來自數據庫,也可能來自文件。為求簡單起見,我在代碼中明確生成這些對象。反正以后我總是可以使用 Substitute Algorithm 來改變它們的創建方式。
~~~
class Customer...
static void loadCustomers() {
new Customer ("Lemon Car Hire").store();
new Customer ("Associated Coffee Machines").store();
new Customer ("Bilston Gasworks").store();
}
private void store() {
_instances.put(this.getName(), this);
}
~~~
現在,我要修改factory method,讓它返回預先創建好的Customer對象:
~~~
public static Customer create (String name) {
return (Customer) _instances.get(name);
}
~~~
由于create()總是返回既有的Customer對象,所以我應該使用Rename Method 修改這個factory method的名稱,以便強調(說明)這一點。
~~~
class Customer...
public static Customer getNamed (String name) {
return (Customer) _instances.get(name);
}
~~~
- 譯序 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 )
- 小結
- 章節十五 集成
- 參考書目