重構的原因，在於需求的變化。需求沒有變化，也就沒有必要瞎折騰來重構，除非你真很蛋疼。 需求變化有兩種原因:
一，是真的變化了。
二，對需求的認識深化了。
舊的需求，轉化到新的需求，設計就要跟著變化。當然也不是所有情況都需要大變動，很多需求變化，沒有涉及到「筋骨」，就可以保持設計的骨架，而新增新的內容。 乙個優秀的設計，應該精良預示到這種簡單的需求變化。
如果真的要改變，那哪些設計會比較容易更改呢？ 類設計有兩種觀點:
一是從自身出發，該類應該有哪些操作，就建立這些操作。
二是從需求出發，別人需要該類有什麼操作，他就應該提供這些操作。
我的看法是，從需求出發，建立的是概念切面，也就是介面。從自身出發，建立的是具體實現。當類呼叫其他類，使用的是介面，而當編寫類自身**時，又應該從自身出發。
介面比類可能要小，也可能要大。而當介面比類要大，顯然需要多個類才能支援完整的介面，這時候可能就需要建立簡單的包裝類。
(當介面比類小，那麼說明系統還不需要更多地控制，這個時候應該選擇暫時封閉相關部分。如果把類看作乙個整體，成員函式就是傳統上的子程式概念。而作為介面的時候，成員函式是流程的區域性。）
介面往往是很穩定，但是，當需求變化的時候，設計變更的時候，變化的是什麼？就是介面。 介面雖然變了，但是類還生存，並且，因為類是從自身出發的，有理由相信在新的介面面前也不需要變化。我們可以設計新的介面，並大量使用已有的實現在完成新的介面的支援，當然，免不了要新增新的類，和廢置很多舊的類，因為這就是需求在變化了。
介面和類之間的關係
首先要明確，介面不是類，所以也不是抽象類。類是屬性和方法容器，但是這些屬性和方法沒有任何區別的堆積在一起，當開發人員要尋找某個方法時，將很不方便，這個時候，介面出現了，介面的出現就是為了解決這個問題。介面將類的內部屬性和方法進行分類，定義不同功能組的屬性和方法。我們可以把介面看做乙個特殊類，除了不能...
類 介面和抽象類的關係
抽象類 使用abstract修飾 2 抽象類不能例項化，即不能使用new關鍵字來例項化物件 3 含有抽象方法 使用abstract關鍵字修飾的方法 的類是抽象類，必須使用abstract關鍵字修飾 4 抽象類可以含有抽象方法，也可以不包含抽象方法，抽象類中可以有具體的方法 5 如果乙個子類實現了父類...
介面和抽象類的關係
定義方面，抽象類 包含乙個抽象方法的類。介面 由全域性常量和公共抽象方法組成。抽象類只能繼承 extends 介面只能實現 implement 介面不能繼承抽象類 要繼承抽象類就要覆寫抽象類裡面的方法，抽象方法中可以有方法體，介面中的抽象方法是沒有方法身體的，所以這一點上就不能繼承。但允許實現多個介...