作者：Eazily
email: Eazily@yeah.net
日期：2001-7-14 21:37:38
提高Java代碼可重用性的三個措施 

本文介紹了三種修改現(xiàn)有代碼提高其可重用性的方法，它們分別是：改寫類的實例方法，把參數(shù)類型改成接口，選擇最簡單的參數(shù)接口類型。 

措施一：改寫類的實例方法 

通過類繼承實現(xiàn)代碼重用不是精確的代碼重用技術，因此它并不是最理想的代碼重用機制。換句話說，如果不繼承整個類的所有方法和數(shù)據(jù)成員，我們無法重用該類里面的單個方法。繼承總是帶來一些多余的方法和數(shù)據(jù)成員，它們總是使得重用類里面某個方法的代碼復雜化。另外，派生類對父類的依賴關系也使得代碼進一步復雜化：對父類的改動可能影響子類；修改父類或者子類中的任意一個類時，我們很難記得哪一個方法被子類覆蓋、哪一個方法沒有被子類覆蓋；最后，子類中的覆蓋方法是否要調(diào)用父類中的對應方法有時并不顯而易見。 

任何方法，只要它執(zhí)行的是某個單一概念的任務，就其本身而言，它就應該是首選的可重用代碼。為了重用這種代碼，我們必須回歸到面向過程的編程模式，把類的實例方法移出成為全局性的過程。為了提高這種過程的可重用性，過程代碼應該象靜態(tài)工具方法一樣編寫：它只能使用自己的輸入?yún)?shù)，只能調(diào)用其他全局性的過程，不能使用任何非局部的變量。這種對外部依賴關系的限制簡化了過程的應用，使得過程能夠方便地用于任何地方。當然，由于這種組織方式總是使得代碼具有更清晰的結構，即使是不考慮重用性的代碼也同樣能夠從中獲益。 

在Java中，方法不能脫離類而單獨存在。為此，我們可以把相關的過程組織成為獨立的類，并把這些過程定義為公用靜態(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(Point p) {return pPolygon.containsPoint(this, 
p 
);} 
. 

} 

其中，pPolygon是： 
class pPolygon { 
static public int computePerimeter(Polygon polygon) {...} 
static public boolean isConvex(Polygon polygon) {...} 
static public boolean 
containsPoint(Polygon polygon, Point p) {...} 
} 

從類的名字pPolygon可以看出，該類所封裝的過程主要與Polygon類型的對象有關。名字前面的p表示該類的唯一目的是組織公用靜態(tài)過程。在Java中，類的名字以小寫字母開頭是一種非標準的做法，但象pPloygon這樣的類事實上并不提供普通Java類的功能。也就是說，它并不代表著一類對象，它只是Java語言組織代碼的一種機制。 

在上面這個例子中，改動代碼的最終效果是使得應用Polygon功能的客戶代碼不必再從Polygon繼承。Polygon類的功能現(xiàn)在已經(jīng)由pPolygon類以過程為單位提供。客戶代碼只使用自己需要的代碼，無需關心Polygon類中自己不需要的功能。但它并不意味著在這種新式過程化編程中類的作用有所削弱。恰恰相反，在組織和封裝對象數(shù)據(jù)成員的過程中，類起到了不可或缺的作用，而且正如本文接下來所介紹的，類通過多重接口實現(xiàn)多態(tài)性的能力本身也帶來了卓越的代碼重用支持。然而，由于用實例方法封裝代碼功能并不是首選的代碼重用手段，所以通過類繼承達到代碼重用和多態(tài)性支持也不是最理想的。 

措施二：把參數(shù)類型改成接口 

正如Allen Holub在《Build User Interfaces for Object-Oriented Systems》中所指出的，在面向對象編程中，代碼重用真正的要點在于通過接口參數(shù)類型利用多態(tài)性，而不是通過類繼承： 

“……我們通過對接口而不是對類編程達到代碼重用的目的。如果某個方法的所有參數(shù)都是對一些已知接口的引用，那么這個方法就能夠操作這樣一些對象：當我們編寫方法的代碼時，這些對象的類甚至還不存在。從技術上說，可重用的是方法，而不是傳遞給方法的對象。” 

