前言
好的系統，應該從寫整潔的代碼開始。再好的架構設計，要是使用的磚頭質量不佳，那造出來的就是危房。
一些老牌的設計原則，這裏瞭解一下。編碼時，我們未必經常會使用，但還是應該牢記於心。有了這些
內功心法（設計原則），至於什麼招式（設計模式）那都是一通百通的，一變百變的。
SOLID原則
SOLID是指：SRP（單一職責原則）、OCP（開閉原則）、LSP（里氏替換原則）、ISP（接口隔離原則）、
DIP（依賴反轉原則）。下面就聽我隨便瞎聊聊。
SRP（單一職責原則）
正如天下武功爲快不破一樣。這個原則是最簡單，但也是最難把控的。什麼叫單一。我覺得應按實際情況來
做分析。如果把人比做是一個系統。當系統還沒到很複雜的時候。也許我們會把，用手處理的運動（
例如：打羽毛球、打乒乓球）歸爲一類行爲。但當我們把這個人做的更精緻的時候，也許我們就會把
用手打一種球類運動歸爲一類行爲。所以什麼是單一，應該在現有的系統基礎上，以及現有的人力資源
上，把功能儘可能的劃分單一。畢竟分類越細，所要創建的模塊會越多，那自然維護的成本也就會越高。
所以，對SRP的最終描述我覺得應該是這樣的：
任何一個軟件模塊都應該只對一類行爲負責。而現有的系統規模和人力資源來決定這一類到底可以分的多細。
OCP（開閉原則）
對於開閉原則，我覺最有用，也是最好去實踐的。相對官方的定義是這樣的：
對修改關閉，對擴展開放
什麼意思呢，其實很好理解。需求是永遠會變動的。所以，我們在編碼時，只要牢記一個原則：
我寫的代碼，假如有一天，有新的需求增加或者調整（修復BUG不算），我只需要額外加一些類就可以搞定
的，而不是去修改原來的代碼來滿足未來可變的需求。
換句話說，我不管你用什麼黑科技，怎麼設計，只要後面的需求來了，不要讓我去修改原來的代碼，
那麼你的設計就是好的設計。所以什麼面向接口編程，抽象與實現的分離，SPI插件機制，工廠模式等等
這些招式都是在處理這個原則。
LSP（里氏替換原則）
這個原則也是比較好處理的。簡單的理解，就是對繼承或者接口實現進行了約束。通俗的講，可以這樣
解釋：
我們申明一個接口或者抽象類，分別有A、B、C三種實現。當上層在使用這個接口時，無論我使用ABC中
的任何一個實現，上層的功能都是可以良好合理工作的。
上面的定義還是不明白，沒關係。我舉個列子。例如，我們申明瞭一個"鳥"做爲基類。其中有個fly的方法。
我們用啄木鳥或者布穀鳥去實現，那是沒問題的，他們都能實現飛的動作。但是如果我們用雞去實現，發現fly這個方法無法實現，
於是就提示說這個方法不支持。這樣雞的實現就違反了LSP原則了。因爲當我們系統用雞的實例去替換時，
發現不能fly，那不就悲劇了麼。
ISP（接口隔離原則）
先拋出一句話，看能不能理解：
任何模塊或者層次的軟件設計，如果依賴了他不需要的東西，那都是有害的
具體舉個例子來解釋：例如我們有個類，其中有3個方法：方法1、方法2、方法3。而我們的模塊a功能只需要方法1，模塊b功能只需要方法2，
模塊c功能只需要方法3。如果我們使用同一個接口，包含這3個方法去編碼，那麼勢必，在模塊a的功能上雖然沒有用到方法2和方法3，
但也是被依賴了，假如有一天，方法2或者方法3被修改了，雖然模塊a沒有使用，但也必須需要重新編譯了。因此，我們應該把這3個方法，
拆分成3個不同的接口，各自模塊只依賴對應的接口。這樣任何其他方法被修改了，都不會影響當前模塊。這就是所謂的接口隔離原則。
換一句比較術語化的說法意思都是一樣一樣的：
客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
DIP（依賴反轉原則）
這個大家應該熟悉的不要不要的了。Spring就是靠IOC（控制反轉）出道的。其實這個原則也很簡單：
我們編碼時，要儘量依賴一些穩定的抽象層，而不要去依賴容易變動的實現層
接口往往比實現更加穩定，所以我們要基於依賴接口編程，不要依賴具體實現。那麼要怎麼實現不依賴具體實現，就是上面說的控制反轉。
我們都知道，Java裏面接口是不能new的，需要有一個具體實現類來構建實例再向上轉型到接口引用。所以這裏有一個常見的做法，就是
使用工廠設計模式，創建一個工廠，專門用來實例化這些實例。這樣我們的模塊裏面只依賴了相對比較穩定的工廠類，而不是具體接口的實現
類。像Spring的IOC，也是利用類似模式，只不過他做的比較強大健全而已，構造了一個容器來管理這些實例，並設置了很多擴展點，讓我們
方便的干預實例的創建。
總結
正如上面所說了，這5大設計原則就是內功心法。武俠小說都看過吧，光有內功心法其實是不夠的。還需要學一點招式，就是所謂的設計模式。
但內功的深厚最終決定你能走多遠。最後，真正的大俠，是需要在實戰中磨練的。最後形成一套屬於自己的拳法，例如：黯然銷魂掌。但內功
心法是你的起步，需要時刻牢記。