一點說明：oo的五大原則是指srp、ocp、lsp、dip、isp。這五個原則是書中所提到的。除此之外，書中還提到一些高層次的原則用於組織高層的設計元素，這些放到下次再寫。當然，oo設計的原則可能不止這五個，希望大家多提寶貴意見，多多交流。
在學習和使用oo設計的時候，我們應該明白：oo的出現使得軟體工程師們能夠用更接近真實世界的方法描述軟體系統。然而，軟體畢竟是建立在抽象層次上的東西，再怎麼接近真實，也不能替代真實或被真實替代。
oo設計的五大原則之間並不是相互孤立的。彼此間存在著一定關聯，乙個可以是另乙個原則的加強或是基礎。違反其中的某乙個，可能同時違反了其餘的原則。因此應該把這些原則融會貫通，牢記在心！
1. srp（single responsibility principle 單一職責原則）
單一職責很容易理解，也很容易實現。所謂單一職責，就是乙個設計元素只做一件事。什麼是「只做一件事」？簡單說就是少管閒事。現實中就是如此，如果要你專心做一件事情，任何人都有信心可以做得很出色。但如果，你整天被亂七八糟的事所累，還有心思和精力把每件事都作好麼？
「單一職責」就是要在設計中為每種職責設計乙個類，彼此保持正交，互不干涉。這個雕塑（二重奏）就是正交的乙個例子，鋼琴家和小提琴家各自演奏自己的樂譜，而結果就是乙個和諧的交響樂。當然，真實世界中，演奏小提琴和彈鋼琴的必須是兩個人，但是在軟體中，我們往往會把兩者甚至更多攪和到一起，很多時候只是為了方便或是最初設計的時候沒有想到。
這樣的例子在設計中很常見，書中就給了乙個很好的例子：數據機。這是乙個數據機最基本的功能。但是這個類事實上完成了兩個職責：連線的建立和中斷、資料的傳送和接收。顯然，這違反了srp。這樣做會有潛在的問題：當僅需要改變資料連線方式時，必須修改modem類，而修改modem類的結果就是使得任何依賴modem類的元素都需要重新編譯，不管它是不是用到了資料連線功能。解決的辦法，書中也已經給出：重構modem類，從中抽出兩個介面，乙個專門負責連線、另乙個專門負責資料傳送。依賴modem類的元素也要做相應的細化，根據職責的不同分別依賴不同的介面。最後由modemimplementation類實現這兩個介面。
從這個例子中，我們不難發現，違反srp通常是由於過於「真實」地設計了乙個類所造成的。因此，解決辦法是往更高一層進行抽象化提取，將對某個具體類的依賴改變為對一組介面或抽象類的依賴。當然，這個抽象化的提取應該根據需要設計，而不是盲目提取。比如剛才這個modem的例子中，如果有必要，還可以把datachannel抽象為datasender和datareceiver兩個介面。
物件導向五大原則之單一職責原則
單一職責原則 single pesponsibility principle,srp 可以理解為 分工明確,該是誰做的事情,就是誰做.安安分分的完成自己的任務即可.比如controller層和model層,該是資料處理就處理資料,該是整合資料就整合資料.在php核心技術與最佳實踐一書中有說到 單一職...
OO設計五大原則
oo的五大原則是指srp ocp lsp dip isp 1.srp single responsibility principle 單一職責原則 單一職責很容易理解，所謂單一職責，就是乙個設計元素只做一件事。srp 原則的核心含義是只能讓乙個類有且只有乙個職責，永遠不要讓乙個類存在多個改變的理由。...
OO的五大原則
oo的五大原則是指srp ocp lsp dip isp 1.srp single responsibility principle 單一職責原則 單一職責很容易理解，所謂單一職責，就是乙個設計元素只做一件事。2.ocp open close principle 開閉原則 一句話 closed fo...