最近借了本閻博士的 Java與模式 開始學習設計模式。本人在設計模式方式純屬菜鳥，所以如果對某些模式的理解有偏差，還請大家及時指正。另外，本系列(《Java與模式》學習筆記)文章中許多語句都是來自原書，由於太多，基本沒有註明出處，如果閻博士認爲有侵權行爲，也別來找我，我只是小角色。^_^
這些軟件設計的基本原則是一種高度地抽象，如果說設計模式是軟件設計中經驗教訓的總結，那麼這些基本原則就是對設計模式的抽象，設計模式是實現這些原則的方式。所以這些原則纔是重中之重，學設計模式重在學其“劍意”，而不是學其“劍招”。而這些原則就是“劍意”，學到深處，心中就只有“意”，而無“招”了。
一、“開-閉”原則（OCP）
1。定義：一個系統應該對擴展開發，對修改關閉。
2。詳細解釋：在設計一個模塊的時候，應該使這個模塊可以在不被修改的前提下被擴展。也就是不修改原有的代碼，而擴展出一個新的功能。
3。自己的理解：開閉原則其實說的是對可變的部分進行封裝，並給這個具體實現一個抽象的接口或父類，這樣一來，當以後需要擴展新功能的時候，只需要增加一個新的類，繼承或實現這個父類或接口。或者直接繼承原來的具體實現。這樣這個模塊就可以在不修改原有代碼的條件下，擴展新的功能了。
4。補充：
1)多態性污染：濫用多態，對於可變性不強的部分也增加大量的冗餘代碼增強其可擴展性。這樣做是很沒必要的，是一種爲了模式而模式的做法。
2)具體類不是用來繼承的：只要有可能，不要從具體類繼承。
3)抽象類應該擁有儘可能多的共同代碼，而應該擁有儘可能少的數據。(抽象類中的代碼就算不使用，也不會佔用內存空間，而變量不管是否使用都會佔用內存)(創建一個子類對象時，JVM其實已經在子類對象中創建了一個父類的對象。)
4)使用繼承的原則：
必須是is-a關係，也就是子類是超類的一個特殊種類，而不是超類的一個角色
永遠不會出現需要將子類換成另一個類的子類的情況。
子類具有擴展超類的責任，而不是具有置換掉或註銷掉超類的責任(如果子類需要大良地置換掉超類的行爲，那麼這個子類就不應當成爲一個超類的子類)
只有在分類學角度上有意義時，纔可以使用繼承，不要從工具類繼承
二、里氏代換原則（LSP）
1。定義：如果一個方法可以接受一個父類對象作爲參數，那麼就一定可以接受這個父類的子類的對象。反過來的說法不成立。
2。自己的理解：這個原則已經被JAVA很好地支持了，我們只需要在程序中注意這個原則的使用就OK了。也就是要針對抽象編程，而不應該針對具體實現編程。
3。補充：
1)java語言對LSP的侷限：JAVA編譯器不能檢查一個系統在實現和商業邏輯上是否滿足里氏代換。最著名的例子是“正方形類是否是長方形類的子類”的問題。
2)墨子：白馬，馬也；乘白馬，乘馬也。驪馬，馬也；乘驪馬，乘馬也。(里氏轉換)
娣，美人也；愛娣，非愛美人也。盜，人也；惡盜，非惡人也。
三、依賴倒轉原則(DIP)
1。定義：要針對抽象編程，不應該針對具體實現編程。(DIP是OCP的實現方式)
2。補充：以來倒轉原則假定所有的具體類都是會變化的，但是在實際中並不完全如此，有些類是十分穩定的，對於這樣的類，就沒必要過多地去模式了。
四、接口隔離原則(ISP)
1。定義：使用多個專用的接口比使用單一的總接口要好。應該讓接口最小化，而不應該將不同角色的行爲定義在一個接口中。
2。自己的理解：看人下菜碟
五、合成/聚合複用原則(CARP)
1。定義：應該儘量使用合成/聚合，而少使用繼承
2。難點；設計時的is-a,has-a關係。這設計到OOD的思想。
六、迪米特法則（LoD）
1。定義：一個對象應當對其他對象有儘可能少的瞭解。
2。自己的理解：儘量減少對象間通信，隱藏具體實現，僅僅暴露有限的對外接口。
3。注意：
1)在類的劃分上，應當創建有弱耦合的類。
2)在類的結構設計上，每個類都應該儘量降低成員的訪問權限
3)一個類應當儘可能設計成不可變類
4)在對其他類的引用上，一個對象對其他對象引用應當降到最低
4。補充：
1)謹慎使用Serializable，原因：沒看明白