設計相關1-設計原則

1. 封裝變化的部分
   找出那些容易或者可能會變化的部分，將他們與那些不變的部分分離開，這樣我們日後維護的時候，影響會小些。

2. 針對接口編程，而不是針對實現編程
   所謂的針對接口編程，就是將變化的某種行爲提取成一個接口，由多個實現類來實現不同的具體行爲。使用時將接口給使用對象即可，而不是將具體的某種實現給使用對象。

3. 多用組合，少用繼承
   使用組合可以很好的實現功能的動態綁定。使用繼承的話，屬於編譯時綁定，有點太死板了，不能很好的適應一些變化。

4. 不寫重複的代碼
   重複的代碼太多，浪費時間不說，維護成本也會正比增長。

5. 開閉原則
   對擴展開放，對修改關閉；通俗一點說就是：允許你在不修改原有邏輯的基礎上進行擴展，禁止你通過修改原有邏輯進行功能的擴展；

6. 單一職責原則
   單一職責就是說，一個類或者一個方法，他們的功能儘可能的單一，也就是最好只幹一種活。更深層一點的說，引起他們變化的維度（原因）應該是單一的。

7. 依賴倒置
   定義： 高層次的模塊不應該依賴於低層次的模塊，它們都應該依賴於抽象。抽象（接口、抽象類）不應該依賴實現（實現類），實現應該依賴抽象。
   依賴：A依賴B，即A使用B，比如B作爲A的某個方法的參數、返回值；
   依賴倒置的核心思想其實就是面向接口編程。實現依賴倒置的常用方法：
   構造函數注入、setter注入、接口注入。

8. 里氏代換原則
   子類實例可以完美的代替父類實例而不影響程序原有功能的正確性。
   里氏替換的核心思想：類B繼承類A時，除添加新的方法完成新增功能P2外，儘量不要重寫父類A的方法，也儘量不要重載父類A的方法。如果子類對父類方法任意修改，就會對整個繼承體系造成破壞。

9. 接口隔離
   一個類對另外一個類的依賴是建立在最小的接口上。一個接口的功能應該是單一的。如果一個接口的功能太多，那麼這個接口是不穩定的，會因爲某個功能的變動而引發這個大接口的改動，顯然增加了維護成本。

10. 迪米特法則
    迪米特法則又叫“最少知道原則”。一個類應該對自己調用的類知道得最少，我只和朋友類交流。

    朋友類的定義是這樣的：出現在成員變量、方法的輸入參數、方法的輸出參數中的類稱爲成員朋友類，而出現在這個類的某個方法體內部的類不屬於朋友類。

    方法是類的一個行爲，在類的某個方法裏使用另外一個類作爲方法的局部變量，類竟然不知道自己的行爲與其他類產生了依賴關係，這是不允許的。類與類之間的關係是建立在類間的，而不是方法間，因此一個方法儘量不引入一個類中不存在的對象，當然，JDK API提供的類除外。

    朋友間也是有距離的。迪米特法則要求類“羞澀”一點，儘量不要對外公佈太多的public方法和非靜態的public變量，儘量內斂，多使用private。一個類公開的public屬性或方法越多，修改時涉及的面也就越大，變更引起的風險擴散也就越大。