註明：下面都是我在學習《大話設計模式》做的筆記，為了傳播設計模式和自我提醒學習。
*****===1、單一職責原則：
就乙個類而言，應該僅有乙個引起它變化的原因
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制
這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭到意想不到的破壞。
當然，軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。其實要去判斷是否應該分離出類來，
也不難，那就是如果你能夠想到多於乙個動機去改變乙個類，那麼這個類就具有多於乙個的職責，就應該考慮類的
職責的分離。
2、**********=開放-封閉原則
兩個特徵：乙個是說：「對於擴充套件是開放的(open for extension)」，另乙個是說：「對於更改是封閉的（closed for modification）」
why：怎樣的設計才能面對需求的改變卻可以保持相對穩定，從而使得系統可以在第乙個版本以後不斷推出新的版本呢？
why：何時應對變化
無論模組是多麼的『封閉』，都會存在一些無法對之封閉的變化，既然不可能完全封閉，設計人員必須對於他設計的模組應該
對哪種變化封閉做出選擇。他必須猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。
等到變化發生時立即採取行動。
==== 在我們最初編寫**時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離以後發生的同類變化。
我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難。
= 面對需求，對程式的改動是通過增加新**進行的，而不是更改現有的**。這就是『開放-封閉原則』
== 「開放-封閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是
可維護，，可擴充套件，可復用，靈活性好」，開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然而，對於應用程式中的
每個部分都刻意地進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
**********=3、依賴倒轉原則：
抽象不應該依賴細節，細節應該依賴於抽象，針對介面程式設計，不要針對實現程式設計；
*這也說明世間萬物都是遵循某種類似的規律，誰先把握了這些規律，誰就最早成為了強者。
依賴倒轉原則：高層模組不應該依賴底層模組，兩個都應該依賴抽象；
抽象不應該依賴細節。細節應該依賴抽象。
+++依賴倒轉模式其實可以說是物件導向設計的標誌，用哪種語言編寫程式都不重要，如果編寫時
考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止於抽象類或者
介面，那就是物件導向的設計，反之那就是過程化的設計。
*****===4、裡式代換原則：
概念：乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件
的區別。也就是說，在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。
== 子型別必須能夠替換掉它們的父型別。
--只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上
增加新的行為。
由於子型別的可替換性才使得父型別的模組在無需修改的情況下就可以擴充套件。
設計模式的四大原則
這幾天 寫完了，開始收拾起本該寒假就讀完的 大話設計模式 整本書讀起來還是不錯的，語言詼諧有趣，以生活中的例子為切入點，使讀者容易理解。比較適合物件導向語言的初學者或者中級人員學習。在這個系列學習中，我們先從設計模式的四大原則開始學起 四大原則 單一職責 就乙個類而言，應該僅有乙個引起它變化的原因。...
物件導向程式設計的四大原則
1.開閉原則 the open closed principle ocp 乙個模組在擴充套件性方面應該是開放的而在更改性方面應該是封閉的 因此在進行物件導向設計時要盡量考慮介面封裝機制 抽象機制和多型技術 擴張性開放，更改性關閉 依賴介面和抽象類，介面優先抽象類。2.替換原則 子類應當可以替換父類並...
設計模式之四大原則
看了大話設計模式，想自己總結一下，以加深印象。本次來總結設計模式中的設計原則。以下大部分來自大話設計模式 一 單一職責原則 它的準確解釋是 就乙個類而言，應該僅有乙個引起它變化的原因。通俗的說，就是乙個類不應該有太多的職責，不然的話，當需求發生改變時，你要改動的地方可能非常多且複雜，設計會遭到意想不...