設計原則之單一職責原則

無論是什麼設計原則，全部都是圍繞「專案的生命週期」和「高內聚，低耦合」這兩個關鍵字。

單一職責原則（srp：single responsibility principle）又稱單一功能原則，它規定了乙個類應該只有乙個發生變化的原因，即乙個類只負責一項職責。

字面上很好理解，但是如果做起來卻很難做到，因為很難劃分職責。

現需求設計乙個使用者類，要求使用者類具有操作手機的能力。

public class user 

}

public class user 

public void call(phone phone) 
}

public class user 

public void call(phone phone) 
public void play(phone phone) 
}

說到這，我們來分析一下有什麼不妥？雖然前期使用者類增加功能看似很簡單，但是功能越多，意味著依賴的模組也就越多。當其中某一模組出現問題，整個類也會隨之異常。這就是有多個原因導致類變更的情況。

怎麼解決？好辦，劃分職責：

public class answeruser 

}public class calluser 
}public class playuser 
}

可能上面的例子比較簡單，不足體現出單一職責原則的好處。但實際上，由於乙個類功能越多，就越多使用者類去使用這個功能強大的類（因為啥都能幹呀），一旦這個功能強大的類出現異常，可能就得修改這麼多個使用者類，導致 「牽一髮而動全身」 。而且由於類功能強大，依賴的模組越多，也就越容易出問題。優點

難點 劃分粒度太大，達不到單一職責原則。劃分粒度太小，會導致類**，也會產生沒必要的花銷。

至於怎麼劃分職責，還需要各位結合實際專案需求以及利用自己的開發經驗，去做出最合理的劃分。

設計原則之單一職責原則

什麼是單一職責原則 定義 有且僅有乙個使介面或類產生變化的原因。也就是說我們使類或介面變化，只能有乙個理由。但是在實際開發的過程中，我們很容易做到介面單一職責，很難做到類單一職責。例如 我們以查詢資料，處理資料，返回資料為例。如果我們這樣設計乙個介面 public inte ce iuserbo p...

設計原則 單一職責原則

定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...

設計原則 單一職責原則

1 原則的定義 2 原則設計的初衷 3 能解決哪些問題 4 有哪些場景可以使用 單一職責原則，英文名single responsibility principle,縮寫為srp。乙個類或者模組只負責完成乙個職責 或者功能 也就是說，不要設計大而全的類，要設計粒度小，功能單一的類。換個角度來講就是，乙...