六大設計原則-單一職責原則

1、開閉原則       
2、接口隔離原則
3、依賴倒置原則
4、迪米特原則            
5、里氏替換原則    
6、單一職責原則

 

單一職責原則

針對的問題

類T負責兩個不同職責：職責P1和職責P2。當業務發生改變需要修改職責P1，有可能會影響到職責P2的功能。

解決方案

遵循單一職責原則，分別創建兩個類：類T1和類T2。類T1負責職責P1的功能，類T2負責職責P2的功能。這樣當修改P1代碼的時候就不會影響到P2的功能了。

拆分後代碼量會增加，理解成本也會增加，什麼時候適合使用單一職責原則呢？

如果類型足夠簡單，方法夠少，是可以在類級別去違背單一職責，如果類型複雜，方法多，建議遵循單一職責原則。

不同級別中使用的單一職責原則：

方法級別：一個方法只負責一件事。

類級別：一個類只負責一件事。

類庫級別：一個類庫應該職責清晰。

項目級別：一個項目應該職責清晰，比如：客戶端、管理後臺、後臺服務、定時任務、分佈式引擎等不要放在一個項目中，應該拆分。

系統級別：爲通用功能拆分，比如IP定位、日誌、在線統計等等。拆分後不僅能保證系統的穩定性還能提高開發效率。