晚
上在宿舍把webcast翻出來，聽了李建忠講的關於物件導向設計的幾天基本設計原則的課，半懂非懂聽了下來，聽完之後除了茫然還是茫然！也好，只有這樣才能知道自己所知甚淺，所學甚糙！革命遠未成功，吾須戒驕戒躁！
(ps:個人覺得李建忠講課水平一般，可能他是乙個非常好的程式設計師，但不是乙個好的講課員，大概程式設計師都有這個通病，寫個程式哪怕再複雜的程式都能應付自如，但讓他講課甚至是講幾句話，總讓人感覺詞不搭意，聽過李建忠講課的，肯定都會有這種感覺：斷斷續續，常為了表達乙個詞卡那半天，最後搜腸刮肚找出來的詞仍然是詞不搭意，但好在都是講給程式設計師聽的，大家基本都能明白他所要表達的意思)
原則一：單一職責原則(srp)
--- 乙個類應該僅有乙個引起它變化的原因(最簡單，最容易理解卻最不容易做到的乙個設計原則)
我想，所謂職責就是乙個類所完成的主要任務和功能，單一職責應就是講這個類只有乙個目的和任務！
也有很多人認為職責就是"變化的原因"或者是"變化的動機"，如果乙個類有多於乙個動機會要求改變這個類，那麼這個類就不是單一職責，就是多職責了！
這個和上面說職責就是類所需要完成的任務和功能，從本質上講不矛盾的，從最終效果來將，類的主要任務和功能也是類需要變化的根本原因，因此從這點來講，這2種看法是統一的！
李建忠在他的課裡講了2個例子來論證srp，乙個就是職員類，乙個是framework類庫里的檔案類！
職員類例子：
比如在職員類裡，將工程師、銷售人員、銷售經理這些情況都放在職員類裡考慮，其結果將會非常混亂，在這個假設下，職員類裡的每個方法都要if else判斷是哪種情況，從類結構上來說將會十分臃腫，並且上述三種的職員型別，不論哪一種發生需求變化，都會改變職員類！這個是大家所不願意看到的！
將那些容易導致變化的職責分離，而不必將每乙個職責都分離！
如果有乙個原因導致類中其中乙個職責發生變化，就應該將這個職責分離！
如果是導致類中所有職責都發生變化，則可以不分離！
srp原則是所有設計原則中最基本的原則，堅持這個原則能夠給我們帶來的好處如下：
1.**的可復用性
2.函式變短，可讀性增強
3.不存在重複**，結構精煉
4.函式功能單一，容易被替換
物件導向設計原則 單一職責原則
單一職責原則是最簡單的物件導向設計原則，它用於控制類的粒度大小。單一職責原則定義如下 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領 域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。單一職責原則告訴我們 乙個類...
物件導向設計原則之單一職責原則
單一職責原則是最簡單的物件導向設計原則，它用於控制類的粒度大小。單一職責原則定義如下 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。單一職責原則告訴我們 乙個類不...
物件導向設計原則之單一職責原則
單一職責原則是最簡單的物件導向設計原則，它用於控制類的粒度大小。單一職責原則定義如下 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。單一職責原則告訴我們 乙個類不...