1.單一職責原則：
定義：單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因！
單一職責就是乙個類負責一種職責，比如，在物件導向的計算器中，每乙個計算的方式就有乙個對應的計算類。這個計算方式的業務都在這個類中，而其他的計算跟這個類無關。
我的例子也許不是非常的恰當，再例如，三層架構，就是對各種邏輯的封裝，如果乙個類承擔的封裝。bll的職責是業務邏輯，dal的職責是資料訪問，ui的職責就是介面顯示！
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞，軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。如果你能夠想到多於乙個的動機去改變乙個類，那麼這個雷就具有多於乙個的職責
程式設計時，我們就是要在類的職責分離上多思考，做到單一職責，這樣你的**才是真正的易維護、易擴充套件、易復用、靈活多樣。
2.開放-封閉原則。
開放封閉原則，是說軟體實體（如類、模組、函式等等）應該可以擴充套件，但是不可以修改。
我們經常會想，怎麼樣的設計才能面對需求的改變卻可以保持相對穩定，從而使得系統可以在第乙個版本以後不斷推出新的版本呢？開放封閉原則給了我們答案！即對擴充套件開放，對修改封閉！就像我們在wcf中的服務一樣，同乙個服務，怎麼做到後期的服務相容前期的服務呢，那就是多擴充套件。在原來處理的基礎上增加擴充套件處理，如果是早期版本則擴充套件處理不會執行。
無論模組式多麼的『封閉』，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化 [引用內容]
面對需求，對程式的改動是通過增加新**進行的，而不是更改現有**--這就是開放封閉原則的精神
開放封閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。然而，對於應用程式中的每個部分都可以的進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
3.依賴倒轉原則。
程式設計中，高層模組不應該依賴於低層模組，兩個都應該依賴抽象。抽象不應該依賴於細節，細節應該依賴抽象。這個大家都懂的，多型就是為了完成抽象。
比如，介面應該定義在高層模組，實現應該在低層模組。這樣實現依賴介面，以三層為例：在dal層中寫具體的實現，依賴介面，bll層呼叫介面也依賴介面，而bll和dal不互相依賴。
依賴倒轉其實可以說是物件導向設計的標誌，用哪種語言來編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有依賴關係都是終止於抽象類或者介面，拿酒是物件導向的設計，反之那就是過程話的設計了。
以上是我在學習設計模式中抽取出來的筆記。舉例全是我自己的理解。
看完了，有用就點下「頂」吧！！！
設計模式 1 原則
package cn.riversky 物件導向設計原則 1單一職責原則 乙個類只負責乙個功能領域中的相應職責 2開閉原則 軟體實體應對擴充套件開放，而對修改關閉 3 黎克特制替換原則 所有引用基類對應的地方能夠透明地使用其子類的物件。4 依賴倒轉原則 抽象不應該依賴於細節，細節應該依賴於抽象 5 ...
設計模式學習筆記之 二 設計模式之工廠模式
首先建立抽象物品類，以tom老師講的milk為例 milk 抽象介面 public inte ce milk 各類milk具體類實現該介面 蒙牛類 public class mengniu implements milk 特崙蘇 public class telunsu implements mil...
設計模式學習 設計原則
單一職責原則 就乙個類而言,應該僅有乙個引起他變化的原因 如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能來,這種耦合會導致脆弱的設計,當變化發生時,設計會遭受意想不到的破壞 如果你能想到多於乙個的動機去改變乙個類,那麼這個類就具有多餘乙個...