作者：jeru
email: jeru@163.net
日期：8/6/2001 5:35:46 PM
最大化JAVA代碼的可重用性

——克服傳統(tǒng)OO方法在重用方面的缺陷

出處: http://www.javaworld.com 
mashy    翻譯  


 

摘要：不要放棄編寫可重用代碼的努力！本文介紹了三種對現(xiàn)有代碼進行修改以提高其可重用性的方法。

在程序員中似乎存在著一種日益普遍的觀點，認為重用只是一個神話?；蛟S是傳統(tǒng)的面向?qū)ο缶幊谭椒ㄖ兴嬖诘牟蛔阍黾恿酥赜玫睦щy。本文介紹了從另外一種不同的途徑使重用成為可能的三個步驟。

第一步：將功能實現(xiàn)從類實例的方法中移出

由于缺乏精確性，類繼承不是非常理想的代碼重用機制。換句話說，如果不繼承一個類的數(shù)據(jù)成員和其他的方法，那么你就無法重用這個類的某個單獨的方法。這些額外的不必要的負擔(dān)使方法重用的代碼變得復(fù)雜。派生類對其父類的依賴性也以入了額外的復(fù)雜性：對父類的改動會對子類造成影響；當(dāng)修改任意一個類的時候，我們很難記得清哪個方法被覆蓋，哪個沒有；而且被覆蓋的方法是否會調(diào)用父類中相應(yīng)的方法并不非常清晰地顯現(xiàn)。

任何執(zhí)行單一概念任務(wù)的方法應(yīng)該能夠成為代碼用的首選而獨立存在。為了達到這個目標(biāo)，我們必須會到過程化的編程模式，將代碼從類實例的方法中移出，形成具有全局可見性的過程。為了提高這種過程的可重用性，過程代碼應(yīng)該象靜態(tài)的通用方法一樣編寫：每個過程只能使用自己的輸入?yún)?shù)，只能調(diào)用其他全局性的過程完成其工作，不能使用任何非本地的變量。這種對外部依賴的簡化降低了過程使用的復(fù)雜性，也增加了在其他地方使用此過程的可能性。當(dāng)然，由于其結(jié)構(gòu)通常會變得更為清晰，即使拋開重用的目的不談我們也可以從這種代碼的組織方式中受益。

在Java中，方法不能脫離類而單獨存在。因此，你可以對相關(guān)的過程進行組織并使它們成為一個獨立的類中的公共靜態(tài)方法。例如，對于如下所示的一個類：

class Polygon{

…

public int getPerimeter(){…}

public boolean isConvex(){…}

public Boolean containsPoint(Point p){…}

…

}

可以將它改寫成下面的形式：

class Polygon { 

…

public int getPerimeter() { return pPolygon.computePerimeter(this);} 

public boolean isConvex() { return pPolygon.isConvex(this);} 

public boolean containsPoint() { return pPolygon.containsPoint(this, p);} 

…

} 

在此處，nPolygon應(yīng)該是這個樣子：

