### Extract Interface(提煉接口)
若干客戶使用class 接口中的同一子集;或者,兩個classes 的接口有部分相同。
將相同的子集提煉到一個獨立接口中。

**動機(Motivation)**
classes 之間彼此互用的方式有若干種。「使用一個class 」通常意味覆蓋該class 的所有責任區( whole area of responsibilities )。另一種情況是,某一組客戶只使用class 責任區中的一個特定子集。再一種情況則是,class 需要與「所有可協助處理某些特定請求」的classes 合作。
對于后兩種情況,將「被使用之部分責任」分離出來通常很有意義,因為這樣可以使系統的用法更清晰,同時也更容易看清系統的責任劃分。如果新的需要支持上述子集,也比較能夠看清子集內有些什么東西。
在許多面向對象語言中,這種「責任劃分」能力是通過多重繼承(multiple inheritance)支持的。你可以針對一段行為(each segment of behavior )建立一個class ,再將它們組合于一份實現品(implementation)中。Java 只提供單一繼承(single inher),但你可以運用interfaces (接口〉來昭示并實現上述需求。interfaces 對于Java 程序的設計方式有著巨大的影響,就連Smalltalk 程序員都認為interfaces (接口) 是一大進步!
Extract Superclass 和Extract Interface 之間有些相似之處。Extract Interface只能提煉共通接口,不能提煉共通代碼。使用Extract Interface 可能造成難聞的「重復」臭味,幸而你可以運用Extract Class 先把共通行為放進一個組件(component)中,然后將工作委托(delegating)該組件,從而解決這個問題。如果有不少共通行為,Extract Superclass 會比較簡單,但是每個class 只能有一個superclass (譯注:每個class 卻能有多個interfaces )。
如果某個class 在不同環境下扮演截然不同的角色,使用interface (接口)就是個好主意。你可以針對每個角色以Extract Interface 提煉出相應接口。另一種可以用上Extract Interface 的情況是:你想要描述一個class 的外駛接口(outbound interface ),亦即這個class 對其server 所進行的操作〉。如果你打算將來加入其他種類的server ,只需要求它們實現這個接口即可。
**作法(Mechanics)**
- 新建一個空接口(empty interface )。
- 在接口中聲明「待提煉類」的共通操作。
- 讓相關的胡實現上述接口。
- 調整客戶端的型別聲明,使得以運用該接口。
**范例:(Example)**
TimeSheet class 表示「月報表」,其中將計算花在員工身上的費用。為了計算這筆費用,TimeSheet 需要知道員工級別,以及該員工是否有特殊技能:
~~~
double charge(Employee emp, int days) {
int base = emp.getRate() * days;
if (emp.hasSpecialSkill())
return base * 1.05;
else return base;
}
~~~
除了提供員工的索費級別和特殊技能信息外,Employee 還有很多其他方面的功能,但本應用程序只需這兩項功能。我可以針對這兩項功能定義一個接口,從而強調「我 只需要這部分功能」的事實:
~~~
interface Billable {
public int getRate();
public boolean hasSpecialSkill();
}
~~~
然后,我聲明Employee 實現這個接口 :
~~~
class Employee implements Billable ...
~~~
完成以后,我可以修改charge() 函數聲明,強調該函數只使用Employee 的這部分行為:
~~~
double charge(Billable emp, int days) {
int base = emp.getRate() * days;
if (emp.hasSpecialSkill())
return base * 1.05;
else return base;
}
~~~
此刻,我們只不過是在文檔化(documentability)方面獲得了一些適度收獲。對函 數,這樣的收獲并沒有太大價值;但如果有若干classes 都使用Billable 接口,它就會很有用。如果我還想計算計算器租金,巨大的收獲就顯露出來了。為了讓公司里的計算器都「能夠被計費」(billable),我只需讓Computer class 實現Billable 接口,然后就可以把計算器租金登記到月報表上了。
- 譯序 by 侯捷
- 譯序 by 熊節
- 序言
- 前言
- 章節一 重構,第一個案例
- 起點
- 重構的第一步
- 分解并重組statement()
- 運用多態(Polymorphism)取代與價格相關的條件邏輯
- 結語
- 章節二 重構原則
- 何謂重構
- 為何重構
- 「重構」助你找到臭蟲(bugs)
- 何時重構
- 怎么對經理說?
- 重構的難題
- 重構與設計
- 重構與性能(Performance)
- 重構起源何處?
- 章節三 代碼的壞味道
- Duplicated Code(重復的代碼)
- Long Method(過長函數)
- Large Class(過大類)
- Long Parameter List(過長參數列)
- Divergent Change(發散式變化)
- Shotgun Surgery(散彈式修改)
- Feature Envy(依戀情結)
- Data Clumps(數據泥團)
- Primitive Obsession(基本型別偏執)
- Switch Statements(switch驚悚現身)
- Parallel Inheritance Hierarchies(平行繼承體系)
- Lazy Class(冗贅類)
- Speculative Generality(夸夸其談未來性)
- Temporary Field(令人迷惑的暫時值域)
- Message Chains(過度耦合的消息鏈)
- Middle Man(中間轉手人)
- Inappropriate Intimacy(狎昵關系)
- Alternative Classes with Different Interfaces(異曲同工的類)
- Incomplete Library Class(不完美的程序庫類)
- Data Class(純稚的數據類)
- Refused Bequest(被拒絕的遺贈)
- Comments(過多的注釋)
- 章節四 構筑測試體系
- 自我測試代碼的價值
- JUnit測試框架
- 添加更多測試
- 章節五 重構名錄
- 重構的記錄格式
- 尋找引用點
- 這些重構準則有多成熟
- 章節六 重新組織你的函數
- Extract Method(提煉函數)
- Inline Method(將函數內聯化)
- Inline Temp(將臨時變量內聯化)
- Replace Temp with Query(以查詢取代臨時變量)
- Introduce Explaining Variable(引入解釋性變量)
- Split Temporary Variable(剖解臨時變量)
- Remove Assignments to Parameters(移除對參數的賦值動作)
- Replace Method with Method Object(以函數對象取代函數)
- Substitute Algorithm(替換你的算法)
- 章節七 在對象之間搬移特性
- Move Method(搬移函數)
- Move Field(搬移值域)
- Extract Class(提煉類)
- Inline Class(將類內聯化)
- Hide Delegate(隱藏「委托關系」)
- Remove Middle Man(移除中間人)
- Introduce Foreign Method(引入外加函數)
- Introduce Local Extension(引入本地擴展)
- 章節八 重新組織數據
- Self Encapsulate Field(自封裝值域)
- Replace Data Value with Object(以對象取代數據值)
- Change Value to Reference(將實值對象改為引用對象)
- Replace Array with Object(以對象取代數組)
- Replace Array with Object(以對象取代數組)
- Duplicate Observed Data(復制「被監視數據」)
- Change Unidirectional Association to Bidirectional(將單向關聯改為雙向)
- Change Bidirectional Association to Unidirectional(將雙向關聯改為單向)
- Replace Magic Number with Symbolic Constant(以符號常量/字面常量取代魔法數)
- Encapsulate Field(封裝值域)
- Encapsulate Collection(封裝群集)
- Replace Record with Data Class(以數據類取代記錄)
- Replace Type Code with Class(以類取代型別碼)
- Replace Type Code with Subclasses(以子類取代型別碼)
- Replace Type Code with State/Strategy(以State/strategy 取代型別碼)
- Replace Subclass with Fields(以值域取代子類)
- 章節九 簡化條件表達式
- Decompose Conditional(分解條件式)
- Consolidate Conditional Expression(合并條件式)
- Consolidate Duplicate Conditional Fragments(合并重復的條件片段)
- Remove Control Flag(移除控制標記)
- Replace Nested Conditional with Guard Clauses(以衛語句取代嵌套條件式)
- Replace Conditional with Polymorphism(以多態取代條件式)
- Introduce Null Object(引入Null 對象)
- Introduce Assertion(引入斷言)
- 章節十一 處理概括關系
- Pull Up Field(值域上移)
- Pull Up Method(函數上移)
- Pull Up Constructor Body(構造函數本體上移)
- Push Down Method(函數下移)
- Push Down Field(值域下移)
- Extract Subclass(提煉子類)
- Extract Superclass(提煉超類)
- Extract Interface(提煉接口)
- Collapse Hierarchy(折疊繼承關系)
- Form Template Method(塑造模板函數)
- Replace Inheritance with Delegation(以委托取代繼承)
- Replace Delegation with Inheritance(以繼承取代委托)
- 章節十二 大型重構
- 這場游戲的本質
- Tease Apart Inheritance(梳理并分解繼承體系)
- Convert Procedural Design to Objects(將過程化設計轉化為對象設計)
- Separate Domain from Presentation(將領域和表述/顯示分離)
- Extract Hierarchy(提煉繼承體系)
- 章節十三 重構,復用與現實
- 現實的檢驗
- 為什么開發者不愿意重構他們的程序?
- 現實的檢驗(再論)
- 重構的資源和參考資料
- 從重構聯想到軟件復用和技術傳播
- 結語
- 參考文獻
- 章節十四 重構工具
- 使用工具進行重構
- 重構工具的技術標準(Technical Criteria )
- 重構工具的實用標準(Practical Criteria )
- 小結
- 章節十五 集成
- 參考書目