16.4 改進設計<br>
《Design Patterns》書內所有方案的組織都圍繞“程序進化時會發生什么變化”這個問題展開。對于任何設計來說，這都可能是最重要的一個問題。若根據對這個問題的回答來構造自己的系統，就可以得到兩個方面的結果：系統不僅更易維護（而且更廉價），而且能產生一些能夠重復使用的對象，進而使其他相關系統的構造也變得更廉價。這正是面向對象程序設計的優勢所在，但這一優勢并不是自動體現出來的。它要求對我們對需要解決的問題有全面而且深入的理解。在這一節中，我們準備在系統的逐步改進過程中向大家展示如何做到這一點。<br>
就目前這個回收系統來說，對“什么會變化”這個問題的回答是非常普通的：更多的類型會加入系統。因此，設計的目標就是盡可能簡化這種類型的添加。在回收程序中，我們準備把涉及特定類型信息的所有地方都封裝起來。這樣一來（如果沒有別的原因），所有變化對那些封裝來說都是在本地進行的。這種處理方式也使代碼剩余的部分顯得特別清爽。<br>
<br>
16.4.1 “制作更多的對象”<br>
這樣便引出了面向對象程序設計時一條常規的準則，我最早是在Grady 
Booch那里聽說的：“若設計過于復雜，就制作更多的對象”。盡管聽起來有些曖昧，且簡單得可笑，但這確實是我知道的最有用一條準則（大家以后會注意到“制作更多的對象”經常等同于“添加另一個層次的迂回”）。一般情況下，如果發現一個地方充斥著大量繁復的代碼，就需要考慮什么類能使它顯得清爽一些。用這種方式整理系統，往往會得到一個更好的結構，也使程序更加靈活。<br>
首先考慮Trash對象首次創建的地方，這是main()里的一個switch語句：<br>
<br>
919-920頁程序<br>
<br>
這些代碼顯然“過于復雜”，也是新類型加入時必須改動代碼的場所之一。如果經常都要加入新類型，那么更好的方案就是建立一個獨立的方法，用它獲取所有必需的信息，并創建一個句柄，指向正確類型的一個對象——已經上溯造型到一個Trash對象。在《Design 
Patterns》中，它被粗略地稱呼為“創建范式”。要在這里應用的特殊范式是Factory方法的一種變體。在這里，Factory方法屬于Trash的一名static（靜態）成員。但更常見的一種情況是：它屬于衍生類中一個被過載的方法。<br>
Factory方法的基本原理是我們將創建對象所需的基本信息傳遞給它，然后返回并等候句柄（已經上溯造型至基礎類型）作為返回值出現。從這時開始，就可以按多形性的方式對待對象了。因此，我們根本沒必要知道所創建對象的準確類型是什么。事實上，Factory方法會把自己隱藏起來，我們是看不見它的。這樣做可防止不慎的誤用。如果想在沒有多形性的前提下使用對象，必須明確地使用RTTI和指定造型。<br>
但仍然存在一個小問題，特別是在基礎類中使用更復雜的方法（不是在這里展示的那種），且在衍生類里過載（覆蓋）了它的前提下。如果在衍生類里請求的信息要求更多或者不同的參數，那么該怎么辦呢？“創建更多的對象”解決了這個問題。為實現Factory方法，Trash類使用了一個新的方法，名為factory。為了將創建數據隱藏起來，我們用一個名為Info的新類包含factory方法創建適當的Trash對象時需要的全部信息。下面是Info一種簡單的實現方式：<br>
<br>
920-921頁程序<br>
<br>
Info對象唯一的任務就是容納用于factory()方法的信息。現在，假如出現了一種特殊情況，factory()需要更多或者不同的信息來新建一種類型的Trash對象，那么再也不需要改動factory()了。通過添加新的數據和構建器，我們可以修改Info類，或者采用子類處理更典型的面向對象形式。<br>
用于這個簡單示例的factory()方法如下：<br>
<br>
921頁上程序<br>
<br>
在這里，對象的準確類型很容易即可判斷出來。但我們可以設想一些更復雜的情況，factory()將采用一種復雜的算法。無論如何，現在的關鍵是它已隱藏到某個地方，而且我們在添加新類型時知道去那個地方。<br>
新對象在main()中的創建現在變得非常簡單和清爽：<br>
<br>
921頁下程序<br>
<br>
我們在這里創建了一個Info對象，用于將數據傳入factory()；后者在內存堆中創建某種Trash對象，并返回添加到Vector 
bin內的句柄。當然，如果改變了參數的數量及類型，仍然需要修改這個語句。但假如Info對象的創建是自動進行的，也可以避免那個麻煩。例如，可將參數的一個Vector傳遞到Info對象的構建器中（或直接傳入一個factory()調用）。這要求在運行期間對參數（自變量）進行分析與檢查，但確實提供了非常高的靈活程度。<br>
大家從這個代碼可看出Factory要負責解決的“領頭變化”問題：如果向系統添加了新類型（發生了變化），唯一需要修改的代碼在Factory內部，所以Factory將那種變化的影響隔離出來了。<br>
<br>
16.4.2 用于原型創建的一個范式<br>
上述設計方案的一個問題是仍然需要一個中心場所，必須在那里知道所有類型的對象：在factory()方法內部。如果經常都要向系統添加新類型，factory()方法為每種新類型都要修改一遍。若確實對這個問題感到苦惱，可試試再深入一步，將與類型有關的所有信息——包括它的創建過程——都移入代表那種類型的類內部。這樣一來，每次新添一種類型的時候，需要做的唯一事情就是從一個類繼承。<br>
為將涉及類型創建的信息移入特定類型的Trash里，必須使用“原型”（prototype）范式（來自《Design 
Patterns》那本書）。這里最基本的想法是我們有一個主控對象序列，為自己感興趣的每種類型都制作一個。這個序列中的對象只能用于新對象的創建，采用的操作類似內建到Java根類Object內部的clone()機制。在這種情況下，我們將克隆方法命名為tClone()。準備創建一個新對象時，要事先收集好某種形式的信息，用它建立我們希望的對象類型。然后在主控序列中遍歷，將手上的信息與主控序列中原型對象內任何適當的信息作對比。若找到一個符合自己需要的，就克隆它。<br>
采用這種方案，我們不必用硬編碼的方式植入任何創建信息。每個對象都知道如何揭示出適當的信息，以及如何對自身進行克隆。所以一種新類型加入系統的時候，factory()方法不需要任何改變。<br>
為解決原型的創建問題，一個方法是添加大量方法，用它們支持新對象的創建。但在Java 
1.1中，如果擁有指向Class對象的一個句柄，那么它已經提供了對創建新對象的支持。利用Java 
1.1的“反射”（已在第11章介紹）技術，即便我們只有指向Class對象的一個句柄，亦可正常地調用一個構建器。這對原型問題的解決無疑是個完美的方案。<br>
原型列表將由指向所有想創建的Class對象的一個句柄列表間接地表示。除此之外，假如原型處理失敗，則factory()方法會認為由于一個特定的Class對象不在列表中，所以會嘗試裝載它。通過以這種方式動態裝載原型，Trash類根本不需要知道自己要操縱的是什么類型。因此，在我們添加新類型時不需要作出任何形式的修改。于是，我們可在本章剩余的部分方便地重復利用它。<br>
<br>
923-925頁程序<br>
<br>
基本Trash類和sumValue()還是象往常一樣。這個類剩下的部分支持原型范式。大家首先會看到兩個內部類（被設為static屬性，使其成為只為代碼組織目的而存在的內部類），它們描述了可能出現的違例。在它后面跟隨的是一個Vector 
trashTypes，用于容納Class句柄。<br>
在Trash.factory()中，Info對象id（Info類的另一個版本，與前面討論的不同）內部的String包含了要創建的那種Trash的類型名稱。這個String會與列表中的Class名比較。若存在相符的，那便是要創建的對象。當然，還有很多方法可以決定我們想創建的對象。之所以要采用這種方法，是因為從一個文件讀入的信息可以轉換成對象。<br>
發現自己要創建的Trash（垃圾）種類后，接下來就輪到“反射”方法大顯身手了。getConstructor()方法需要取得自己的參數——由Class句柄構成的一個數組。這個數組代表著不同的參數，并按它們正確的順序排列，以便我們查找的構建器使用。在這兒，該數組是用Java 
1.1的數組創建語法動態創建的：<br>
new Class[] {double.class}<br>
這個代碼假定所有Trash類型都有一個需要double數值的構建器（注意double.class與Double.class是不同的）。若考慮一種更靈活的方案，亦可調用getConstructors()，令其返回可用構建器的一個數組。<br>
從getConstructors()返回的是指向一個Constructor對象的句柄（該對象是java.lang.reflect的一部分）。我們用方法newInstance()動態地調用構建器。該方法需要獲取包含了實際參數的一個Object數組。這個數組同樣是按Java 
1.1的語法創建的：<br>
new Object[] {new Double(info.data)}<br>
在這種情況下，double必須置入一個封裝（容器）類的內部，使其真正成為這個對象數組的一部分。通過調用newInstance()，會提取出double，但大家可能會覺得稍微有些迷惑——參數既可能是double，也可能是Double，但在調用的時候必須用Double傳遞。幸運的是，這個問題只存在于基本數據類型中間。<br>
理解了具體的過程后，再來創建一個新對象，并且只為它提供一個Class句柄，事情就變得非常簡單了。就目前的情況來說，內部循環中的return永遠不會執行，我們在終點就會退出。在這兒，程序動態裝載Class對象，并把它加入trashTypes（垃圾類型）列表，從而試圖糾正這個問題。若仍然找不到真正有問題的地方，同時裝載又是成功的，那么就重復調用factory方法，重新試一遍。<br>
正如大家會看到的那樣，這種設計方案最大的優點就是不需要改動代碼。無論在什么情況下，它都能正常地使用（假定所有Trash子類都包含了一個構建器，用以獲取單個double參數）。<br>
<br>
1. Trash子類<br>
為了與原型機制相適應，對Trash每個新子類唯一的要求就是在其中包含了一個構建器，指示它獲取一個double參數。Java 
1.1的“反射”機制可負責剩下的所有工作。<br>
下面是不同類型的Trash，每種類型都有它們自己的文件里，但都屬于Trash包的一部分（同樣地，為了方便在本章內重復使用）：<br>
<br>
926-927頁程序<br>
<br>
下面是一種新的Trash類型：<br>
<br>
927頁下程序<br>
<br>
可以看出，除構建器以外，這些類根本沒有什么特別的地方。<br>
<br>
2. 從外部文件中解析出Trash<br>
與Trash對象有關的信息將從一個外部文件中讀取。針對Trash的每個方面，文件內列出了所有必要的信息——每行都代表一個方面，采用“垃圾（廢品）名稱:值”的固定格式。例如：<br>
<br>
928頁程序<br>
<br>
注意在給定類名的時候，類路徑必須包含在內，否則就找不到類。<br>
為解析它，每一行內容都會讀入，并用字串方法indexOf()來建立“:”的一個索引。首先用字串方法substring()取出垃圾的類型名稱，接著用一個靜態方法Double.valueOf()取得相應的值，并轉換成一個double值。trim()方法則用于刪除字串兩頭的多余空格。<br>
Trash解析器置入單獨的文件中，因為本章將不斷地用到它。如下所示：<br>
<br>
929-930頁程序<br>
<br>
在RecycleA.java中，我們用一個Vector容納Trash對象。然而，亦可考慮采用其他集合類型。為做到這一點，fillBin()的第一個版本將獲取指向一個Fillable的句柄。后者是一個接口，用于支持一個名為addTrash()的方法：<br>
<br>
930頁上程序<br>
<br>
支持該接口的所有東西都能伴隨fillBin使用。當然，Vector并未實現Fillable，所以它不能工作。由于Vector將在大多數例子中應用，所以最好的做法是添加另一個過載的fillBin()方法，令其以一個Vector作為參數。利用一個適配器（Adapter）類，這個Vector可作為一個Fillable對象使用：<br>
<br>