簡單講解Java設(shè)計模式編程中的單一職責(zé)原則
單一職責(zé)原則:一個類,只有一個引起它變化的原因。
為什么需要單一職責(zé)原則?
如果一個類有多個原因要去修改它,那么修改一個功能時,可能會讓其他功能產(chǎn)生Bug,所以一個類最好只有一個職責(zé)。但實(shí)際應(yīng)用中還是比較難實(shí)現(xiàn)的,我們只能是盡量符合這個原則。
有時候,開發(fā)人員設(shè)計接口的時候會有些問題,比如用戶的屬性和用戶的行為被放在一個接口中聲明。這就造成了業(yè)務(wù)對象和業(yè)務(wù)邏輯被放在了一起,這樣就造成了這個接口有兩種職責(zé),接口職責(zé)不明確,按照SRP的定義就違背了接口的單一職責(zé)原則了。
下面是個例子:
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); }
上面的例子就存在這個問題,身高、體重屬于業(yè)務(wù)對象,與之相應(yīng)的方法主要負(fù)責(zé)用戶的屬性。而吃飯、上網(wǎng)是相應(yīng)的業(yè)務(wù)邏輯,主要負(fù)責(zé)用戶的行為。但是這就會給人一種不知道這個接口到底是做什么的感覺,職責(zé)不清晰,后期維護(hù)的時候也會造成各種各樣的問題。
解決辦法:單一職責(zé)原則,將這個接口分解成兩個職責(zé)不同的接口即可
ItutuBO.java:負(fù)責(zé)tutu(涂涂,假如是個人名)的屬性
package com.loulijun.chapter1; /** * BO:Bussiness Object,業(yè)務(wù)對象 * 負(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)接口的時候,就需要有兩個不同的類
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ǎng)..."); return true; } return false; } }
這樣就清晰了,當(dāng)需要修改用戶屬性的時候只需要對ItutuBO這個接口來修改,只會影響到TutuBO這個類,不會影響其他類。
總結(jié):
1. 實(shí)際情況是,很多時候我們無法提前預(yù)見“引起變化的原因”,所以我們只能憑經(jīng)驗構(gòu)造我們的接口,盡量做到一個接口只有一個職責(zé)。這里說的是接口,類可能會有繼承和實(shí)現(xiàn)多個接口,更加難以實(shí)現(xiàn)單一職責(zé)。
2. 當(dāng)以前寫的類已經(jīng)有多個引起變化的原因時,我們最好做代碼重構(gòu)。
但是、使用單一職責(zé)原則有一個問題,“職責(zé)”沒有一個明確的劃分標(biāo)準(zhǔn),如果把職責(zé)劃分的太細(xì)的話會導(dǎo)致接口和實(shí)現(xiàn)類的數(shù)量劇增,反而提高了復(fù)雜度,降低了代碼的可維護(hù)性。所以使用這個職責(zé)的時候還要具體情況具體分析。建議就是接口一定要采用單一職責(zé)原則,實(shí)現(xiàn)類的設(shè)計上盡可能做到單一職責(zé)原則,最好是一個原因引起一個類的變化。
相關(guān)文章
springcloud中Ribbon和RestTemplate實(shí)現(xiàn)服務(wù)調(diào)用與負(fù)載均衡
這篇文章主要介紹了Ribbon和RestTemplate實(shí)現(xiàn)服務(wù)調(diào)用與負(fù)載均衡,想了解負(fù)載均衡的同學(xué)可以參考下2021-04-04SpringBoot連接MySql數(shù)據(jù)庫的原理及代碼示例
SpringBoot是一款流行的Java開發(fā)框架,它可以輕松地連接各種類型的數(shù)據(jù)庫,包括關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫,本文將介紹SpringBoot是如何連接數(shù)據(jù)庫的,包括其原理和代碼示例,需要的朋友可以參考下2023-07-07springMVC幾種頁面跳轉(zhuǎn)方式小結(jié)
本篇文章主要介紹了springMVC 幾種頁面跳轉(zhuǎn)方式,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2017-02-02application.yml的格式寫法和pom.xml讀取配置插件方式
這篇文章主要介紹了application.yml的格式寫法和pom.xml讀取配置插件方式,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2023-07-07從零搭建腳手架之集成Spring?Retry實(shí)現(xiàn)失敗重試和熔斷器模式(實(shí)戰(zhàn)教程)
在我們的大多數(shù)項目中,會有一些場景需要重試操作,而不是立即失敗,讓系統(tǒng)更加健壯且不易發(fā)生故障,這篇文章主要介紹了從零搭建開發(fā)腳手架之集成Spring?Retry實(shí)現(xiàn)失敗重試和熔斷器模式,需要的朋友可以參考下2022-07-07聊聊@RequestMapping和@GetMapping @PostMapping的區(qū)別
這篇文章主要介紹了@RequestMapping和@GetMapping及@PostMapping的區(qū)別,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2021-08-08SpringBoot深入探究@Conditional條件裝配的使用
這篇文章主要為大家介紹了SpringBoot底層注解@Conditional的使用分析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-06-06