建站
咨詢
售后
建站咨詢
新聞中心
單一職責(zé)原則（Single Responsibility Principle），簡(jiǎn)稱SRP。
定義：
There should never be more than one reason for a class to change.
應(yīng)該有且僅有一個(gè)原因引起類的變更。
有時(shí)候，開(kāi)發(fā)人員設(shè)計(jì)接口的時(shí)候會(huì)有些問(wèn)題，比如用戶的屬性和用戶的行為被放在一個(gè)接口中聲明。這就造成了業(yè)務(wù)對(duì)象和業(yè)務(wù)邏輯被放在了一起，這樣就造成了這個(gè)接口有兩種職責(zé)，接口職責(zé)不明確，按照SRP的定義就違背了接口的單一職責(zé)原則了。
下面是個(gè)例子：
- package com.loulijun.chapter1;
- public interface Itutu {
- //身高
- void setShengao(double height);
- double getShengao();
- //體重
- void setTizhong(double weight);
- double getTizhong();
- //吃飯
- boolean chiFan(boolean hungry);
- //上網(wǎng)
- boolean shangWang(boolean silly);
- }
上面的例子就存在這個(gè)問(wèn)題，身高、體重屬于業(yè)務(wù)對(duì)象，與之相應(yīng)的方法主要負(fù)責(zé)用戶的屬性。而吃飯、上網(wǎng)是相應(yīng)的業(yè)務(wù)邏輯，主要負(fù)責(zé)用戶的行為。但是這就會(huì)給人一種不知道這個(gè)接口到底是做什么的感覺(jué)，職責(zé)不清晰，后期維護(hù)的時(shí)候也會(huì)造成各種各樣的問(wèn)題。
解決辦法：?jiǎn)我宦氊?zé)原則，將這個(gè)接口分解成兩個(gè)職責(zé)不同的接口即可
ItutuBO.java：負(fù)責(zé)tutu（涂涂，假如是個(gè)人名）的屬性
- package com.loulijun.chapter1;
- /**
- * BO：Bussiness Object，業(yè)務(wù)對(duì)象
- * 負(fù)責(zé)用戶的屬性
- * @author Administrator
- *
- */
- public interface ItutuBO {
- //身高
- void setShengao(double height);
- double getShengao();
- //體重
- void setTizhong(double weight);
- double getTizhong();
- }
ItutuBL.java：負(fù)責(zé)涂涂的行為
- package com.loulijun.chapter1;
- /**
- * BL:Business Logic,業(yè)務(wù)邏輯
- * 負(fù)責(zé)用戶的行為
- * @author Administrator
- *
- */
- public interface ItutuBL {
- //吃飯
- boolean chiFan(boolean hungry);
- //上網(wǎng)
- boolean shangWang(boolean silly);
- }
這樣就實(shí)現(xiàn)了接口的單一職責(zé)。那么實(shí)現(xiàn)接口的時(shí)候，就需要有兩個(gè)不同的類
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("好無(wú)聊啊，上會(huì)網(wǎng)...");
- return true;
- }
- return false;
- }
- }
這樣就清晰了，當(dāng)需要修改用戶屬性的時(shí)候只需要對(duì)ItutuBO這個(gè)接口來(lái)修改，只會(huì)影響到TutuBO這個(gè)類，不會(huì)影響其他類。
那么單一職責(zé)原則的意義何在呢？
- 降低類的復(fù)雜性，實(shí)現(xiàn)什么樣的職責(zé)都有清晰的定義
- 提高可讀性
- 提高可維護(hù)性
- 降低變更引起的風(fēng)險(xiǎn)，對(duì)系統(tǒng)擴(kuò)展性和維護(hù)性很有幫助
但是、使用單一職責(zé)原則有一個(gè)問(wèn)題，“職責(zé)”沒(méi)有一個(gè)明確的劃分標(biāo)準(zhǔn)，如果把職責(zé)劃分的太細(xì)的話會(huì)導(dǎo)致接口和實(shí)現(xiàn)類的數(shù)量劇增，反而提高了復(fù)雜度，降低了代碼的可維護(hù)性。所以使用這個(gè)職責(zé)的時(shí)候還要具體情況具體分析。建議就是接口一定要采用單一職責(zé)原則，實(shí)現(xiàn)類的設(shè)計(jì)上盡可能做到單一職責(zé)原則，***是一個(gè)原因引起一個(gè)類的變化。
名稱欄目：設(shè)計(jì)模式6大原則：?jiǎn)我宦氊?zé)原則
網(wǎng)頁(yè)地址：http://www.dlmjj.cn/article/ccspecg.html
