我們開發(fā)人員喜歡抽象。 沒有它，我們將無法構(gòu)建應(yīng)用程序。 我們的編程學(xué)科甚至要求我們對(duì)抽象進(jìn)行編碼，并避免將我們的代碼耦合到詳細(xì)的實(shí)現(xiàn)。

但是，什么是適合您的應(yīng)用程序的正確抽象呢？

可悲的是，抽象的選擇確實(shí)來自我們對(duì)框架的選擇。 框架基本上是我們?yōu)榻鉀Q問題而擴(kuò)展的抽象解決方案。

不幸的是，諸如Spring Boot之類的框架對(duì)使用的線程模型，需要擴(kuò)展的接口，可能的適用數(shù)據(jù)存儲(chǔ)庫(kù)以及關(guān)于問題空間的各種其他假設(shè)都持謹(jǐn)慎態(tài)度。 在編寫第一行代碼之前，這有很多限制。

我們真正想做的是首先探索問題空間。 這就是測(cè)試驅(qū)動(dòng)設(shè)計(jì)的全部?jī)?nèi)容。 我們編寫測(cè)試來定義什么是成功的代碼。 然后，我們實(shí)現(xiàn)代碼以通過那些測(cè)試。 在編寫測(cè)試以掩蓋需求的過程中，我們隨后為應(yīng)用程序編制了工作代碼。 隨著時(shí)間的流逝，我們可以獲得足夠的工作代碼以作為應(yīng)用程序發(fā)布。

所以這導(dǎo)致我問，我們什么時(shí)候測(cè)試框架的選擇？

固執(zhí)己見的框架在開發(fā)過程中過早強(qiáng)制抽象

好吧，我想我們會(huì)請(qǐng)經(jīng)驗(yàn)豐富的資深人士來做出此選擇。 因此，此選擇必須正確。 不會(huì)因?yàn)橐韵略?#xff1a;

• 我（或我們的公司）只知道此框架，因此我們正在使用它
• 新閃亮，帶有很多流行語，我們必須使用它
• 我的簡(jiǎn)歷有點(diǎn)舊，讓我們嘗試一些新的東西
• 這個(gè)便宜一點(diǎn)
• 建筑相信它在錫上說了什么

無論出于何種原因，測(cè)試框架選擇的唯一方法是使用它來構(gòu)建應(yīng)用程序。 而對(duì)于那些喜歡固執(zhí)己見的框架（例如Spring Boot）的人，請(qǐng)告訴我您首先編寫最冒險(xiǎn)的方面。 這樣，您可以快速發(fā)現(xiàn)框架的意見是否與您的問題相符。

令人遺憾的是，即使您使用最危險(xiǎn)的方面進(jìn)行測(cè)試，發(fā)現(xiàn)框架決策是錯(cuò)誤的也會(huì)導(dǎo)致大量的代碼浪費(fèi)。 可以說，這浪費(fèi)了企業(yè)很多錢，并可能導(dǎo)致項(xiàng)目失敗。

例如，假設(shè)我們選擇“ Spring Reactive”。 是的，我們可以對(duì)各種微服務(wù)進(jìn)行并發(fā)異步調(diào)用。 我們還可以使用NoSQL數(shù)據(jù)存儲(chǔ)中的最新數(shù)據(jù)。 這都是一個(gè)偉大的決定。 但是，隨著時(shí)間的流逝，我們意識(shí)到我們擁有少量數(shù)據(jù)，其中數(shù)據(jù)的完整性非常重要。 我們發(fā)現(xiàn)我們想使用關(guān)系數(shù)據(jù)庫(kù)來解決此問題，然后將JPA合并到該數(shù)據(jù)庫(kù)中以便更輕松地進(jìn)行交互。 但是，我們選擇Spring Reactive不允許這樣做，因?yàn)樗笏蠭 / O都是異步的（JPA是同步數(shù)據(jù)庫(kù)調(diào)用）。 好的，是的，我們可以使用Scheduler，但是由于缺少事務(wù)，我似乎一直在不斷地工作。 數(shù)據(jù)一致性問題開始加劇，我們錯(cuò)過了最后期限。 現(xiàn)在，我可以扔掉所有的Reactive代碼，還是繼續(xù)努力以希望它們都可以在一起。 我肯定需要調(diào)換職位，然后才能開始支持我們。 在下一份工作中，我學(xué)習(xí)了使用Spring Servlet解決這類問題。

這種情況的另一面也很容易發(fā)生。 我們開始是想讓Spring Servlet與數(shù)據(jù)庫(kù)進(jìn)行JPA交互。 但是，隨著時(shí)間的流逝，我們意識(shí)到數(shù)據(jù)庫(kù)交互主要是只讀的。 我們真正想要的是Spring Reactive的異步I / O，以同時(shí)從多個(gè)微服務(wù)和數(shù)據(jù)存儲(chǔ)中收集數(shù)據(jù)。 不幸的是，由于我們選擇了Spring Servlet，因此數(shù)據(jù)收集太慢了。 我們的工作是使用異步Servlet和生成線程來發(fā)出并發(fā)請(qǐng)求。 最初可以正常工作，但隨著時(shí)間的推移，負(fù)載會(huì)增加。 這大大增加了線程數(shù)，導(dǎo)致線程調(diào)度不足，導(dǎo)致超時(shí)。 如果不對(duì)應(yīng)用程序進(jìn)行大量重寫，我真的無法解決此問題。 在下一份工作中，我學(xué)會(huì)了使用Spring Reactive解決此類問題。