class pPolygon { 

static public int computePerimeter(Polygon polygon) {...} 

static public boolean isConvex(Polygon polygon) {...} 

static public boolean containsPoint(Polygon polygon, Point p) {...} 

｝

從類的名字pPolygon可以看出，該類所封裝的過程主要與Polygon類型的對象有關(guān)。名字前面的p表示該類的唯一目的是組織公共靜態(tài)過程。在Java中，類的名字以小寫字母開頭不是一種標(biāo)準(zhǔn)的做法，但象pPloygon這樣的類事實上并不執(zhí)行普通類的功能。也就是說，它并不代表著一類對象，它只是語言本身所需要的用于代碼組織的實體。

　在上面這個例子中，改動代碼的總體影響是使得客戶代碼不必為了重用其功能而從Polygon繼承。Polygon類的功能現(xiàn)在已經(jīng)由pPolygon類以過程為單位提供?？蛻舸a只使用自己需要的代碼，無需關(guān)心自身并不需要的功能。

這并不意味著在這種新型的過程化編程模式中，類不服務(wù)于更有用的目的。恰恰相反，類執(zhí)行組織和封裝對象數(shù)據(jù)成員的必要工作。而且它們通過多重接口實現(xiàn)多態(tài)性的能力也為代碼重用提供了顯著的支持，這將在下一個步驟中討論。然而，由于將功能實現(xiàn)包含在實例方法中無法實現(xiàn)理想的代碼重用，所以通過類繼承實現(xiàn)代碼重用和多態(tài)性支持也不應(yīng)成為最佳的技術(shù)選擇。

在一本被廣為閱讀的書《Design Patterns》中曾簡要地提及一種略有不同的技術(shù)。策略模式（Strategy Pattern）提倡將相關(guān)算法的每個成員封裝在一個通用的接口下，以便于客戶端代碼可交換地使用其算法。由于一個算法通常被作為一個或幾個獨立的過程進行編碼，這種封裝更注重執(zhí)行單獨任務(wù)的過程的重用，而不是執(zhí)行多種任務(wù)的、包含代碼和數(shù)據(jù)的對象的重用。這一步驟體現(xiàn)了相同的基本思想。

然而，將一個算法封裝在一個接口下意味著將算法作為實現(xiàn)接口的對象進行編碼。這意味著我們?nèi)匀灰蕾囉谝粋€與所包裝的對象的數(shù)據(jù)和其他方法相耦合的過程，這樣便會使其復(fù)用變得復(fù)雜。此外還存在這樣一個問題，每次需要使用這個算法的時候都必須實例化這些對象，這便會降低程序的性能。值得慶幸的是，設(shè)計模式提供了針對這兩個問題的解決方法?？梢栽趯Σ呗詫ο筮M行編碼時應(yīng)用享元模式(Flyweight Pattern，譯者注：還存在一種譯法為輕量模式)，這樣每個對象只會存在一個被共知共享的實例(這針對程序性能的問題)，而且每個共享對象在訪問間隔中并不維持狀態(tài)(于是對象將沒有數(shù)據(jù)成員，這針對大多數(shù)的耦合問題)。由此產(chǎn)生的享元--策略模式非常類似于在這一步驟中所提到的將功能實現(xiàn)封裝在全局可見的、無狀態(tài)的過程中的技術(shù)。(譯者注：以上這兩段文字讀起來可能有些晦澀難解，建議有興趣的讀者參閱文中所提到《設(shè)計模式》一書，Erich Gamma等著、李英軍等譯、機械工業(yè)出版社出版。)

第二步：將非原始的輸入?yún)?shù)類型改為接口類型

在面向?qū)ο缶幊讨?，代碼重用的真正基礎(chǔ)在于通過接口參數(shù)類型利用多態(tài)性，而不是通過類繼承，正如Allen Holub在 “Build User Interfaces for Object-Oriented System, Part 2”中所述：

“……你應(yīng)該通過對接口而不是類編程實現(xiàn)重用。如果一個方法的所有參數(shù)都是某個已知接口的引用，這個接口由一些你所不知道的類實現(xiàn)，那么這個方法就能夠操作這樣一些對象：當(dāng)編寫方法的代碼時，這些對象的類甚至還不存在。從技術(shù)上講，可重用的是方法，而不是傳遞給方法的對象?！?
將Holub所講的方法應(yīng)用于第一步所得到的結(jié)果，只要某塊功能代碼能夠作為一個全局可見的過程而獨立存在，你就可以將其每個類類型(class-type)的輸入?yún)?shù)改為一個接口類型，這樣便能進一步提高其重用的潛力。那么，實現(xiàn)此接口類型的任何類的對象都可以作為參數(shù)使用，而不僅僅局限于原始類。由此，這個過程對可能存在的大量的對象類型都成為可用的。

例如，有這樣一個全局可見的靜態(tài)過程

static public boolean contains(Rectangle rect, int x, int y) {…}

這個方法用于檢查給定的矩形是否包含某個給定的點。在這個例子中，rect參數(shù)的類型可以從Rectangle類改變?yōu)榻涌陬愋停缦滤荆?
static public boolean contains(Rectangular rect, int x, int y){…}

Rectangular可以是下面形式的接口：

public interface Rectangular{

       Rectangle getBounds();

}

現(xiàn)在，所有可以被描述為矩形的類(也就意味著實現(xiàn)了Rectangular接口)的對象都可以作為傳遞給pRectangular.contains()的rect參數(shù)。通過放寬所傳遞的參數(shù)類型的限制，我們使方法具有更好的可重用性。

