設計模式之SOLID原則
面向物件軟體設計：SOLID 原則
Single-responsibility principle
A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.
"Software entities ... should be open for extension, but closed for modification."
"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also design by contract.
Interface segregation principle
"Many client-specific interfaces are better than one general-purpose interface."
Dependency inversion principle
One should "depend upon abstractions, [not] concretions.
一：單一職責原則[Single-responsibility principle]---SRP
解釋：一個類或者模組只是負責完成一個職責，通俗的理解就是一個模組，類，方法不要承擔過多的任務。
設計類應該遵循：設計粒度小，功能單一的類。
實際開發中：不必嚴格遵守，但是可以設計一個粗粒度的類，隨著業務的發張，再進行重構。
實際開發中可以按照以下參考意見：
1:依賴過多的其他類，或者程式碼直接依賴關係過於複雜時，不符合高內聚低耦合的設計思想時，就可以考慮對程式碼進行拆分。 2：類的名稱或者實際的功能關係不大或者沒關係，可以更加細粒度的拆分，把無關的功能獨立出去。 3：類的程式碼函式過多影響可讀性和程式碼維護時，可以對程式碼進行方法級別的拆分
二 ：開閉原則[Open–closed principle]---OCP
解釋：軟體實體(模組，類，方法等)應該對擴充套件開放，對修改關閉，通俗理解就是新增一個功能應該在已有的程式碼上進行擴充套件，而不是修改已有的程式碼。
開閉原則的目的是為了程式碼的可擴充套件性，並且避免了對現有程式碼的修改而給軟體帶來風險。
實際開發中可以按照以下參考意見：
1:業務驅動的系統,需要充分了解業務需求，找到對應的擴充套件點。 如果不確定因素過多，需求變化過快，則可以對一些比較確定的，短期內就可能會擴充套件的，通過設計擴充套件點，能明顯提高程式碼的穩定性和開發效率的地方進行設計。
2;如果是通用型的技術，比如框架，元件，類庫，你應該考慮該技術框架如何被使用者使用，考慮升級和相容性問題
三：裡式替換原則[Liskov substitution principle]----LSP
解釋：子類物件能夠替換程式中父類物件出現的任何地方，並保證原來的程式的邏輯行為不變以及正確性不被破壞。
可以利用面向物件的多型性來實現，多型和裡式替換原則類似， 多型是面向物件的特性，而裡式替換原則是一種設計原則，用來指導繼承關係中子類該如何設計，子類的設計要確保在替換父類的時候，不改變程式原有的邏輯以及不破快原有程式的正確性。
具體的實現方式可以理解為：
子類在設計時候，要遵循父類的行為約定。父類定義了方法的行為，子類可以改變方法的內部實現[重寫]，但是不改變方法原有的行為約定如：介面/方法 宣告要實現的功能，對引數值，返回值，異常的約定。
四： 介面隔離原則[Interface segregation principle]----ISP
解釋：客戶不應該強迫依賴他不需要的介面。
具體的實踐可以參考如下：
1：對於介面定義來說，如果某個介面承擔了與他無關的介面定義，則說明了該介面違反了介面隔離的原則，可以把無關的介面剝離出去。
2：對於共通的功能來說，應該細分功能點，按需新增，而不是定義一個大而全的介面，讓子類去實現。
五：依賴倒置原則[Dependency inversion principle]----DIP
解釋：高層模組不要依賴低層模組。高層模組和低層模組應該通過抽象來互相依賴。除此之外，抽象不要依賴具體實現，具體實現依賴抽象。
這裡的高層模組，從程式碼的角度來看就是呼叫者，低層模組就是被呼叫者。