單一職責原則(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這個類,不會影響其他類別。
那麼單一職責原則的意義何在呢?
降低類別的複雜性,實現什麼樣的職責都有清晰的定義
提高可讀性
#提高可維護性
降低變更所造成的風險,對系統擴充性和維護性很有幫助
但是、使用單一職責原則有一個問題,「職責」沒有一個明確的劃分標準,如果把職責劃分的太細的話會導致接口和實現類的數量劇增,反而提高了複雜度,降低了代碼的可維護性。所以使用這個職責的時候還要具體情況具體分析。建議就是介面一定要採用單一職責原則,實現類別的設計上盡可能做到單一職責原則,***是一個原因造成一個類別的變化。
以上是java設計模式的單一職責原則怎麼實現的詳細內容。更多資訊請關注PHP中文網其他相關文章!