2019獨角獸企業重金招聘Python工程師標準>>>

單一職責原則（Single Responsibility Principle），簡稱SRP。

定義：

There should never be more than one reason for a class to change.

應該有且僅有一個原因引起類的變更。

?

有時候，開發人員設計接口的時候會有些問題，比如用戶的屬性和用戶的行為被放在一個接口中聲明。這就造成了業務對象和業務邏輯被放在了一起，這樣就造成了這個接口有兩種職責，接口職責不明確，按照SRP的定義就違背了接口的單一職責原則了。

下面是個例子：

package com.loulijun.chapter1;

?

public interface Itutu {

? ? //身高

? ? void setShengao(double height);

? ? double getShengao();

? ? //體重

? ? void setTizhong(double weight);

? ? double getTizhong();

? ? //吃飯

? ? boolean chiFan(boolean hungry);

? ? //上網

? ? boolean shangWang(boolean silly);

}

　　上面的例子就存在這個問題，身高、體重屬于業務對象，與之相應的方法主要負責用戶的屬性。而吃飯、上網是相應的業務邏輯，主要負責用戶的行為。但是這就會給人一種不知道這個接口到底是做什么的感覺，職責不清晰，后期維護的時候也會造成各種各樣的問題。

解決辦法：單一職責原則，將這個接口分解成兩個職責不同的接口即可

ItutuBO.java：負責tutu（涂涂，假如是個人名）的屬性

package com.loulijun.chapter1;

?

/**

?* BO：Bussiness Object，業務對象

?* 負責用戶的屬性

?* @author Administrator

?*

?*/

public interface ItutuBO {

? ? //身高

? ? void setShengao(double height);

? ? double getShengao();

? ? //體重

? ? void setTizhong(double weight);

? ? double getTizhong();

}

ItutuBL.java：負責涂涂的行為

package com.loulijun.chapter1;

/**

?* BL:Business Logic,業務邏輯

?* 負責用戶的行為

?* @author Administrator

?*

?*/

public interface ItutuBL {

? ? //吃飯

? ? boolean chiFan(boolean hungry);

? ? //上網

? ? boolean shangWang(boolean silly);

}

這樣就實現了接口的單一職責。那么實現接口的時候，就需要有兩個不同的類

TutuBO.java

package com.loulijun.chapter1;

?

public class TutuBO implements ItutuBO {

? ? private double height;

? ? private double weight;

? ? @Override

? ? public double getShengao() { ? ? ? ?

? ? ? ? return height;

? ? }

?

? ? @Override

? ? public double getTizhong() {

? ? ? ? return weight;

? ? }

?

? ? @Override

? ? public void setShengao(double height) {

? ? ? ? this.height = height;

? ? }

?

? ? @Override

? ? public void setTizhong(double weight) {

? ? ? ? this.weight = weight;

? ? }

?

}

TutuBL.java

package com.loulijun.chapter1;

?

public class TutuBL implements ItutuBL {

?

? ? @Override

? ? public boolean chiFan(boolean hungry) {

? ? ? ? if(hungry)

? ? ? ? {

? ? ? ? ? ? System.out.println("去吃火鍋...");

? ? ? ? ? ? return true;

? ? ? ? }

? ? ? ? return false;

? ? }

?

? ? @Override

? ? public boolean shangWang(boolean silly) {

? ? ? ? if(silly)

? ? ? ? {

? ? ? ? ? ? System.out.println("好無聊啊，上會網...");

? ? ? ? ? ? return true;

? ? ? ? }

? ? ? ? return false;

? ? }

?

}

這樣就清晰了，當需要修改用戶屬性的時候只需要對ItutuBO這個接口來修改，只會影響到TutuBO這個類，不會影響其他類。

那么單一職責原則的意義何在呢？

1、降低類的復雜性，實現什么樣的職責都有清晰的定義

2、提高可讀性

3、提高可維護性

4、降低變更引起的風險，對系統擴展性和維護性很有幫助

?

但是、使用單一職責原則有一個問題，“職責”沒有一個明確的劃分標準，如果把職責劃分的太細的話會導致接口和實現類的數量劇增，反而提高了復雜度，降低了代碼的可維護性。所以使用這個職責的時候還要具體情況具體分析。建議就是接口一定要采用單一職責原則，實現類的設計上盡可能做到單一職責原則，最好是一個原因引起一個類的變化。

轉載于:https://my.oschina.net/u/1409620/blog/293879

總結

以上是生活随笔為你收集整理的设计模式--6大原则--单一职责原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。