設計模式--原則

1.單一職責原則

           簡單總結：就一個類而言，應該隻有一個引起它變化的原因，一個類中承擔的職責不宜多

                        如果 承擔的職責越多，可複用性越差 

                           承擔的職責越多，各職責間耦合性越強，修改一個職責，都有影響到其它職的風險        

               是實作高内聚、低耦合的指導方針，它是最簡單但又最難運用的原則    

              2.開閉原則

           簡單總結：一個軟體實體應該對擴充開放，對修改關閉。在不修改原有代碼的情況下進行擴充

                  把系統定義成一個相對穩定的抽象層，将不同行為移至具體的實作層中完成。

                 使軟體具有較好的穩定性和可延續性。

           抽象化是開閉原則的關鍵

           3.裡氏替換原則

         簡單總結：所有引用基類的地方必須能透明地使用其子類的對象

                     在軟體中将一個基類對象替換成它的子類對象，程式将不會産生任何錯誤和異常，反過來則不成立

                  在程式中經量使用基類對對象進行定義，而在運作時再确定其子類型，用子類對象來替換父類對象

           裡氏代換原則是開閉原則的具體實作手段之一

        4.依賴倒置原則

         簡單總結：抽象不應該依賴于細節，細節應當依賴于抽象。要對接口程式設計，而不是針對實作程式設計。

                    使用接口和抽象類進行變量類型聲明，參數類型聲明，方法傳回類型聲明，以及資料類型的轉換。而不用具體類來做這些事情。

                    針對抽象層程式設計，将具體類對象通過依賴注入的方式注入其它對象中（構造注入，設定注入（set方法），接口注入）

         開閉原則是目标，裡氏代換原則是基礎，依賴倒轉原則是手段

       5.接口隔離原則

        簡單總結：使用多個專門的接口，而不使用單一的總接口，用戶端不應該依賴于它不需要的接口

                     每個接口是一個獨立的較少，不幹不該幹的事，該幹的都得幹

                     給用戶端提供盡可能小的 接口，而不要提供大的總接口，僅僅提供客戶需要的行為 

         需要注意控制接口的粒度，接口不能太小，如果太小會導緻系統中接口泛濫，不利于維護；接口也不能太大，太大的接口将違背接口隔離原則，靈活性較差，使用起來很不友善

       6.合成複用原則

       簡單總結：盡量使用對象組合，而不是繼承來達到複用的目的

      7.迪米特法則

      簡單總結：一個對象應當對其他對象有盡可能少的了解

                       一個類應該對自己需要耦合或調用的類知道得最少，不關心被耦合或調用的類的内部實作，隻負責調用你提供的方法

                       不要和“陌生人”說話、隻與你的直接朋友通信----朋友指

  (1) 目前對象本身(this)；

             (2) 以參數形式傳入到目前對象方法中的對象；

              (3) 目前對象的成員對象；

                        (4) 如果目前對象的成員對象是一個集合，那麼集合中的元素也都是朋友；

                        (5) 目前對象所建立的對象

    在類的結構設計上，每一個類都應當盡量降低其成員變量和成員函數的通路權限

     在類的設計上，隻要有可能，一個類型應當設計成不變類；

     在對其他類的引用上，一個對象對其他對象的引用應當降到最低