java依賴混亂存在的問(wèn)題與解決方案
呈現(xiàn)的形態(tài)
- 1.缺少防腐層,業(yè)務(wù)與外部接口耦合;
- 2.業(yè)務(wù)代碼中出現(xiàn)具體實(shí)現(xiàn)類(lèi)。
存在的問(wèn)題與解決方案
缺少防腐層,會(huì)讓請(qǐng)求對(duì)象傳導(dǎo)到業(yè)務(wù)代碼中,造成了業(yè)務(wù)與外部接口的耦合,也就是業(yè)務(wù)依賴了一個(gè)外部通信協(xié)議。一般來(lái)說(shuō),業(yè)務(wù)的穩(wěn)定性要比外部接口高,這種反向的依賴就會(huì)讓業(yè)務(wù)一直無(wú)法穩(wěn)定下來(lái),繼而在日后帶來(lái)更多的問(wèn)題。解決方案自然就是引入一個(gè)防腐層,將業(yè)務(wù)和接口隔離開(kāi)來(lái)。
業(yè)務(wù)代碼中出現(xiàn)具體的實(shí)現(xiàn)類(lèi),實(shí)際上是違反了依賴倒置原則。因?yàn)檫`反了依賴倒置原則,業(yè)務(wù)代碼也就不可避免地受到具體實(shí)現(xiàn)的影響,也就造成了業(yè)務(wù)代碼的不穩(wěn)定。識(shí)別一段代碼是否屬于業(yè)務(wù),我們不妨問(wèn)一下,看把它換成其它的東西,是否影響業(yè)務(wù)。解決這種壞味道就是引入一個(gè)模型,將業(yè)務(wù)與具體的實(shí)現(xiàn)隔離開(kāi)來(lái)。
編程規(guī)則
依賴倒置原則,即高層模塊不應(yīng)依賴于底層模塊,二者應(yīng)依賴于抽象。抽象不應(yīng)該依賴細(xì)節(jié),細(xì)節(jié)應(yīng)該依賴于抽象。
記住一句話
代碼應(yīng)該向著穩(wěn)定性的方向依賴。
缺少防腐層
@PostMapping("/books") public NewBookResponse createBook(final NewBookRequest request) { boolean result = this.service.createBook(request); ... }
按照通常的架構(gòu)設(shè)計(jì)原則,service 層屬于我們的核心業(yè)務(wù),而 controller層屬于接口。二者相較而言,核心業(yè)務(wù)的重要程度更高一些,所以,它的穩(wěn)定程度也應(yīng)該更高一些。同樣的業(yè)務(wù),我們可以用 REST 的方式對(duì)外提供,也可以用 RPC 的方式對(duì)外提供。
NewBookRequest穿越了兩層,職責(zé)不清晰的同時(shí),也存在破壞核心業(yè)務(wù)層穩(wěn)定性的風(fēng)險(xiǎn)。為此,我們只要再引入一個(gè)模型就可以破解這個(gè)問(wèn)題。
class NewBookParameter { ... } class NewBookRequest { public NewBookParameters toNewBookRequest() { ... } } @PostMapping("/books") public NewBookResponse createBook(final NewBookRequest request) { boolean result = this.service.createBook(request.toNewBookParameter()); ... }
通過(guò)增加一個(gè)模型,我們就破解了依賴關(guān)系上的糾結(jié)。也許你會(huì)說(shuō),雖然它們成了兩個(gè)類(lèi),但是,它們兩個(gè)應(yīng)該長(zhǎng)得一模一樣吧。這算不算是一種重復(fù)呢?但我的問(wèn)題是,它們兩個(gè)為什么要一樣呢?有了兩層不同的參數(shù),我們就可以給不同層次上的模型以不同的約定了。
比如,對(duì)于 controller 層的請(qǐng)求對(duì)象,因?yàn)樗闹饕饔檬莻鬏敚?,一般?lái)說(shuō),我們約定請(qǐng)求對(duì)象的字段主要是基本類(lèi)型。而 service 的參數(shù)對(duì)象,因?yàn)樗呀?jīng)是核心業(yè)務(wù)的一部分,就需要全部轉(zhuǎn)化為業(yè)務(wù)對(duì)象。舉個(gè)例子,比如,同樣表示價(jià)格,在請(qǐng)求對(duì)象中,我們可以是一個(gè) double 類(lèi)型,而在業(yè)務(wù)參數(shù)對(duì)象中,它應(yīng)該是 Price 類(lèi)型。
業(yè)務(wù)代碼里的具體實(shí)現(xiàn)
@Task public void sendBook() { try { this.service.sendBook(); } catch (Throwable t) { this.feishuSender.send(new SendFailure(t))); throw t; } }
上面的不符合設(shè)計(jì)原則,它違反了依賴倒置原則。高層模塊不應(yīng)依賴于低層模塊,二者應(yīng)依賴于抽象。抽象不應(yīng)依賴于細(xì)節(jié),細(xì)節(jié)應(yīng)依賴于抽象。
上面這段代碼,在一段業(yè)務(wù)處理中出現(xiàn)了一個(gè)具體的實(shí)現(xiàn),也就是這里的 feishuSender。你需要知道,業(yè)務(wù)代碼中任何與業(yè)務(wù)無(wú)關(guān)的東西都是潛在的壞味道。
在這里,飛書(shū)肯定不是業(yè)務(wù)的一部分,它只是當(dāng)前選擇的一個(gè)具體實(shí)現(xiàn)。換言之,是否選擇飛書(shū),與團(tuán)隊(duì)當(dāng)前的狀態(tài)是相關(guān)的,如果哪一天團(tuán)隊(duì)切換即時(shí)通信軟件,這個(gè)實(shí)現(xiàn)就需要換掉。
識(shí)別一個(gè)東西是業(yè)務(wù)的一部分,還是一個(gè)可以替換的實(shí)現(xiàn),我們不妨問(wèn)問(wèn)自己,如果不用它,是否還有其它的選擇?就像這里,飛書(shū)是可以被其它即時(shí)通信軟件替換的。
另外,常見(jiàn)的中間件,比如,Kafka、Redis、MongoDB 等等,通常也都是一個(gè)具體的實(shí)現(xiàn),其它中間件都可以把它替換掉。所以,它們?cè)跇I(yè)務(wù)代碼里出現(xiàn),那一定就是一個(gè)壞味道了。
既然我們已經(jīng)知道了,這些具體的東西是一種壞味道,那該怎么解決呢?你可以引入一個(gè)模型,也就是這個(gè)具體實(shí)現(xiàn)所要扮演的角色,通過(guò)它,將業(yè)務(wù)和具體的實(shí)現(xiàn)隔離開(kāi)來(lái)。
interface FailureSender { void send(SendFailure failure); } class FeishuFailureSenderS implements FailureSender { ... }
這里我們通過(guò)引入一個(gè) FailureSender,業(yè)務(wù)層只依賴于這個(gè) FailureSender 的接口就好,而具體的飛書(shū)實(shí)現(xiàn)可以通過(guò)依賴注入的方式注入進(jìn)去。
依賴關(guān)系是軟件開(kāi)發(fā)中非常重要的一個(gè)東西,然而,很多程序員在寫(xiě)代碼的時(shí)候,由于開(kāi)發(fā)習(xí)慣的原因,常常會(huì)忽略掉依賴關(guān)系這件事本身。
現(xiàn)在已經(jīng)有一些工具,可以保證我們?cè)趯?xiě)代碼的時(shí)候,不會(huì)出現(xiàn)嚴(yán)重破壞依賴關(guān)系的情況,比如,像前面那種 service 層調(diào)用 resource 層的代碼。
在 Java 世界里,我們就可以用 ArchUnit 來(lái)保證這一切??疵志筒浑y發(fā)現(xiàn),它是把這種架構(gòu)層面的檢查做成了單元測(cè)試,下面就是這樣的一個(gè)單元測(cè)試:
@Test public void should_follow_arch_rule() { JavaClasses clazz = new ClassFileImporter().importPackages("..."); ArchRule rule = layeredArchitecture() .layer("Resource").definedBy("..resource..") .layer("Service").definedBy("..service..") .whereLayer("Resource").mayNotBeAccessedByAnyLayer() .whereLayer("Service").mayOnlyBeAccessedByLayers("Resource"); rule.check(clazz); }
在這里,我們定義了兩個(gè)層,分別是 Resource 層和 Service 層,而且我們要求 Resource 層的代碼不能被其它層訪問(wèn),而 Service 層的代碼只能由 Resource 層方法訪問(wèn)。這就是我們的架構(gòu)規(guī)則,一旦代碼里有違反這個(gè)架構(gòu)規(guī)則的代碼,這個(gè)測(cè)試就會(huì)失敗,問(wèn)題也就會(huì)暴露出來(lái)。
以上就是java依賴混亂存在的問(wèn)題與解決方案的詳細(xì)內(nèi)容,更多關(guān)于java依賴混亂的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Spring相關(guān)知識(shí)點(diǎn)的總結(jié)與梳理
今天小編就為大家分享一篇關(guān)于Spring相關(guān)知識(shí)點(diǎn)的總結(jié)與梳理,小編覺(jué)得內(nèi)容挺不錯(cuò)的,現(xiàn)在分享給大家,具有很好的參考價(jià)值,需要的朋友一起跟隨小編來(lái)看看吧2019-02-02spring schedule實(shí)現(xiàn)動(dòng)態(tài)配置執(zhí)行時(shí)間
這篇文章主要介紹了spring schedule實(shí)現(xiàn)動(dòng)態(tài)配置執(zhí)行時(shí)間,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-11-11Java?ArrayList遍歷foreach與iterator時(shí)remove的區(qū)別
這篇文章主要介紹了Java?ArrayList遍歷foreach與iterator時(shí)remove的區(qū)別,文章圍繞主題展開(kāi)詳細(xì)的內(nèi)容介紹,具有一定的參考價(jià)值,需要的朋友可以參考一下2022-07-07教你快速搭建sona服務(wù)及idea使用sona的方法
Sonar 是一個(gè)用于代碼質(zhì)量管理的開(kāi)放平臺(tái)。通過(guò)插件機(jī)制,Sonar 可以集成不同的測(cè)試工具,代碼分析工具,以及持續(xù)集成工具,本文給大家分享搭建sona服務(wù)及idea使用sona的方法,感興趣的朋友一起看看吧2021-06-06Java8中forEach語(yǔ)句循環(huán)一個(gè)List和Map
這篇文章主要給大家介紹了關(guān)于Java8中forEach語(yǔ)句循環(huán)一個(gè)List和Map的相關(guān)資料,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2021-02-02SpringBoot使用TraceId進(jìn)行日志鏈路追蹤的實(shí)現(xiàn)步驟
有時(shí)候一個(gè)業(yè)務(wù)調(diào)用鏈場(chǎng)景,很長(zhǎng),調(diào)了各種各樣的方法,看日志的時(shí)候,各個(gè)接口的日志穿插,確實(shí)讓人頭大,所以為了解決這個(gè)問(wèn)題,本文給大家介紹了SpringBoot使用TraceId進(jìn)行日志鏈路追蹤的實(shí)現(xiàn)步驟,需要的朋友可以參考下2024-11-11