提高Java程式碼可重用性的三個措施 (轉)

提高Java程式碼可重用性的三個措施 (轉)[@more@]  提高程式碼可重用性的三個措施
  （松下客　2001年05月19日 00:08）

本文介紹了三種修改現有程式碼提高其可重用性的方法，它們分別是：改寫類的例項方法，把引數型別改成介面，選擇最簡單的引數介面型別。

措施一：改寫類的例項方法
透過類繼承實現程式碼重用不是精確的程式碼重用技術，因此它並不是最理想的程式碼重用機制。換句話說，如果不繼承整個類的所有方法和資料成員，我們無法重用該類裡面的單個方法。繼承總是帶來一些多餘的方法和資料成員，它們總是使得重用類裡面某個方法的程式碼複雜化。另外，派生類對父類的依賴關係也使得程式碼進一步複雜化：對父類的改動可能影響子類；修改父類或者子類中的任意一個類時，我們很難記得哪一個方法被子類覆蓋、哪一個方法沒有被子類覆蓋；最後，子類中的覆蓋方法是否要父類中的對應方法有時並不顯而易見。

任何方法，只要它的是某個單一概念的任務，就其本身而言，它就應該是首選的可重用程式碼。為了重用這種程式碼，我們必須迴歸到程式導向的，把類的例項方法移出成為全域性性的過程。為了提高這種過程的可重用性，過程程式碼應該象靜態工具方法一樣編寫：它只能使用自己的輸入引數，只能呼叫其他全域性性的過程，不能使用任何非區域性的變數。這種對外部依賴關係的限制簡化了過程的應用，使得過程能夠方便地用於任何地方。當然，由於這種組織方式總是使得程式碼具有更清晰的結構，即使是不考慮重用性的程式碼也同樣能夠從中獲益。

在Java中，方法不能脫離類而單獨存在。為此，我們可以把相關的過程組織成為獨立的類，並把這些過程定義為公用靜態方法。

例如，對於下面這個類：

