設計模式乃系統程序設計心法，多讀益善。
方法/步驟
『Single Responsibility Principle』單一職責原則：
單一職責原則的核心精神是：一個類，或者一個接口，最好只做一件事情，當發生變化時，他只能受到單一的影響；因為職責過多，可能引起變化的原因將會很多，這樣導致職責和功能上的依賴，將嚴重影響其內聚性和耦合度，混亂由此而生。
單一職責的原則在現實生活中早就實踐於現代公司體制與工業生產上，如公司的各個部門職責分明相互獨立，生產流水線的某一環節只需關注上螺絲，而另一環節只做零件組裝等等；這一原則使龐大的系統組合起來還能各司其職，井井有條，即使某個部門、某個環節出了問題或需要改動，你只需去動那個要變動的地方即可，從而避免因職責功能不明而導致不必要的的混亂。同樣，程序代碼的設計也是如此，功能和職責單一化也是衡量代碼優良的一個標準；交雜不清的職責和功能將使得代碼看起來特別別混亂、彆扭且一發而動全身，更嚴重的是在日後的維護中你得花更多的時間去理清他的邏輯，並且這地方的變動幾乎是必然引起讓人頭痛的BUG，你將花費更多的精力，承擔更多的風險！
在代碼工程的實施中，遵循單一職責原則將會帶來諸多好處：類的複雜性將降低，簡單明細的代碼將使可讀性將大大提高，自然而然可維護性亦將同步提高，可維護性提高將預示著因變更引起的風險會大大降低，最重要的前邊的好處將會是你工作輕鬆愉悅、思路清晰、遠離腦爆頭大……專注即高效，單一既輕鬆，人事皆如此。
『Liskov Substitution Principle』里氏替換原則
里氏替換原則的核心精神是：在使用基類的的地方可以任意使用其子類，能保證子類完美替換基類；這一精神其實是對繼承機制約束規範的體現。在父類和子類的具體實現中，嚴格控制繼承層次中的關係特徵，以保證用子類替換基類時，程序行為不發生問題，且能正常進行下去。
里氏替換原則主要發力點是繼承基礎上的抽象和多態，具體就是子類必須實現父類的方法，是重寫；這裡要注意重寫（Override）與重載（Overload）的區分，即使參數的數據範圍發生變化，也能將重寫變成重載！而你原本只是想把所繼承的方法完善的具體點兒！如果是這樣的話絕對會引起以後業務邏輯的混亂。
里氏替換原則是關於繼承機制的設計原則，違反里氏替換原則將會使繼承變的一塌糊塗；而遵循里氏替換原則能夠保證系統具有良好的的拓展性，我們可以隨時根據需要增改不同的子類，這將大大增強程序的健壯性，讓版本的升級可以做到非常好的兼容；同時基於多態的抽象機制，能夠很好的減少代碼冗餘，避免運行期的類型判別等；而在項目的實施中不同的子類對應著不同的業務，使用父類做參數，不同子類可以輪番上陣，必然強大！
*在此重溫【重寫與重載】
多態性是面向對象編程的一種特性，和方法本身無關。
方法的重載，就是同樣的一個方法能夠根據輸入數據的不同，做出不同的處理——有不同的參數列表，甚至不同的返回值（靜態多態性）
方法的在重寫，是子類繼承自父類的相同方法，輸入參數一樣，但要做出有別於父類的操作，要覆蓋父類方法。——相同參數，相同返回值，不同實現（動態多態性）
用好重寫和重載可以設計一個結構清晰而簡潔的類，重寫和重載在編寫代碼過程中的作用非同凡響。
『Interface Segregation Principle』接口隔離原則
接口隔離原則的核心精神是：儘量使用多個專門的單一的小接口，避免龐大的總接口；專業點的說法是類間的依賴關係儘量建立在最小的接口上。接口儘量的小，但是小不是說一個接口一個方法，小也要不違背單一職責原則；接口應該嚴格體現內聚性，儘可能的少公佈public方法，在開發中不能讓功能繁瑣的大接口出現；一個類對另一個類的依賴應該建立在最小的接口上，不能強迫與之無關的方法，否則將會造成接口汙染。遵循接口隔離原則將使接口有效的將細節和抽象隔離，體現了對抽象編程的一切優點，接口隔離強調接口的單一性。而大接口因強制要求實現類完成它所有的並非必須的方法、屬性等，從而造成嚴重的設計浪費，對以後的維護和改動帶來難以衡量的困難，對“接口”這個概念造成極大的侮辱。
但在現實中，如何把握接口越小越好，這個度很難界定，顆粒度小固然靈活，但同時會造成結構的複雜化，以下有幾個把握規則可以參考：一個接口只服務於一個子模塊或業務邏輯，服務定製；通過業務邏輯壓縮接口中的public方法，讓接口看起來精悍；已經被汙染了的接口，儘量修改，如果變更風險太大，則用適配器模式進行轉化處理；根據具體的業務，深入瞭解邏輯，用心感知去控制設計思路。
具體如何實施接口隔離，主要有兩種方法：1、委託分離，通過增加一個新的接口類型來委託客戶的請求，隔離客戶和接口的直接依賴，注意這同時也會增加系統的開銷；2多重繼承分離，通過接口的多重繼承來實現客戶的需求，這種方式相對較好。具體的使用，視情況而定。
怎麼準確的實踐接口隔離原則呢？有一本書上寫得非常好：實踐、經驗和領悟。
『Low Of Demeter』迪米特法則
迪米特法則也叫做做最少知識原則，其核心精神是：不和陌生人說話，通俗之意是一個對象對自己需要耦合關聯調用的類應該知道的更少。這樣會導致類之間的耦合度降低，每個類都儘量減少對其他類的依賴，因此，這也很容易使得系統的功能模塊相互獨立，之間不存在很強的依賴關係。
迪米特法則很純情、比較保守，不希望和其他的類建立直接的接觸；如果真的需要交互關係，也是希望通過自己比較熟的中間類來傳達信息。因此，在迪米特法則的實際應用中可能會導致大量的中介類。
迪米特法則的核心就是解耦，弱耦合能使類的複用率提高，在實際中這個解耦是有限度的解耦，不能因法則而法則，應權衡利弊而為之。
『Open Close Principle』開閉原則
開放封閉原則，簡稱開閉原則。開閉原則是面向對象設計中“可複用設計”的基石原則，是面向對象設計中最重要的原則之一，屬於“易筋經”級別的，諸如里氏替換啦，接口隔離啦、依賴倒置啦，都可以看做是開閉原則的實現；在面向對象設計中，抽象類和接口，即是因開閉而生，應開閉而存！
開閉開閉，開放封閉。開放的是拓展，封閉的是修改，即降低耦合，封裝變化的集中展現。開放擴展，則意味著當有新的或變化的需求時，可以通過對現有代碼的拓展來實現，而不需要該變原有程序的結構與內容；封閉修改，指的是程序設計一旦完成，其預定功能即按照既定獨立工作，在不可對其做修改操作（太絕對了、太完美了！）開閉原則的核心思想就是抽象編程，而不是對具體，因為抽象是相對穩定的，再說了我們還有接口（好多地方接口和抽象類都放一塊兒說了）。讓類依賴於固定的抽象對象，即可以達到封閉修改的目的；而通過面向對象的繼承和多態機制，又可以實現對抽象類的繼承，通過複寫其方法來改變固有的行為操作，也可以實現新的拓展方法，即可以達到開放的目的。
歸根究底，開閉原則就是“萬變不離其宗”；變，即變的是需求，宗，既是系統強大穩定的基礎核心；開放封閉，既可以通過開放拓展滿足需求的變化，又可以通過封裝而使系統穩定。開閉原則，實乃程序設計心法，金剛般若波羅蜜！
『Dependence Inversion Principle』依賴倒置原則
依賴倒置原則，重要的三層含義：高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。其核心思想是：依賴於抽象。
關於“倒置”這個詞。準確的講，這是因為傳統的軟件開發方法，如結構化的分析和設計，傾向於創建高層模塊依賴於低層模塊、抽象依賴於具體的軟件結構。在實際上，這些方法的目標之一就是去定義描述上層模塊如何調用低層模塊的子程序層次結構。所以，相對於傳統的過程化的方法通常所產生的那種依賴結構，一個設計良好的面向對象的程序中的依賴結構就是“被倒置”的。
在系統代碼的實現中，依賴關係一定會存在於類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關係時，最好的方法就是分離接口和實現：在依賴之間定義一個抽象的接口使得高層模塊調用接口，而底層模塊實現接口的定義，以此來有效控制耦合關係，達到依賴於抽象的設計目標抽象的穩定性決定了系統的穩定性，因為抽象是不變的；依賴倒置原則的運用還可以減少並行開發引起的風險，提高代碼的可讀性和維護性。依賴於抽象是面向對象設計的精髓，也是依賴倒置原則的核心。
依賴倒置原則是許多面向對象技術的優點的根本。合理地應用它對於建立可複用的框架是必要的。對於構建富有變化彈力的代碼也是相當重要的。而且，由於抽象和具體相互完全分離，代碼的維護就容易很多了。依賴於抽象是一個通用的原則，而某些時候依賴於細節則是在所難免的，必須權衡在抽象和具體之間，方法不是一層不變的，技術只是一種業務關係實現的工具，取捨自知。