介面和類的關係

重構的原因，在於需求的變化。需求沒有變化，也就沒有必要瞎折騰來重構，除非你真很蛋疼。 需求變化有兩種原因:

一，是真的變化了。

二，對需求的認識深化了。

舊的需求，轉化到新的需求，設計就要跟著變化。當然也不是所有情況都需要大變動，很多需求變化，沒有涉及到“筋骨”，就可以保持設計的骨架，而添加新的內容。 一個優秀的設計，應該精良預示到這種簡單的需求變化。

如果真的要改變，那哪些設計會比較容易更改呢？ 類設計有兩種觀點:

一是從自身出發，該類應該有哪些操作，就建立這些操作。

二是從需求出發，別人需要該類有什麼操作，他就應該提供這些操作。

我的看法是，從需求出發，建立的是概念切面，也就是介面。從自身出發，建立的是具體實現。當類調用其他類，使用的是介面，而當編寫類自身代碼時，又應該從自身出發。

介面比類可能要小，也可能要大。而當介面比類要大，顯然需要多個類才能支援完整的介面，這時候可能就需要建立簡單的封裝類。

(當介面比類小，那麼說明系統還不需要更多地控制，這個時候應該選擇暫時封閉相關部分。如果把類看作一個整體，成員函數就是傳統上的子程式概念。而作為介面的時候，成員函數是流程的局部。）

介面往往是很穩定，但是，當需求變化的時候，設計變更的時候，變化的是什嗎？就是介面。 介面雖然變了，但是類還生存，並且，因為類是從自身出發的，有理由相信在新的介面面前也不需要變化。我們可以設計新的介面，並大量使用已有的實現在完成新的介面的支援，當然，免不了要添加新的類，和廢置很多舊的類，因為這就是需求在變化了。