前面學習了一部分建立型模式，發現了乙個比設計模式更重要的東西：設計模式原則。對於設計模式來說，為什麼這個模式要這樣解決這個問題，而另乙個模式要那樣，它們背後都遵循的就是永恆的設計原則。可以說，設計原則是設計模式的靈魂。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
三大基本物件導向設計原則：
1.
針對介面程式設計，而不是針對實現程式設計
；
2。優先使用物件組全，而不是類繼承；
3.封裝變化點。
下面開始學習常用的具體的一些設計模式原則：
1.
單一職責原則（
srp）
單一職責原則（
srp），就乙個類而言，應該僅有乙個引起它變化的原因。也就是說，不要把變化原因各不相同的職責放在一起，因為不同的變化會影響到不相干的職責。再通俗一點地說就是，不該你管的事情你不要管，管好自己的事情就可以了，多管閒事害了自己也害了別人。
在軟體設計中，如果乙個類承擔的職責過多，就等於吧這些職責耦合在一起，而乙個職責的變化可能會削弱和抑制這個類完成其他職責的能力。這耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。如果多於乙個的動機去改變乙個類，那麼這個類就具有多餘乙個的職責，就應該要考慮類的職責分離。
2.
開放
-封閉原則（
the open-closed principle
簡稱
ocp）
開放
-封閉原則，或叫開
-閉原則，是說軟體實體
(類、模組、函式等
)應該是可以擴充套件的，但是不可修改。不修改的意思就是是「你可以隨便增加新的類，但是不要修改原來的類」。從這個角度去理解就好多了，其實這裡還是乙個隔離變化的問題。
這個原則的兩個特徵：乙個是對於擴充套件是開放的；另乙個是對於更改是封閉的。
我們在設計開發任何系統時，都不可能指望系統一開始就需求確定，就不再變化（要這樣就太幸福了，哈哈），這是不現實的也是不科學的想法。既然需求是有一定變化的，那麼如何在面對需求變化時，設計的程式可以相對容易的修改，不至於說，新需求一來，就要把整個程式推倒重來
(這樣會讓程式設計師瘋了不可，哈哈，你不想瘋吧
)。怎樣的設計才能面對需求的改變卻可以保持相對穩定，從而使得系統可以在第乙個版本以後不斷推出的新版本呢？開放
-封閉原則就是我們的答案。
在程式設計時，我們要時刻考慮盡量把類設計的足夠好，寫好了就不要去修改，如果有新的需求來了，我們增加一些類來完成新的需求，原來的**能不動就不動。
絕對的對修改關閉是不可能的，無論模組是多麼的封閉，都會存在一些無法對之封閉的變化，既然不能完全封閉，設計人員必須對他設計的模組應該對那種變化封閉做出抉擇、他必須事先猜測出最有可能發生變化的變化種類，然後構建抽象來隔離那些變化。
開放-封閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所生成的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的部分都做出抽象，然後，對於應用程式中的每部分都刻意定進行抽象同樣不是乙個好主意，拒絕不成熟的抽象和抽象本身一樣重要。
3.
依賴倒轉原則
依賴倒轉原則：抽象不應該依賴於細節。細節應該依賴於抽象；高層不應該依賴於底層，兩者都應該依賴於抽象。說白了就是要針對介面程式設計，不要針對實現程式設計。抽象的東西才是最穩定的，也就是說，我們依賴的是它的穩定。
依賴倒轉其實可以說是物件導向設計的標誌，用哪種語言來編寫程式不重要，如果編寫是考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中的所有的依賴關係都是終止與抽象類或者介面，那就是物件導向的設計，反之就是過程化設計了。
4.
黎克特制代換原則
黎克特制代換原則（
lsp）：子型別必須能夠替換掉他的父型別。說白了就是乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而他察覺不出父類物件和子類物件的區別，也就是說，在軟體裡面，把父類都替換成他的子類，程式行為沒有變化。
有了黎克特制替換原則，才是繼承服用成為可能，只有當子類可以替換掉父類時，軟體的功能不受到影響，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。
有了黎克特制代換原則，才能使開放
-封閉原則成為可能，正是由於子型別的可替換性才使得父型別的模組在無需修改的情況下擴充套件。
5.
介面隔離原則(isp)
介面隔離原則(isp)
:
不應該強迫客戶依賴於它們不用的方法。介面屬於客戶，不屬於它所在的類層次結構。這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，如果強迫使用者使用它們不使用的方法，那麼這些客戶就會面臨由於這些不使用的方法的改變所帶來的改變。
6.
迪公尺特法則（lod）
迪公尺特法則（
law of demeter
或簡寫
lod）又叫最少知識原則（
least knowledge principle
或簡寫為
lkp）
:如果兩個類不彼此之間直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某個方法的話，可以通過第三者**這個呼叫。
迪公尺特法則首先強調的前提是在類的結構設計上，每乙個類都應當盡量降低成員的訪問許可權。
迪公尺特法則其根本思想強調的是類之間的松耦合。類之間的耦合越弱，越利於復用，乙個處於弱耦合的類被修改，不會對有關係的類造成波及。
7.
合成/聚合復用原則（composite/aggregate reuse principle或carp）
合成/聚合復用原則（composite/aggregate reuse principle或carp）：經常又叫做合成復用原則（composite reuse principle或crp），就是在乙個新的物件裡面使用一些已有的物件，使之成為新物件的一部分；新物件通過向這些物件的委派達到復用已有功能的目的。我白了就是要盡量使用合成
/聚合，盡量不要使用繼承。
七 常用設計模式詳解
單例模式 懶漢 餓漢雙重鎖單例 靜態內部類單例 列舉工廠模式 定義乙個建立物件的介面，讓其子類自己決定例項化哪乙個工廠類，工廠模式使其建立過程延遲到子類進行。分為 簡單工廠 抽象工廠 觀察者模式 當乙個物件的狀態發生改變時，所有依賴於它的物件都得到通知並被自動更新 觀察者和被觀察者是抽象耦合的 建立...
設計模式 （七）設計模式原則
1 乙個物件應該對其他物件保持最少的了解 2 類與類之間關係越密切，耦合度越大 3 迪公尺特法則又叫做最小知道原則，即乙個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類不管多麼複雜，都盡量將邏輯封裝在類的內部，對外除了提供的public方法，不對外洩露任何資訊 4 迪公尺特法則還有個更簡單...
設計模式學習筆記 設計模式概述
設計模式 design pattern 是一套被反覆使用 多數人知曉的 經過分類編目的 設計經驗的總結。使用設計模式是為了可重用 讓 更容易被他人理解 保證 可靠性。毫無疑問，設計模式於己於他人於系統都是多贏的 設計模式使 編制真正工程化 設計模式是軟體工程的基石脈絡，如同大廈的結構一樣。設計模式一...