在說【單一職責原則】之前，先說一下什麼是內聚性。
內聚性：是乙個模組內的組成元素之間的功能相關性。在本文中，將這個概念延伸一下，把內聚性和引起乙個模組或者類改變的作用力聯絡起來。
現在，就介紹一下什麼是【單一職責原則】。
單一職責原則：就乙個類而言，應該僅有乙個引起它變化的原因。
為什麼要這樣做呢？因為每乙個職責都是變化的乙個軸線。當需求變化時，反映出來的就是類的職責的變化。如果乙個類承擔多個職責的話，那麼引起它變化的原因就會有多個。如果乙個類承擔多個職責，就等於將這些職責耦合在了一起。乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，但變化發生時，設計會遭受意想不到的破壞。
那看一下什麼是【職責】吧！職責在這裡定義為「變化的原因」。如果有不只乙個動機去改變乙個類，那麼這個類就不止乙個職責。
下面，還是用例子來說明問題。來看一下**：
上面這個介面定義了4個方法，其中有兩個職責：乙個是連線管理；乙個是通訊管理。那麼，這裡到底需不需要分離職責呢？就是將這個介面分為兩個介面。
對於這個問題，是否分離的關鍵在於應用程式的變化方式！如果這兩個職責的變化是不同步的，打個比方：關於通訊的職責經常方式變化，而關於連線的職責則是比較穩定的。這樣，就需要分離職責了。如果這兩個職責的變化經常是同時發生的，那麼就不需要分離職責了！
總之，就是變化的軸線僅當變化實際發生時才有具有真正的意義。也可以說在任何變化發生之前，任何原則的實施都是不明智的，因為我們無法猜測變化。
對於這個原則有乙個違反srp的特殊情況：持久化。因為持久化的職責不會經常變動，所以可以將持久化的一系列職責都放在乙個類中。其實這也就是所謂的「具體問題，具體分析」。
敏捷軟體開發 敏捷開發原則
編寫單元測試是一種驗證行為，更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，會有乙個測試展示給你看。什麼是設計？不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分，但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動，即使是簡單的...
敏捷軟體開發第二部分（SRP 單一職責原則）
剛說的堅持，上週就抽了個打耳光，直接沒繼續啦，不過也是身體素質真心不行，上週因為上上週的週末通宵，導致上一周整個人一直渾渾噩噩的，每天晚上回來基本已經11點，洗澡整理就12點了，頭腦漲漲的也看不下書，就倒床就睡死過去了。不bb拉，簡單的記錄下這週看的內容。好吧，我也知道看的太少了，今天本來打算早上看...
軟體設計原則 單一職責原則
單一職責 responsibility pinciple,srp 是指不要存在多於乙個導致類變更的原因 乙個類如果負責兩個職責,當需求發生變更,修改其中乙個職責的邏輯時,可能會導致另乙個職責功能發生意想不到的問題.建立乙個 course 類,體育課送一套護具,其他課程不送 public class ...