今天看了一本叫做大話設計模式的書，裏面提到了原則，所以就準備寫一篇文章，作爲讀後感，方便自己以後可以查看
單一職責原則
單一職責原則：就一個類而言，應該僅有一個引起它變化的原因
軟件設計真正要做的許多內容，就是發現職責並把那些職責相互分離，如果你能夠想到多餘一個的動機去改變一個類，
那麼這個類就具有多餘一個的職責，就應該考慮職責分離。達到易維護，易擴展，易複用，靈活多樣。一個類承擔的職責
過多，就等於把這些職責耦合在一起，一個職責發生變化可能會抑制或改變這個類完成其他職責的能力，這種耦合會導致
脆弱的設計，當發生變化時，設計會發生意向不到的破壞
例子：比如說俄羅斯方塊遊戲。可以分爲2個職責（遊戲邏輯職責，手勢按鍵職責）
遊戲邏輯職責： 對下落，變形，碰撞判斷，消除進行但是單一職責處理
手勢按鍵職責： 對手勢的上下左右職責進行處理
手勢指着和遊戲邏輯職責是保持相對獨立的，針對於每個職責下的功能都保持的單一職責，手勢的左右上下職責，
只是手勢的職責。並不會改變遊戲的邏輯職責。就像手勢上的職責會去調用遊戲邏輯裏面的變形職責，
但是並不會改變變形職責的處理，同理任何手勢職責都可以調用變形職責，但是卻改變不了變形職責的實現能力
開放-封閉原則
開放-封閉原則：對於軟件實體（類，模塊，函數等等）應該可以擴展，但是不可修改
開閉原則是面向對象設計的核心所在。遵循這個原則可以帶來面向對象技術所聲稱的巨大好處，也就是可維護，可擴展，
可複用，靈活性好。開發人員應該進隊程序中呈現出頻繁變化的那些部分作出抽象，然而，對於應用程序中的每個部分
都可以進行抽象同樣不是一個好主意，拒絕不成熟的抽象和抽象本身一樣重要。
例子：計算器的加減乘除
在設計計算器的時候就會有加減乘除等方法的實現，但是也可能會有其他方法的（次方，開方），但是邏輯是不會變，
輸入一個數字，針對於這個數字進行一些計算的操作。
所以在程序設計的時候就要對方法進行可擴展性，在定義的時候可以針對計算設計一個接口。數字和計算這兩個過程
是不變的，變化的是數字本身和計算的方式而已
那麼在設計的時候就可以設計一個具有計算方法的接口，加減乘除等其他計算方式去實現這個接口，就能夠達到開放關閉原則了
依賴顛倒原則
依賴顛倒原則：就是針對接口編程，不要針對實現編程
A、高層模塊不應該依賴低層模塊，兩者都應該依賴抽象
B、抽象不應該依賴細節，細節應該依賴抽象
依賴倒轉其實可以說是面向對象設計的標誌，如果邊寫時都是考慮針對抽象編程而不是針對於細節編程，
即程序中所有的依賴關係都是終止於抽象或者接口，那就是面向對象設計，反之則是過程化的設計。
例子：電腦的各個硬件
每個電腦硬件的功能實現都是針對於接口進行實現，所以當部分硬件工作出問題的時候，其他硬件也是可以正常
運行的。處理的時候對於出現問題的硬件進行更換或維修就行了
里氏替換原則
里氏替換原則： 子類型必須能夠替換父類型
一個軟件實體如果使用的是一個父類的話，那麼就一定適用於其子類，而且它察覺不出父類對象和子類對象的區別。
也就是說:在軟件裏面，把父類替換成它的子類，程序行爲是沒有
變化的，只有當子類能夠替換父類的時候，軟件單位的功能不受影響是，父類才能夠真正的複用，而子類也能夠在父類
的基礎上增加新的行爲。也正是由於子類型的可替換性才使得
父類型的模塊在無需修改的情況下就可以擴展
例子：貓（子類）是一種動物（父類）
動物（父類）可以吃，喝，跑，叫等功能，貓（子類）集成父類的所有功能，並且可以增加新的功能（爬樹）。
所以說貓（子類）可以完全替換父類的功能並且還能夠擴展新的功能
迪米特法則
迪米特法則：也叫最少知識法則（根本思想：強調了類之間的鬆耦合）
如果兩個雷不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類
的某一個方法的話，可以通過第三者轉發這個調用
迪米特法則首先強調的前提是在這個類的結構設計上，每一個類都應當儘量降低成員的訪問權限，也就是說這個類
包裝好自己的private狀態，不需要讓別的類知道的字段和行爲
就不要公開
類之間的耦合越弱，越有利於複用，一個出來弱耦合的類被修改，不會對有關係的類造成波及，也就是說：信息的
隱藏促進的軟件的複用
例子：一個朋友說他今天過生日喊你去吃飯。你不需要知道去的有哪些人，只需要知道去哪裏做什麼就行了，
其他的事情不需要知道，告訴你也太大的用處，反而會增加你的思考
時間和處理的能力
接口隔離原則
不是太懂，大致的意思是使用多個專門的接口，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口。