因此，可以不必去扔掉所有代碼就能測(cè)試框架嗎？

反轉(zhuǎn)框架控制

依賴注入在反轉(zhuǎn)控制方面走了很長(zhǎng)一段路。 當(dāng)我編寫Servlet處理方法時(shí)，不再需要傳入所有依賴對(duì)象。 我將通過@Inject定義依賴項(xiàng)，以使框架使它們可用。 隨后，該框架不再規(guī)定我的實(shí)現(xiàn)可以依賴哪些對(duì)象。

但是，框架不僅僅是對(duì)象，還有很多其他功能。 框架將施加某種線程模型，并要求我擴(kuò)展某些方法。 盡管依賴注入提供了對(duì)對(duì)象的引用，但是框架仍然必須調(diào)用對(duì)象上的方法以執(zhí)行任何有用的操作。 例如，Spring一直在使方法變得靈活，但仍然通過方法所需的返回類型將您耦合到Reactive或Servlet編碼。

由于我需要Spring框架來進(jìn)行測(cè)試的依賴注入，因此在編寫第一行代碼之前，我就已經(jīng)耦合到特定的Spring Servlet / Reactive抽象。 如果我弄錯(cuò)了，更改的前期選擇可能會(huì)非常昂貴！

我真正想做的是：

為我的實(shí)現(xiàn)編寫測(cè)試（ 當(dāng)然，因?yàn)槲覀兛偸鞘軠y(cè)試驅(qū)動(dòng) ）

寫我的實(shí)現(xiàn)

將我的實(shí)現(xiàn)連接在一起成為應(yīng)用程序

好，前兩個(gè)很簡(jiǎn)單：

編寫調(diào)用傳遞模擬對(duì)象的方法的測(cè)試

編寫方法的實(shí)現(xiàn)以通過測(cè)試

最后變得非常困難。 最后一個(gè)變得很困難的原因是沒有一致的方法來調(diào)用每個(gè)方法。 方法具有不同的名稱，不同的參數(shù)，不同的異常，可能不同的線程要求和不同的返回類型。 我們需要的是使這些方法看起來相同的方法的基礎(chǔ)。

（耦合）控制的反轉(zhuǎn)（IoC）通過ManagedFunction在方法上提供了這種外觀。 ManagedFunction接口不會(huì)指示要使用的線程，需要的參數(shù)/返回類型，也不會(huì)拋出異常。 所有這些都由所包含的方法實(shí)現(xiàn)指定。 耦合是反向的，因此實(shí)現(xiàn)可指定所需的條件。

耦合的這種反轉(zhuǎn)使得可以推遲框架決策。 因?yàn)槲铱梢杂靡恢碌姆绞秸{(diào)用所有方法，所以我可以繼續(xù)并開始編寫實(shí)現(xiàn)。 這些實(shí)現(xiàn)可能需要響應(yīng)式編碼來對(duì)不同的微服務(wù)進(jìn)行異步調(diào)用。 其中一些實(shí)現(xiàn)可能需要使用JPA寫入關(guān)系數(shù)據(jù)庫(kù)。 我真的不應(yīng)該在開始構(gòu)建系統(tǒng)時(shí)就在意。 我正在解決具體問題，以更好地了解實(shí)際問題空間。 我知道我的方法可以通過將框架包裝在ManagedFunction中來調(diào)用。 一旦了解更多信息，我們便可以稍后確定合適的框架。

實(shí)際上，這允許實(shí)現(xiàn)選擇框架要提??供的適當(dāng)抽象。 我的實(shí)現(xiàn)定義了所需的對(duì)象，所需的其他方法以及所需的線程模型。 這些實(shí)現(xiàn)有效地定義了從框架中需要什么抽象。

因此，它不再是框架。 允許對(duì)您的開發(fā)人員代碼提出意見。

然后，這可以使您的實(shí)現(xiàn)對(duì)使用的最合適的框架有意見。 您不再需要基于對(duì)問題空間的模糊理解來猜測(cè)框架。 您可以看到實(shí)現(xiàn)需要什么抽象，并可以更明智地選擇框架。

實(shí)際上，IoC已將框架的選擇推遲到開發(fā)過程的后期。 這樣，您可以更加自信地做出決定。 這不是敏捷所說的，將承諾推遲到最后一個(gè)負(fù)責(zé)任的時(shí)刻。

摘要

總而言之，為什么要被迫對(duì)您的應(yīng)用做出太多的前期決策？ 在選擇框架時(shí)，您正在做出一些重要的選擇來解決您的問題空間。 鑒于框架的存在，它們對(duì)您的解決方案造成了很多耦合。

相反，為什么我不能立即開始為具體問題編寫解決方案并擔(dān)心以后它們?nèi)绾稳诤显谝黄?#xff1f; 當(dāng)我對(duì)問題空間有更多了解時(shí)，這使我可以選擇適當(dāng)?shù)某橄?#xff08;以及隨后的框架）。

當(dāng)您被告知正確地做出決策時(shí)，（耦合）控制的反轉(zhuǎn)使此功能可以將抽象和框架選擇推遲到開發(fā)過程的后期。

翻譯自: https://www.javacodegeeks.com/2019/05/opinionated-frameworks-inverting-opinionated-code.html

總結(jié)

以上是生活随笔為你收集整理的固执己见的框架（例如Spring Boot）的危险。 求知代码反转的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。