本文介紹了三種修改現有代碼提高其可重用性的方法它們分別是改寫類的實例方法把參數類型改成接口選擇最簡單的參數接口類型
措施一改寫類的實例方法
通過類繼承實現代碼重用不是精確的代碼重用技術因此它並不是最理想的代碼重用機制換句話說如果不繼承整個類的所有方法和數據成員我們無法重用該類裡面的單個方法繼承總是帶來一些多余的方法和數據成員它們總是使得重用類裡面某個方法的代碼復雜化另外派生類對父類的依賴關系也使得代碼進一步復雜化對父類的改動可能影響子類修改父類或者子類中的任意一個類時我們很難記得哪一個方法被子類覆蓋哪一個方法沒有被子類覆蓋最後子類中的覆蓋方法是否要調用父類中的對應方法有時並不顯而易見
任何方法只要它執行的是某個單一概念的任務就其本身而言它就應該是首選的可重用代碼為了重用這種代碼我們必須回歸到面向過程的編程模式把類的實例方法移出成為全局性的過程為了提高這種過程的可重用性過程代碼應該象靜態工具方法一樣編寫它只能使用自己的輸入參數只能調用其他全局性的過程不能使用任何非局部的變量這種對外部依賴關系的限制簡化了過程的應用使得過程能夠方便地用於任何地方當然由於這種組織方式總是使得代碼具有更清晰的結構即使是不考慮重用性的代碼也同樣能夠從中獲益
在Java中方法不能脫離類而單獨存在為此我們可以把相關的過程組織成為獨立的類並把這些過程定義為公用靜態方法
例如對於下面這個類
class Polygon {
public int getPerimeter（） {…}
public boolean isConvex（） {…}
public boolean containsPoint（Point p） {…}
}
我們可以把它改寫成
class Polygon {
public int getPerimeter（） {return putePerimeter（this） }
public boolean isConvex（） {return pPolygonisConvex（this） }
public boolean containsPoint（Point p） {return ntainsPoint（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 ObjectOriented 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接口的類）所創建的對象都可以作為提供給ntains（）的rect參數
通過放寬參數類型的限制
我們使方法具有更好的可重用性
不過
對於上面這個例子
Rectangular接口的getBounds方法返回 Rectangle
你可能會懷疑這麼做是否真正值得
換言之
如果我們知道傳入過程的對象會在被調用時返回一個Rectangle
為什麼不直接傳入 Rectangle取代接口類型呢？之所以不這麼做
最重要的原因與集合有關
讓我們假設有這樣一個方法
static public boolean areAnyOverlapping（Collection rects） {…}
該方法用於檢查給定集合中的任意矩形對象是否重疊
在這個方法的內部
當我們用循環依次訪問集合中的各個對象時
如果我們不能把對象cast成為Rectangular之類的接口類型
又如何能夠訪問對象的矩形區域呢？唯一的選擇是把對象cast成為它特有的類形式（我們知道它有一個方法可以返回矩形）
它意味著方法必須事先知道它所操作的對象類型
從而使得方法的重用只限於那幾種對象類型
而這正是前面這個措施力圖先行避免的問題！
措施三
選擇最簡單的參數接口類型
在實施第二個措施時
應該選用哪一種接口類型來取代給定的類形式？答案是哪一個接口完全滿足過程對參數的需求
同時又具有最少的多余代碼和數據
描述參數對象要求的接口越簡單
其他類實現該接口的機會就越大
由此
其對象能夠作為參數使用的類也越多
從下面這個例子可以很容易地看出這一點
static public boolean areOverlapping（Window window
Window window
） {…}
這個方法用於檢查兩個窗口（假定是矩形窗口）是否重疊
如果這個方法只要求從參數獲得兩個窗口的矩形坐標
此時相應地簡化這兩個參數是一種更好的選擇
static public boolean areOverlapping（Rectangular rect
Rectangular rect
） {…}
上面的代碼假定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接口不能在其他地方重用
總而言之
本文三個措施適合於改造現有的
按照面向對象慣例編寫的代碼
這三個措施與面向對象編程技術結合就得到了一種可在以後編寫代碼時使用的新式代碼編寫技術
它能夠簡化方法的復雜性和依賴關系
同時提高方法的可重用能力和內部凝聚力
當然
這裡的三個措施不能用於那些天生就不適合重用的代碼
不適合重用的代碼通常出現在應用的表現層
例如
創建程序用戶界面的代碼
以及聯結到輸入事件的控制代碼
都屬於那種在程序和程序之間千差萬別的代碼
這種代碼幾乎不可能重用
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26688.html
