@(0.05@設計模式)[設計模式|**規範|筆記--大話設計模式]
物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件、封閉更改的效果。
1、單一職責原則
就乙個類而言, 應該僅有乙個引起它變化的原因. 增加功能不應該修改已有的**, 避免修改出錯及重複測試.
如果你能夠想到多於乙個的動機去改變乙個類,那麼這個類就是具有多於乙個的職責, 應該考慮類的職責分離.
2、黎克特制代換原則
父型別可以被子型別替換,程式行為不發生變化. 這樣父類才能真正的被復用, 而子類也能夠在父類的基礎上增加新的行為.
黎克特制替換原則通俗的來講就是：子類可以擴充套件父類的功能，但不能改變父類原有的功能。它包含以下4層含義：
3、依賴倒轉原則(物件導向設計的標誌)高層模組不應該依賴底層模組. 兩個都應該依賴抽象.
抽象不應該依賴細節, 細節應該依賴抽象.
依賴倒轉就是誰也不依賴誰,除了約定的介面,大家都可以靈活自如.
程式中所有的依賴關係都是終止於抽象類或者介面,那就是物件導向的設計,反之就是過程化的設計.
在實際程式設計中，我們一般需要做到如下3點：
依賴倒置原則的核心就是要我們面向介面程式設計，理解了面向介面程式設計，也就理解了依賴倒置。傳遞依賴關係有三種方式，以上的例子中使用的方法是介面傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞.
4、介面隔離原則
定義：客戶端不應該依賴它不需要的介面；乙個類對另乙個類的依賴應該建立在最小的介面上。
介面隔離原則的含義是：建立單一介面，不要建立龐大臃腫的介面，盡量細化介面，介面中的方法盡量少。也就是說，我們要為各個類建立專用的介面，而不要試圖去建立乙個很龐大的介面供所有依賴它的類去呼叫。
很多人會覺的介面隔離原則跟之前的單一職責原則很相似，其實不然。其一，單一職責原則原注重的是職責；而介面隔離原則注重對介面依賴的隔離。其二，單一職責原則主要是約束類，其次才是介面和方法，它針對的是程式中的實現和細節；而介面隔離原則主要約束介面介面，主要針對抽象，針對程式整體框架的構建。
採用介面隔離原則對介面進行約束時，要注意以下幾點：
運用介面隔離原則，一定要適度，介面設計的過大或過小都不好。設計介面的時候，只有多花些時間去思考和籌畫，才能準確地實踐這一原則。5、迪公尺特法則(最少知識原則)
定義：乙個物件應該對其他物件保持最少的了解。
問題由來：類與類之間的關係越密切，耦合度越大，當乙個類發生改變時，對另乙個類的影響也越大。
如果兩個類不必彼此直接通訊,那麼這兩個類就不應當發生直接的相互作用. 如果其中乙個類需要呼叫另乙個類的某乙個方法的話, 可以通過第三者**這個呼叫.
前提：在類的設計上，每乙個類都應當盡量降低成員的訪問許可權。
6、開放-封閉原則
定義：乙個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉。
問題由來：在軟體的生命週期內，因為變化、公升級和維護等原因需要對軟體原有**進行修改時，可能會給舊**中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有**經過重新測試。
解決方案：當軟體需要變化時，盡量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的**來實現變化。
設計類時, 盡量讓這個類是足夠好,寫好了就不要去修改,如果新需求來,增加一些類就完事,原來的**能不動就不動.
設計人員需要猜測出最有可能發生的變化種類,然後構造抽象來隔離那些變化.
發生小的變化時，就要及時去想辦法應對發生更大變化的可能，重構修改同一處**時要一次搞定，同乙個地方不要修改2次。
開閉原則是物件導向設計中最基礎的設計原則，它指導我們如何建立穩定靈活的系統。開閉原則可能是設計模式六項原則中定義最模糊的乙個了，它只告訴我們對擴充套件開放，對修改關閉，可是到底如何才能做到對擴充套件開放，對修改關閉，並沒有明確的告訴我們。以前，如果有人告訴我「你進行設計的時候一定要遵守開閉原則」，我會覺的他什麼都沒說，但貌似又什麼都說了。因為開閉原則真的太虛了。
在仔細思考以及仔細閱讀很多設計模式的文章後，終於對開閉原則有了一點認識。其實，我們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要我們對前面5項原則遵守的好了，設計出的軟體自然是符合開閉原則的，這個開閉原則更像是前面五項原則遵守程度的「平均得分」，前面5項原則遵守的好，平均分自然就高，說明軟體設計開閉原則遵守的好；如果前面5項原則遵守的不好，則說明開閉原則遵守的不好。
其實筆者認為，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴充套件細節。因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟體架構的穩定。而軟體中易變的細節，我們用從抽象派生的實現類來進行擴充套件，當軟體需要發生變化時，我們只需要根據需求重新派生乙個實現類來擴充套件就可以了。當然前提是我們的抽象要合理，要對需求的變更有前瞻性和預見性才行。
說到這裡，再回想一下前面說的5項原則，恰恰是告訴我們用抽象構建框架，用實現擴充套件細節的注意事項而已：
最後說明一下如何去遵守這六個原則。對這六個原則的遵守並不是是和否的問題，而是多和少的問題，也就是說，我們一般不會說有沒有遵守，而是說遵守程度的多少。任何事都是過猶不及，設計模式的六個設計原則也是一樣，制定這六個原則的目的並不是要我們刻板的遵守他們，而需要根據實際情況靈活運用。對他們的遵守程度只要在乙個合理的範圍內，就算是良好的設計。參考文獻 :
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
參考文章 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放，對修改關閉。...
設計模式六大原則
1.單一職責原則 乙個類只負責一項職責 2.黎克特制替換原則 定義1 如果對每乙個型別為 t1的物件 o1，都有型別為 t2 的物件o2，使得以 t1定義的所有程式 p 在所有的物件 o1 都代換成 o2 時，程式 p 的行為沒有發生變化，那麼型別 t2 是型別 t1 的子型別。定義2 所有引用基類...