單一職責原則

乙個類，只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線，如果乙個類有乙個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。例如：要實現邏輯和介面的分離。

對於user類，裡面可以有修改資訊方法，如果我們把這些方法全部寫在乙個方法之中，那麼它的靈活性就大大的降低，例子如下 :

首先我們先建乙個user介面inte***ceuser

public inte***ce inte***ceuser

然後我們建乙個user類實現這個介面，裡面的方法包括修改資訊，顯示資訊

public class user implements inte***ceuser 
@override
public void changeuser(string type, string changeoptions) else if(type.equals("修改**"))
} public void display()
}

當我們需要修改使用者資訊的時候我們可以呼叫user的changeuser方法給出引數修改，達到修改的目的

public class testdemo 
}

這時我們就可以達到修改使用者的資訊，但這時候我們想到如果在user類中修改姓名該怎麼辦，我們就要修改changeuser方法加入if....else分支，這種使**很不靈活，針對單一職責原則，我們希望每乙個方法只幹一件事情，我們可以把各個屬性分開進行處理。

乙個user介面inte***ceuser

public inte***ce inte***ceuser

乙個user類實現這個介面

public class user implements inte***ceuser 
@override
public void setuserid(string userid) 
@override
public void setuserphone(string userphone) 
@override
public void setuseraddr(string useraddr) 
@override
public string getusername() 
@override
public string getuserid() 
public string getuserphone() 
@override
public string getuseraddr() 
}

當我們需要修改某個值得時候直接呼叫相應的方法就可以

public class testdemo 
}

本文所舉的這個例子，它太簡單，它只有乙個方法，所以，無論是在**級別上違反單一職責原則，還是在方法級別上違反，都不會造成太大的影響。實際應用中的類都要複雜的多，一旦發生職責擴散而需要修改類時，除非這個類本身非常簡單，否則還是遵循單一職責原則的好。

遵循單一職責原的優點有：

可以降低類的複雜度，乙個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；

提高類的可讀性，提高系統的可維護性；

變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改乙個功能時，可以顯著降低對其他功能的影響。

需要說明的一點是單一職責原則不只是物件導向程式設計思想所特有的，只要是模組化的程式設計，都適用單一職責原則。

對於介面，我們在設計的時候一定要做到單一，但是對於實現類就需要多方面考慮了。生搬硬套單一職責原則會引起類的劇增，給維護帶來非常多的麻煩，而且過分的細分類的職責也會人為地製造系統的複雜性，本來乙個類可以實現的行為硬要拆成兩個類，然後使用聚合或組合的方式再耦合在一起，這個是人為製造了系統的複雜性，所以原則是死的，人是活的，這句話是非常好的。

單一職責原則

單一職責原則

單一職責原則

單一職責原則

相關推薦