0、前言
這一段時間一直在看設計模式，裡面分多次提到幾個設計原則，看了幾次發現記不清楚，還是得自己動手總結一下吧，把書上的理論先理解寫下來再說嘍。
1、單一職責原則
雖說我們要遵守單一職責原則，但是也不是說死板的對每乙個細節都嚴格遵守，也要視情況而定：如果乙個類的邏輯非常簡單且可以保證變化極小，此時可以在**級別上違反單一職責原則；另外當乙個類中方法很少時，也可以在方法的級別上違反這一原則。（這裡我這麼理解單一職責原則：分為兩個層次，最高層次是類的層次，其次是方法層次上）但是如果乙個類相對龐大，類中方法較多時，一定要遵守單一職責原則；寧願在第一次擴充套件時花費精力完成重構，也要遵守這一原則，否則會給以後的擴充套件帶來不可預估的災難！
2、裡式替換原則
繼承包含這樣一層含義：父類中凡是已經實現好的方法（區別於抽象方法），實際上是在設定一系列的規則和契約，雖然它並不要求所有的子類都必須強制遵守這些規則，但是如果子類任意對這些非抽象方法進行重寫，就會對整個繼承體系造成破壞。裡式替換原則主要就是想表達這一層含義。
當然如果你非要重寫父類的非抽象方法，這時應該採用這樣的方式：原來的父類和子類都繼承自乙個更通用的基類，原有的繼承關係去掉，轉而採用依賴、聚合、組合等關係來替代。
裡式替換原則更通俗的說就是：子類可以擴充套件父類的功能，但是不能修改父類原有的功能；具體有以下4中含義：
如果在開發中不遵循裡式替換原則程式也照樣跑的好好地，那麼也沒啥差別啊？這就錯了，這樣的後果就是你的**出錯的機率會大大的增加。
3、依賴倒轉原則
依賴倒轉原則基於這樣乙個事實：相對於細節實現中的多變性，抽象的東西要穩定的多；以抽象為基礎搭建起來的架構比以細節為基礎搭建起來的架構要穩定的多。具體來說（.net+c#），抽象一般指的是介面、抽象類，細節就是具體的實現類。使用抽象的目的是制定好規範和契約，而不要涉及具體的實現，把細節交給他們的實現類來完成。
依賴倒轉原則的核心就是面向介面程式設計，傳遞依賴關係有三種方式：介面傳遞、構造方法傳遞、setter傳遞（如果用過spring框架，那麼對傳遞一定會很熟悉）。在實際的開發中我們主要通過以下幾點來較好的遵守依賴倒轉原則：
遵循依賴倒轉原則可以降低類之間的耦合性，提高系統穩定性，降低修改造成的風險。同時，採用依賴倒轉原則給並行開發帶來了極大的便利，參與開發的人越多、專案越龐大依賴倒轉原則意義和好處就越明顯。當前比較流行的tdd開發模式就是依賴倒置原則非常成功的應用。
4、迪公尺特法則
通俗的來講，就是乙個類對自己以來的類知道的越少越好；也就是說對於被依賴的類來說，無論邏輯多麼複雜，都應當把邏輯封裝在內部，對外除了提供public方法之外，不洩露其他任何資訊。再通俗來說：迪公尺特法則就是『只與直接的朋友通訊』。那麼什麼是直接的朋友呢：每個物件都會與其他物件有耦合關係，只要兩個物件間出現耦合關係，我們就說兩個物件之間是朋友關係。而耦合的方式有很多，依賴、關聯、聚合、組合都是耦合關係；其中，我們稱出現成員變數、方法引數、方法返回值中的類為直接朋友，而出現在區域性變數中的類則是間接朋友關係。也就是說陌生的類最好不要作為區域性變數的形式出現在類的內部。
迪公尺特法則的初衷是降低類之間的耦合，但是凡事都有乙個度，雖然可以避免與非直接類之間的通訊，但是要通訊就必須通過乙個中介來發生關係；而過分的使用迪公尺特法則，就會產生大量這樣的中介和傳遞類，導致系統的複雜度增加。所以在使用迪公尺特法則時，要反覆權衡，既要做到結構清晰又要高內聚低耦合。
5、開放-封閉原則
開放-封閉原則是物件導向設計中最基礎的原則，它指導我們如何建立穩定、靈活的系統。但是他也是這幾個模式中定義最為模糊的乙個，在初接觸它時，總給你一種無處下手的感覺，因為它太虛了。但是當把其他原則還有23中設計模式通讀了一遍之後，我發現可以這麼理解它：開放-封閉原則是戰略，而其他的幾個原則以及設計模式就是具體的戰術；如何實現開放-封閉原則呢？要想實現乙個戰略，就必須要制定合適的戰術：即，通過較好的遵守其他幾個原則以及通過合適的設計模式，最終實現乙個軟體很好的開發-封閉原則。
※其他【介面隔離原則】
客戶端不應該依賴它不需要的介面，乙個類對另乙個類的依賴應該建立在最小的介面上。
可以這麼理解：如果介面過於臃腫，那麼實現他的類不管用不用的到，都必須實現介面中所有的方法，這顯然是不好的設計；這時候就需要遵循介面隔離原則對臃腫的介面進行拆分。他的原則就是：盡量建立單一的介面，盡量細化介面，介面中的方法盡量少。也就是說，我們要為各個類建立專用的介面，而不是試圖去建立乙個很龐大的介面共所有依賴他的類去呼叫。
這裡介面隔離原則與單一職責原則也有一定的區別，主要從以下方面來看：
但是在使用介面隔離原則時也一定要適度，一定要注意：
最後的這個介面隔離原則，我的看法就是：只是從更加細小的粒度上解釋了單一職責原則。因此在這裡放在最後的其他裡面描述他。同時，這幾個原則現在只是對照著定義還是自己很少的開發經歷來理解，很多還無法清楚的理解和使用，後面還有很長的路需要走啊，加油！
設計模式的6大原則
1 開閉原則 open close principle 1.1 定義 乙個軟體實體如類 模組和函式應該對擴充套件開放，對修改關閉。1.2 當軟體需要變化時，盡量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的 來實現變化。1.3 開閉原則是總綱，他告訴我們要對擴充套件開放，對修改關閉。2 ...
設計模式之6大原則
軟體程式設計的總原則 高內聚，低耦合。提高 的復用率 耦合的方式 依賴，關聯，組合，聚合等 設計模式之6大原則 1.單一職責原則 乙個類只負責乙個功能領域中的相應職責。是實現高內聚低耦合的指導方針。2.裡式替換原則 所有引用基類的地方必須能透明地使用其子類的物件。子型別必須能夠替換掉它們的父型別 既...
設計模式6大原則 總結
1.設計模式6大原則 封裝相關的3個 1，2，3 2.黎克特制替換原則 關注類與類相關直接的類，學校類只關注班級類，不關注學生類 1.任何使用基類的地方，都可以透明 安全，不會行為不一致 的使用其子類 2.子類可以有自己獨有的屬性和行為 3.父類實現的東西，子類不要在寫了 不要new 隱藏 防止出現...