一個類的修改隻能有一個被修改的原因。
通俗地講,就是一個類隻能負責一個職責,修改一個類不能影響到别的功能,也就是說隻有一個導緻該類被修改的原因。我們寫代碼的都知道盡量要做到低耦合、高内聚的特性,單一職責原則正是保證了類與類之間的低耦合性。一個類如果承擔過多的職責,就會有很多原因來導緻這個類的被修改,就有很大可能性影響到别的功能。
單一職責原則,看起來是一個非常簡單的原則,但真正實踐起來也并非易事,因為職責的聯合在實際當中是經常遇到的事,也不能随便地去拆分類去适配單一職責模式,是以如何從這些聯合的職責中合理地把職責分隔出來更合适的遵守單一職責原則要好好考慮。
看看下面這這個接口是否符合單一職責原則呢?
public interface
UserInterface{
voidsaveUser(User user);
UsergetUser(long id);
voidupdateUserBalance(long id, BigDecimal balance);
BigDecimalgetUserBalance(long id);
}
這是一個使用者接口,提供四個方法:儲存使用者、擷取使用者、更新使用者餘額、擷取使用者餘額,很顯然使用者個人資訊與使用者的賬戶餘額是兩回事,這樣設計在一起耦合非常高,不利于擴充,也不符合單一職責原則,我們可以把它折分成兩個,一個為使用者資訊接口,一個賬戶接口,如下
AccountInterface這樣分開來,是不是就符合了單一職責原則,類的複雜性和耦合性也降低了,即使使用者接口或賬戶接口加減接口也不影響别的接口實作類。
是以,單一職責原則可以總結為以下優勢:
1、低耦合性,影響範圍小。
2、類複雜度降低,職責分明,提高了可讀性。
3、職責單一,利于維護。