敏捷軟體開發 單一職責原則

2021-05-02 22:16:43 字數 809 閱讀 7385

在說【單一職責原則】之前,先說一下什麼是內聚性。

內聚性:是乙個模組內的組成元素之間的功能相關性。在本文中,將這個概念延伸一下,把內聚性和引起乙個模組或者類改變的作用力聯絡起來。

現在,就介紹一下什麼是【單一職責原則】。

單一職責原則:就乙個類而言,應該僅有乙個引起它變化的原因。

為什麼要這樣做呢?因為每乙個職責都是變化的乙個軸線。當需求變化時,反映出來的就是類的職責的變化。如果乙個類承擔多個職責的話,那麼引起它變化的原因就會有多個。如果乙個類承擔多個職責,就等於將這些職責耦合在了一起。乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,但變化發生時,設計會遭受意想不到的破壞。

那看一下什麼是【職責】吧!職責在這裡定義為「變化的原因」。如果有不只乙個動機去改變乙個類,那麼這個類就不止乙個職責。

下面,還是用例子來說明問題。來看一下**:

上面這個介面定義了4個方法,其中有兩個職責:乙個是連線管理;乙個是通訊管理。那麼,這裡到底需不需要分離職責呢?就是將這個介面分為兩個介面。

對於這個問題,是否分離的關鍵在於應用程式的變化方式!如果這兩個職責的變化是不同步的,打個比方:關於通訊的職責經常方式變化,而關於連線的職責則是比較穩定的。這樣,就需要分離職責了。如果這兩個職責的變化經常是同時發生的,那麼就不需要分離職責了!

總之,就是變化的軸線僅當變化實際發生時才有具有真正的意義。也可以說在任何變化發生之前,任何原則的實施都是不明智的,因為我們無法猜測變化。

對於這個原則有乙個違反srp的特殊情況:持久化。因為持久化的職責不會經常變動,所以可以將持久化的一系列職責都放在乙個類中。其實這也就是所謂的「具體問題,具體分析」。

敏捷軟體開發 敏捷開發原則

編寫單元測試是一種驗證行為,更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件,會有乙個測試展示給你看。什麼是設計?不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分,但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動,即使是簡單的...

敏捷軟體開發第二部分(SRP 單一職責原則)

剛說的堅持,上週就抽了個打耳光,直接沒繼續啦,不過也是身體素質真心不行,上週因為上上週的週末通宵,導致上一周整個人一直渾渾噩噩的,每天晚上回來基本已經11點,洗澡整理就12點了,頭腦漲漲的也看不下書,就倒床就睡死過去了。不bb拉,簡單的記錄下這週看的內容。好吧,我也知道看的太少了,今天本來打算早上看...

軟體設計原則 單一職責原則

單一職責 responsibility pinciple,srp 是指不要存在多於乙個導致類變更的原因 乙個類如果負責兩個職責,當需求發生變更,修改其中乙個職責的邏輯時,可能會導致另乙個職責功能發生意想不到的問題.建立乙個 course 類,體育課送一套護具,其他課程不送 public class ...