在“措施一”得到的結果上應用Holub的看法，當某塊代碼能夠編寫為獨立的全局過程時，只要把它所有類形式的參數(shù)改為接口形式，我們就可以進一步提高它的可重用能力。經(jīng)過這個改動之后，過程的參數(shù)可以是實現(xiàn)了該接口的所有類的對象，而不僅僅是原來的類所創(chuàng)建的對象。由此，過程將能夠對可能存在的大量的對象類型進行操作。 

例如，假設有這樣一個全局靜態(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接口的類）所創(chuàng)建的對象都可以作為提供給pRectangular.contains()的rect參數(shù)。通過放寬參數(shù)類型的限制，我們使方法具有更好的可重用性。 

不過，對于上面這個例子，Rectangular接口的getBounds方法返回Rectangle，你可能會懷疑這么做是否真正值得。換言之，如果我們知道傳入過程的對象會在被調(diào)用時返回一個Rectangle，為什么不直接傳入Rectangle取代接口類型呢？之所以不這么做，最重要的原因與集合有關。讓我們假設有這樣一個方法： 

static public boolean areAnyOverlapping(Collection rects) {...} 

該方法用于檢查給定集合中的任意矩形對象是否重疊。在這個方法的內(nèi)部，當我們用循環(huán)依次訪問集合中的各個對象時，如果我們不能把對象cast成為Rectangular之類的接口類型，又如何能夠訪問對象的矩形區(qū)域呢？唯一的選擇是把對象cast成為它特有的類形式（我們知道它有一個方法可以返回矩形），它意味著方法必須事先知道它所操作的對象類型，從而使得方法的重用只限于那幾種對象類型。而這正是前面這個措施力圖先行避免的問題！ 

措施三：選擇最簡單的參數(shù)接口類型 

在實施第二個措施時，應該選用哪一種接口類型來取代給定的類形式？答案是哪一個接口完全滿足過程對參數(shù)的需求，同時又具有最少的多余代碼和數(shù)據(jù)。描述參數(shù)對象要求的接口越簡單，其他類實現(xiàn)該接口的機會就越大——由此，其對象能夠作為參數(shù)使用的類也越多。從下面這個例子可以很容易地看出這一點： 

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

這個方法用于檢查兩個窗口（假定是矩形窗口）是否重疊。如果這個方法只要求從參數(shù)獲得兩個窗口的矩形坐標，此時相應地簡化這兩個參數(shù)是一種更好的選擇： 

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

上面的代碼假定Window類型實現(xiàn)了Rectangular接口。經(jīng)過改動之后，對于任何矩形對象我們都可以重用該方法的功能。 

有些時候可能會出現(xiàn)描述參數(shù)需求的接口擁有太多方法的情況。此時，我們應該在全局名稱空間中定義一個新的公共接口供其他面臨同一問題的代碼重用。 

當我們需要象使用C語言中的函數(shù)指針一樣使用參數(shù)時，創(chuàng)建唯一的接口描述參數(shù)需求是最好的選擇。例如，假設有下面這個過程： 
static public void sort(List list, SortComparison comp) {...} 

該方法運用參數(shù)中提供的比較對象comp，通過比較給定列表list中的對象排序list列表。sort對comp對象的唯一要求是要調(diào)用一個方法進行比較。因此，SortComparison應該是只帶有一個方法的接口： 
public interface SortComparison { 
boolean comesBefore(Object a, Object b); 
} 

SortComparison接口的唯一目的在于為sort提供一個它所需功能的鉤子，因此SortComparison接口不能在其他地方重用。 

總而言之，本文三個措施適合于改造現(xiàn)有的、按照面向對象慣例編寫的代碼。這三個措施與面向對象編程技術結合就得到了一種可在以后編寫代碼時使用的新式代碼編寫技術，它能夠簡化方法的復雜性和依賴關系，同時提高方法的可重用能力和內(nèi)部凝聚力。 

當然，這里的三個措施不能用于那些天生就不適合重用的代碼。不適合重用的代碼通常出現(xiàn)在應用的表現(xiàn)層。例如，創(chuàng)建程序用戶界面的代碼，以及聯(lián)結到輸入事件的控制代碼，都屬于那種在程序和程序之間千差萬別的代碼，這種代碼幾乎不可能重