class Polygon {
.
.
public int getPerimeter() {...}
public boolean invex() {...}
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表示該類的唯一目的是組織公用靜態過程。在Java中，類的名字以小寫字母開頭是一種非標準的做法，但象pPloygon這樣的類事實上並不提供普通Java類的功能。也就是說，它並不代表著一類物件，它只是Java語言組織程式碼的一種機制。

在上面這個例子中，改動程式碼的最終效果是使得應用Polygon功能的客戶程式碼不必再從Polygon繼承。Polygon類的功能現在已經由pPolygon類以過程為單位提供。客戶程式碼只使用自己需要的程式碼，無需關心Polygon類中自己不需要的功能。但它並不意味著在這種新式過程化程式設計中類的作用有所削弱。恰恰相反，在組織和封裝物件資料成員的過程中，類起到了不可或缺的作用，而且正如本文接下來所介紹的，類透過多重介面實現多型性的能力本身也帶來了卓越的程式碼重用支援。然而，由於用例項方法封裝程式碼功能並不是首選的程式碼重用手段，所以透過類繼承達到程式碼重用和多型性支援也不是最理想的。

措施二：把引數型別改成介面
正如Allen Holub在《Build User Interfaces for -Oriented Systems》中所指出的，在物件導向程式設計中，程式碼重用真正的要點在於透過介面引數型別利用多型性，而不是透過類繼承：

“……我們透過對介面而不是對類程式設計達到程式碼重用的目的。如果某個方法的所有引數都是對一些已知介面的引用，那麼這個方法就能夠操作這樣一些物件：當我們編寫方法的程式碼時，這些物件的類甚至還不存在。從技術上說，可重用的是方法，而不是傳遞給方法的物件。”

在“措施一”得到的結果上應用Holub的看法，當某塊程式碼能夠編寫為獨立的全域性過程時，只要把它所有類形式的引數改為介面形式，我們就可以進一步提高它的可重用能力。經過這個改動之後，過程的引數可以是實現了該介面的所有類的物件，而不僅僅是原來的類所建立的物件。由此，過程將能夠對可能存在的大量的物件型別進行操作。

例如，假設有這樣一個全域性靜態方法：

static public boolean contains(Rectangle rect, int x, int y) {...}
這個方法用於檢查指定的點是否包含在矩形裡面。在這個例子中，rect引數的型別可以從Rectangle類改變為介面型別，如下所示：

static public boolean contains(Rectangular rect, int x, int y) {...}
而Rectangular介面的定義是：

public interface Rectangular {Rectangle getBounds();}
現在，所有可以描述為矩形的類（即，實現了Rectangular介面的類）所建立的物件都可以作為提供給pRectangular.contains()的rect引數。透過放寬引數型別的限制，我們使方法具有更好的可重用性。

不過，對於上面這個例子，Rectangular介面的getBounds方法返回Rectangle，你可能會懷疑這麼做是否真正值得。換言之，如果我們知道傳入過程的物件會在被呼叫時返回一個Rectangle，為什麼不直接傳入Rectangle取代介面型別呢？之所以不這麼做，最重要的原因與集合有關。讓我們假設有這樣一個方法：

static public boolean areAnyOverlap(Collection rects) {...}
該方法用於檢查給定集合中的任意矩形物件是否重疊。在這個方法的內部，當我們用迴圈依次訪問集合中的各個物件時，如果我們不能把物件cast成為Rectangular之類的介面型別，又如何能夠訪問物件的矩形區域呢？唯一的選擇是把物件cast成為它特有的類形式（我們知道它有一個方法可以返回矩形），它意味著方法必須事先知道它所操作的物件型別，從而使得方法的重用只限於那幾種物件型別。而這正是前面這個措施力圖先行避免的問題！

措施三：選擇最簡單的引數介面型別
在實施第二個措施時，應該選用哪一種介面型別來取代給定的類形式？答案是哪一個介面完全滿足過程對引數的需求，同時又具有最少的多餘程式碼和資料。描述引數物件要求的介面越簡單，其他類實現該介面的機會就越大——由此，其物件能夠作為引數使用的類也越多。從下面這個例子可以很容易地看出這一點：

static public boolean areOverlapping(Window window1, Window window2) {...}
這個方法用於檢查兩個視窗（假定是矩形視窗）是否重疊。如果這個方法只要求從引數獲得兩個視窗的矩形座標，此時相應地簡化這兩個引數是一種更好的選擇：

static public boolean areOverlapping(Rectangular rect1, Rectangular rect2) {...}
上面的程式碼假定Window型別實現了Rectangular介面。經過改動之後，對於任何矩形物件我們都可以重用該方法的功能。

有些時候可能會出現描述引數需求的介面擁有太多方法的情況。此時，我們應該在全域性名稱空間中定義一個新的公共介面供其他面臨同一問題的程式碼重用。

當我們需要象使用C語言中的指標一樣使用引數時，建立唯一的介面描述引數需求是最好的選擇。例如，假設有下面這個過程：

static public void sort(List list, SortComparison comp) {...}
該方法運用引數中提供的比較物件comp，透過比較給定列表list中的物件排序list列表。sort對comp物件的唯一要求是要呼叫一個方法進行比較。因此，SortComparison應該是隻帶有一個方法的介面：

public interface SortComparison {
boolean comesBefore(Object a, Object b);
}
SortComparison介面的唯一目的在於為sort提供一個它所需功能的鉤子，因此SortComparison介面不能在其他地方重用。

總而言之，本文三個措施適合於改造現有的、按照物件導向慣例編寫的程式碼。這三個措施與物件導向程式設計技術結合就得到了一種可在以後編寫程式碼時使用的新式程式碼編寫技術，它能夠簡化方法的複雜性和依賴關係，同時提高方法的可重用能力和內部凝聚力。

當然，這裡的三個措施不能用於那些天生就不適合重用的程式碼。不適合重用的程式碼通常出現在應用的表現層。例如，建立介面的程式碼，以及聯結到輸入事件的控制程式碼，都屬於那種在程式和程式之間千差萬別的程式碼，這種程式碼幾乎不可能重用