SRP是Bob大叔提出的一個重要設計原則。SRP強調每一個類或模塊只有一個變化的原因。但這個唯一的變化原因不太容易理解，不少人以為單一職責就是指的每個類都盡量設計成只有一個方法，只做一件事。真正理解SRP關鍵在于理解職責的層次性。關于SRP原則一個很好的例子是汽車：汽車作為一個整體是單一職責的，它的職責就是滿足駕駛需要；而汽車又是由發動機、底盤、輪胎等等部件構成的，每一個部件的職責也是單一的，發動機的職責就是提供動力，輪胎的職責就是轉動；進一步發動機還可以細分為更低層次的零件，每個零件其實也是單一職責的。所以，職責是有層次的，任何系統或對象都負責所屬層次的職責。系統的職責是作為一個單一且完備的整體存在的，而不是子系統層次職責的簡單累加。這就是 職責層次性 原理。

職責的層次性是它的一種性質，但并不說明職責的本質。那么職責的本質是什么呢？我認為，職責是對需求的滿足。職責層次性來源于 需求層次性 。需求是有層次的，用戶也是有層次的。汽車需求=>發動機需求=>螺絲需求=>鋼材需求就是需求的層次性；車的用戶=>汽車制造商=>發動機生產商=>螺絲生產商=>…就是用戶的層次性。所以，SRP中提到的“變化原因”即是需求變化，“唯一的變化原因”暗示了需求的層次性，如果需求層次與職責層次相對應，那么每一個系統在所處的層次上的確只會有一個變化的原因。

職責層次性的背后是需求層次性，那么需求層次性又是哪里來的呢？需求層次性來源于設計！對于汽車的用戶來講，他的需求是汽車整體這個層次的，至于汽車部件的設計則不屬于他所關心的范疇。而發動機、輪胎等需求來源于汽車設計者對汽車結構的設計，這就是說為滿足高層系統需求所進行的設計產生了子系統的需求，而子系統的需求又進一步產生了子子系統的設計，這就是 設計層次性 。需求=>設計=>需求=>設計…，需求和設計就像雞生蛋，蛋生雞一樣層層地細化，我們稱這種設計方式為 職責驅動設計 。

需要指出的是職責驅動設計所產生的層次性僅僅是若干系統層次性的一種。對系統劃分層次的方法有很多很多種，傳統的3層架構也是一種層次性，那么職責驅動設計產生的層次性有什么不同呢？我們舉一個例子來說明，比如：一家公司可以先按項目組來劃分，項目組再劃分成開發和測試；同樣，一家公司也可以先劃分成開發部門和測試部門，再各部門抽調員工來組成項目組。系統層次劃分方法的多樣性本質上是由于系統的多元性決定的，一個人從項目看屬于A項目，按工種來看屬于測試，按學歷來看屬于研究生，按性別來看屬于男性等等。而職責驅動設計的特點是把功能作為第一級的分層標準，每一層都是一種功能內聚！即各子系統是為實現高層職責而進行功能協作聚合到一起的，或者說各子系統是一種功能耦合關系。前面例子中，先按項目組劃分的方式是一種 功能內聚 方式，而先按開發和測試部門劃分則不是。良好的系統設計應具有高內聚、低耦合的特點，功能耦合被認為是一種最佳的耦合方式。比如：Socket類具有Connect、Disconnect、Send、Receive等功能，它們是作為完整地實現Socket通信功能而耦合在一起的，是一種值得提倡的高內聚方式。

職責層次性又決定了 測試層次性 。一輛汽車的測試需要從螺絲測試到輪胎測試到整車測試，這才能讓人放心每一個環節都不出問題。職責是有層次的，類是有層次的，關于類的單元測試也是有層次的。所以，單元測試并不像不少人所誤解的那樣只測“螺絲”級別。雖然單元測試可能達不到“整車”測試的級別，但起碼達到“輪胎”測試的級別是可能的。除了單元測試本身的層次性，向外擴展，集成測試、驗收測試形成了更大的測試反饋鏈，每一層測試都會形成對該層系統的反饋，這就是 反饋層次性 。

上面從單一職責原則入手，介紹了職責驅動設計所產生的各種層次性，包括：需求層次性，職責層次性，設計層次性，測試層次性，反饋層次性。這些不同的層次性具有內在的一致性，因為它們都源于系統層次性。每一種層次性是系統這個多維對象從不同維度所建立的視圖，從需求的角度看是需求層次性，從測試角度看是測試層次性。所以，理解系統的多維度與多層次是分析理解問題的根本。

上面是我對系統和設計的一點粗淺的認識，文中錯誤和不足之處歡迎批評指正！

系統的層次性與單一職責原則