不過，在上面這個例子中，Rectangular接口的getBounds方法返回一個Rectangle類型，你可能會懷疑使用這個接口是否具有真正的價值；換句話說，如果我們知道傳入過程的對象會在被調(diào)用時返回一個Rectangle，為什么不直接傳入Rectangle取代接口類型呢？不這樣做的最重要原因與集合有關(guān)，假設(shè)有這樣一個方法：

static public boolean areAnyOverlapping(Collection rects) {…}

這個方法的目的在于檢查給定集合中的任意矩形對象是否存在重疊。那么，在方法內(nèi)部遍歷集合中的每個對象時，如果無法將對象造型(cast)成如Rectangular這樣的接口類型，那么將如何能夠訪問對象的矩形區(qū)域呢？唯一的選擇是將對象造型成為其特定的類型(我們直到它有一個能夠返回rectangle的方法)，這意味著方法必須事先知道其所要操作的是什么類型。這恰恰是這一步驟力圖首先要避免的問題！

第三步：選擇低耦合的輸入?yún)?shù)接口類型

完成第二步之后，應(yīng)該選擇什么樣的接口類型來取代給定的類型呢？答案是能夠通過參數(shù)完全描述過程的需求，同時又具有最少的額外負擔(dān)的接口類型。參數(shù)對象所要實現(xiàn)的接口越簡單，其他特定類實現(xiàn)此接口的機會就越大——由此，其對象可以作為參數(shù)使用的類也就越多。通過下面的例子可以很容易地看到這點：

static public boolean areOverlapping(Window window1, Window window2) {...}

這個方法用于檢查兩個窗口（假定是矩形窗口）是否重疊，如果這個方法只要求從參數(shù)獲得兩個窗口的矩形坐標(biāo)，那么簡化參數(shù)的類型使其能反映這個事實是一種更好的選擇：

static public boolean areOverlapping(Rectangular rect1, Rectangular rect2) {...}

以上的代碼假設(shè)先前的Window類型的對象同樣可以實現(xiàn)Rectangular接口?，F(xiàn)在對于所有的矩形對象，都可以重用第一個方法所包含的功能了。

你可能多次體驗到當(dāng)一個接口能夠完全確定需要通過參數(shù)獲哪那些內(nèi)容時，會存在太多不必要的方法。在這種情況下，應(yīng)該在全局命名空間中定義一個新的公共接口以供其他可能面臨同一困境的方法重用。

你可能還會不止一次地發(fā)現(xiàn)，在確定需要通過單一過程的一個參數(shù)獲取哪些內(nèi)容時，最好創(chuàng)建一個單獨的接口。你應(yīng)該只為這個參數(shù)使用此接口。這通常會在你希望如同C語言中的函數(shù)指針一樣使用參數(shù)的情況下出現(xiàn)。例如下面的過程：

static public void sort(List list, SortComparison comp) {...}

此過程使用參數(shù)所提供的比較對象comp，通過比較給定列表中的所有對象而對其進行排序，sort對comp的全部要求是調(diào)用一個單獨的方法進行比較。因此，SortComparison應(yīng)該是只帶有一個方法的接口：

public interface SortComparison { 

boolean comesBefore(Object a, Object b); 

} 

這個接口的唯一目的是為sort提供一個與其完成任務(wù)所需功能相聯(lián)系的鉤子(hook)，因此SortComparison無法在其他地方重用。

結(jié)束語

以上所述的三個步驟用于現(xiàn)有的、按照相對傳統(tǒng)的面向?qū)ο蠓椒ㄋ帉懙拇a。這些步驟與面向?qū)ο缶幊碳夹g(shù)結(jié)合就形成了一種可以運用于今后代碼編寫中的新方法，它可以提高代碼的可重用性和內(nèi)聚性，同時降低了耦合度及復(fù)雜性。

很顯然，這些步驟無法運用于那些在本質(zhì)上就不適合于重用的代碼。這類代碼通常出現(xiàn)在應(yīng)用程序的表示層(presentation layer)。例如程序中用于創(chuàng)建用戶界面的代碼，以及將輸入事件與完成實際工作的過程相聯(lián)系的控制代碼，都是屬于那種其功能在不同的程序中差別很大的代碼，這種代碼的重用幾乎是不可能的。