這幾天重新看了一遍《大話設計模式》，發現果然有不同的感悟，而且自己也上網找了《敏捷軟體開發—原則、模式與實踐》一書來看，那本書的序言中有一段話我覺得很有道理：「美的東西比醜的東西建立起來更廉價，也更快捷。」設計乙個軟體不關要追求**的優雅問題，更關乎生產成本等。技術大師們在對軟體架構的研究中經歷了很長時間的摸索，從面向過程到物件導向，從設計原則到設計模式，總結了許多設計上的經典法則，而我們就只是站在巨人的肩膀上眺望遠方而已。
從《大話設計模式》中，大家一定會發現其中的經典的23個模式背後，其實都遵循著一些基本的原則的。而設計原則又由設計模式來實現，這就是二者相輔相成的關係，所以了解原則對於了解模式具有絕對的指導意義。以下是我在閱讀過程中的一些學習筆記，自以為有一定道理。
最基本的設計原則有5條，分別是：單一職責原則、開放封閉原則、依賴倒置原則、介面隔離原則和liskov替換原則。
單一職責原則
對於單一職責原則，其核心思想為：乙個類，最好只做一件事，只有乙個引起它的變化。單一職責原則可以看做是低耦合、高內聚在物件導向原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從而大大損傷其內聚性和耦合度。通常意義下的單一職責，就是指只有一種單一功能，不要為類實現過多的功能點，以保證實體只有乙個引起它變化的原因。
專注，是乙個人優良的品質；同樣的，單一也是乙個類的優良設計。交雜不清的職責將使得**看起來特別彆扭牽一髮而動全身，有失美感和必然導致醜陋的系統錯誤風險。
開放封閉原則
對於開放封閉原則，它是物件導向所有原則的核心，軟體設計說到底追求的目標就是封裝變化、降低耦合，而開放封閉原則就是這一目標的最直接體現。
開放封閉原則，其核心思想是：軟體實體應該是可擴充套件的，而不可修改的。也就是，對擴充套件開放，對修改封閉的。
因此，開放封閉原則主要體現在兩個方面：1、對擴充套件開放，意味著有新的需求或變化時，可以對現有**進行擴充套件，以適應新的情況。2、對修改封閉，意味著類一旦設計完成，就可以獨立完成其工作，而不要對其進行任何嘗試的修改。
實現開開放封閉原則的核心思想就是對抽象程式設計，而不對具體程式設計，因為抽象相對穩定。讓類依賴於固定的抽象，所以修改就是封閉的；而通過物件導向的繼承和多型機制，又可以實現對抽象類的繼承，通過覆寫其方法來改變固有行為，實現新的拓展方法，所以就是開放的。
「需求總是變化」沒有不變的軟體，所以就需要用封閉開放原則來封閉變化滿足需求，同時還能保持軟體內部的封裝體系穩定，不被需求的變化影響。
依賴倒置原則
對於依賴倒置原則，其核心思想是：依賴於抽象。具體而言就是高層模組不依賴於底層模組，二者都同依賴於抽象；抽象不依賴於具體，具體依賴於抽象。
我們知道，依賴一定會存在於類與類、模組與模組之間。當兩個模組之間存在緊密的耦合關係時，最好的方法就是分離介面和實現：在依賴之間定義乙個抽象的介面使得高層模組呼叫介面，而底層模組實現介面的定義，以此來有效控制耦合關係，達到依賴於抽象的設計目標。
抽象的穩定性決定了系統的穩定性，因為抽象是不變的，依賴於抽象是物件導向設計的精髓，也是依賴倒置原則的核心。
依賴於抽象是乙個通用的原則，而某些時候依賴於細節則是在所難免的，必須權衡在抽象和具體之間的取捨，方法不是一層不變的。依賴於抽象，就是對介面程式設計，不要對實現程式設計。
介面隔離原則
對於介面隔離原則，其核心思想是：使用多個小的專門的介面，而不要使用乙個大的總介面。
具體而言，介面隔離原則體現在：介面應該是內聚的，應該避免「胖」介面。乙個類對另外乙個類的依賴應該建立在最小的介面上，不要強迫依賴不用的方法，這是一種介面汙染。
介面有效地將細節和抽象隔離，體現了對抽象程式設計的一切好處，介面隔離強調介面的單一性。而胖介面存在明顯的弊端，會導致實現的型別必須完全實現介面的所有方法、屬性等；而某些時候，實現型別並非需要所有的介面定義，在設計上這是「浪費」，而且在實施上這會帶來潛在的問題，對胖介面的修改將導致一連串的客戶端程式需要修改，有時候這是一種災難。在這種情況下，將胖介面分解為多個特點的定製化方法，使得客戶端僅僅依賴於它們的實際呼叫的方法，從而解除了客戶端不會依賴於它們不用的方法。
分離的手段主要有以下兩種：1、委託分離，通過增加乙個新的型別來委託客戶的請求，隔離客戶和介面的直接依賴，但是會增加系統的開銷。2、多重繼承分離，通過介面多繼承來實現客戶的需求，這種方式是較好的。
liskov替換原則
對於liskov替換原則，其核心思想是：子類必須能夠替換其基類。這一思想體現為對繼承機制的約束規範，只有子類能夠替換基類時，才能保證系統在執行期內識別子類，這是保證繼承復用的基礎。在父類和子類的具體行為中，必須嚴格把握繼承層次中的關係和特徵，將基類替換為子類，程式的行為不會發生任何變化。同時，這一約束反過來則是不成立的，子類可以替換基類，但是基類不一定能替換子類。
liskov替換原則，主要著眼於對抽象和多型建立在繼承的基礎上，因此只有遵循了liskov替換原則，才能保證繼承復用是可靠地。實現的方法是面向介面程式設計：將公共部分抽象為基類介面或抽象類，通過extract abstract class，在子類中通過覆寫父類的方法實現新的方式支援同樣的職責。
liskov替換原則是關於繼承機制的設計原則，違反了liskov替換原則就必然導致違反開放封閉原則。
liskov替換原則能夠保證系統具有良好的拓展性，同時實現基於多型的抽象機制，能夠減少**冗餘，避免執行期的型別判別。
以上就是5個基本的設計原則，它們就像物件導向程式設計中的金科玉律，遵守它們可以使我們的**更加鮮活，易於復用，易於拓展，靈活優雅。不同的設計模式對應不同的需求，而設計原則則代表永恆的靈魂，需要在實踐中時時刻刻地遵守。就如arthur j.riel在那邊《ood啟示錄》中所說的：「你並不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看做警鈴，若違背了其中的一條，那麼警鈴就會響起。」
請記住這些技術大師的名字和作品，並深入研習其中的招式和經驗，正是他們讓物件導向程式設計變得如此光彩奪目，沿著這些智慧型的道路一直走下去，我覺得，我們會不僅僅提高了技術，還會發現設計以外的東西，因為oop還蘊含著人生的很多智慧型。
物件導向的5個基本設計原則
1.單一職責原則 single resposibility principle 其核心思想為 乙個類，最好只做一件事，只有乙個引起它的變化。是低耦合 高內聚在物件導向原則上的引申。2.開放封閉原則 open closed principle 其核心思想是 軟體實體應該是可擴充套件的，而不可修改的。也...
61條物件導向設計的經驗原則
你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。arthur j.riel 1 所有資料都應該隱藏在所在的類的內部。p13 2 類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。p15 3 儘量減少類的協議中的訊息。p16...
61條物件導向設計的經驗原則
你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。arthur j.riel 1 所有資料都應該隱藏在所在的類的內部。p13 2 類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。p15 3 儘量減少類的協議中的訊息。p16...