設計模式2.1:單一職責原則

  經過之前的學習，我們知道了面向對象程式設計，以及面向對象的四大特性，在這個基礎之上，我們來繼續學習設計原則，其中包括，經典的SOLID（五大原則），以及KISS、YAGNI、DRY、LOD等。我們先來學習SOLID原則中的SRP（單一指責原則）。

1.如何了解單一職責原則(SRP) ?

  一個類隻負責完成一個職責或者功能。不要設計大而全的類，要設計粒度小、功能單一的

類。單一職責原則是為了實作代碼高内聚、低耦合，提高代碼的複用性、可讀性、可維護

性。

2.如何判斷類的職責是否足夠單一?

  不同的應用場景、不同階段的需求背景、不同的業務層面，對同一個類的職責是否單一，可能會有不同的判定結果。實際上，一些側面的判斷名額更具有指導意義和可執行性，比如，出現下面這些情況就有可能說明這類的設計不滿足單一職責原則:

●類中的代碼行數、函數或者屬性過多;

●類依賴的其他類過多，或者依賴類的其他類過多;

●私有方法過多;

●比較難給類起一個合适的名字;

●類中大量的方法都是集中操作類中的某幾個屬性。

3.類的職責是否設計得越單一越好?

  單一職責原則通過避免設計大而全的類，避免将不相關的功能耦合在-起，來提高類的内聚性。同時，類職責單一，類依賴的和被依賴的其他類也會變少，減少了代碼的耦合性，以此來實作代碼的高内聚、低耦合。但是，如果拆分得過細，實際.上會适得其反，反倒會降低内聚性，也會影響代碼的可維護性。