mockito手動注入依賴

依賴注入是一種將行為與依賴解決方案分開的技術(shù)。 用簡單的話來說，它使開發(fā)人員可以定義具有特定功能的類，這些功能取決于各種協(xié)作者，而不必定義如何獲取對這些協(xié)作者的引用。 以此方式，實現(xiàn)了各個組件之間的解耦，并且通常引入了更簡潔的代碼。 更具體地說，一個組件僅列出必要的服務(wù)，而不是對依賴項進行硬編碼，而在運行時，一個外部獨立的組件將提供對這些服務(wù)的訪問。 我們不應(yīng)忘記，依賴注入只是控制反轉(zhuǎn)的一種特殊形式，其中反轉(zhuǎn)的關(guān)注點是獲得所需依賴的過程。 前述技術(shù)的參考文章是Martin Fowler的 “控制容器的倒置和依賴注入模式” 。

為了注入依賴關(guān)系，已經(jīng)出現(xiàn)了許多框架，最著名的是Spring和Guice （請參閱JavaCodeGeeks Spring相關(guān)文章）。 但是，對于小型項目使用整個框架無疑是一個過大的殺傷力。 我們的JCG合作伙伴之一， “ Death By Code”博客的作者，對如何手動處理依賴項注入做了簡短的介紹 。 讓我們看看他怎么說？

在另一篇文章中， “我真的需要單身人士嗎？” ，我寫了有關(guān)Singleton設(shè)計模式引入的問題的文章。 通過getInstance（）方法訪問單個唯一實例時，Singleton會變相充當全局變量，并引入緊密耦合和不必要的依賴關(guān)系。 我收到了讀者的兩個直接問題：

單例應(yīng)該僅與依賴注入框架一起使用嗎？
如果通過getInstance（）訪問Singleton創(chuàng)建緊密耦合，則通過new（）創(chuàng)建任何其他類的實例也將導(dǎo)致緊密耦合。 那么，如何創(chuàng)建一個保持松散耦合的對象？

根據(jù)我的理解，依賴注入是這兩個問題的答案。 但是，這并不要求使用框架。 依賴注入首先是一個概念，然后是一個框架。 當所討論的應(yīng)用程序很小時，我們總是可以通過手動注入依賴項來滿足需求，而無需使用任何類似Spring的框架。

在任何Java應(yīng)用程序中，我們都會反復(fù)遇到兩個事件：

• 對象創(chuàng)建
• 對象之間的交互–業(yè)務(wù)邏輯

但是，通常我們將兩者混為一談，從而導(dǎo)致緊密耦合和不必要的依賴關(guān)系，這反過來又給維護以及單元測試帶來麻煩。 讓我嘗試使用一個非常簡單的示例來解釋它：

class MyClass {private A a; //A is an interfaceprivate B b; //B is an interface//Object creation within constructorMyClass(A a, B b) { a = new AImpl(); //AImpl is the concrete impl of Ab = new BImpl(); //BImpl is the concrete impl of B}//Application logic lies within this methodpublic void doSomething() {//Do A specific thing//Do B specific thingC c = new CImpl(); //Object creation within the method.//Do C specific thing} }

此類的問題是：

它無法將對象創(chuàng)建與業(yè)務(wù)邏輯分開，從而導(dǎo)致緊密耦合。

此處已完成了“實現(xiàn)編程”，而不是接口。 明天，如果需要A，B或C的不同實現(xiàn)，則必須更改類中的代碼。

測試MyClass需要首先測試A，B，C。

讓我嘗試解決問題：

class MyClass {private A a;private B b;private C c;MyClass(A a, B b, C c) {//Only Assignmentthis.a = a;this.b = b;this.c = c;}//Application Logicpublic void doSomething() {//Do A specific thing//Do B specific thing//Do C specific thing} }//The Factory class MyFactory {public MyClass createMyClass() {return new MyClass(new AImpl(), new BImpl(), new CImpl());} }class Main {public static void main(String args[]) {MyClass mc = new MyFactory().createMyClass();mc.doSomething();} }

在這里已經(jīng)實現(xiàn)了什么：

1.構(gòu)造函數(shù)沒有new（）：
沒有在MyClass的構(gòu)造函數(shù)中創(chuàng)建對象。 該構(gòu)造函數(shù)僅用于字段（A，B，C）分配。 在這里，構(gòu)造函數(shù)要求依賴項作為參數(shù)，但不創(chuàng)建它們（這是依賴項注入的最簡單定義）。 但是，可以在構(gòu)造函數(shù)中創(chuàng)建簡單的Collection對象（如ArrayList，HashMap或value / leaf對象，如Person / Employee）（即應(yīng)用程序內(nèi)的對象，這些對象又不會創(chuàng)建其他對象）。 構(gòu)造函數(shù)不應(yīng)用于任何其他操作，例如I / O，線程創(chuàng)建等。

根據(jù)經(jīng)驗法則，任何對象都應(yīng)僅保留對其直接完成工作所需的其他對象的引用（這稱為Demeter法則）。 例如，如果MyClass需要其他稱為X的類，則MyClass的構(gòu)造函數(shù)應(yīng)直接要求X。不應(yīng)要求其他工廠F可以返回X的實例。違反“ De??meter法則”將導(dǎo)致不必要的依賴關(guān)系因此，如果您發(fā)現(xiàn)多個Dot（。）運算符，請當心-那里發(fā)生了非法事件。

2. Factory（MyFactory）負責對象的創(chuàng)建和連接：
所有新的操作員（90％-99％）應(yīng)屬于工廠。 它應(yīng)負責為應(yīng)用程序創(chuàng)建整個對象圖，并應(yīng)根據(jù)聲明的依賴關(guān)系關(guān)聯(lián)（連接）不同的對象（例如，MyClass需要A，B，C等）。 它不應(yīng)包含任何其他內(nèi)容-不應(yīng)包含任何其他邏輯（沒有I / O，線程創(chuàng)建等）。

明天如果C開始依賴于其他稱為D的東西，則只會影響C和工廠，而不會影響整個對象圖（C必須引入重載的構(gòu)造函數(shù)，并且工廠必須合并對象實例化以及與對象接線相關(guān)的更改） 。

對于大型應(yīng)用程序，當然可能會有多個工廠。 在這里，經(jīng)驗法則是一個工廠應(yīng)該實例化具有相同壽命的所有對象。

3.對象的創(chuàng)建與業(yè)務(wù)邏輯是分開的：
MyClass現(xiàn)在是業(yè)務(wù)邏輯持有人。 它沒有任何new（）。 甚至，它也不了解用于業(yè)務(wù)邏輯的具體實現(xiàn)（即，它了解A，但不了解AImpl，即“接口程序而不是實現(xiàn)程序”）。

您一定已經(jīng)開始認為我是在Singleton的背景下開始討論的。 手動依賴項注入如何處理Singleton？ 如何創(chuàng)建一個Singleton（減去緊密耦合，隱藏的依賴關(guān)系等）并在需要時訪問它？ 令人驚訝的是，我們的示例中已經(jīng)有三個Singleton-AImpl，BImpl，CImpl。 如果工廠只負責創(chuàng)建Class的一個實例（通過僅調(diào)用new（）一次），則其為Singleton。 是不是 然后，工廠可以將該依賴關(guān)系形式的唯一實例傳遞給需要它的所有其他對象。

4.那么，我們在哪里？
業(yè)務(wù)邏輯持有者MyClass的業(yè)務(wù)需要A，B和C。 它不會創(chuàng)建它們，而是要它們（依賴項）。 工廠（MyFactory）創(chuàng)建這些依賴關(guān)系并將其關(guān)聯(lián)到MyClass。 但是，誰創(chuàng)造了工廠？ 當然是主要方法（應(yīng)用程序啟動器：-）。 讓我再重復(fù)一遍這個故事：main方法首先實例化工廠，工廠反過來實例化對象圖，每個Object聲明其依賴關(guān)系，最后main方法本身設(shè)置滾動－通過調(diào)用MyClass的doSomething（）啟動應(yīng)用程序，即。 這些對象開始互相交談，執(zhí)行日常業(yè)務(wù)。

讓我再重復(fù)一次： 創(chuàng)建工廠，使用工廠創(chuàng)建應(yīng)用程序，然后啟動應(yīng)用程序！ 對于大規(guī)模應(yīng)用程序，可以通過像Spring，Google Guice等依賴注入框架來實現(xiàn)相同的目的。當然，它們還將帶來許多其他好處。 但是，對于中小型應(yīng)用程序，可以手動制作依賴項注入，從而使應(yīng)用程序松散耦合，更易于維護并且當然對單元測試友好。

相關(guān)文章 ：

• 使用Spring AspectJ和Maven進行面向方面的編程
• JBoss 4.2.x Spring 3 JPA Hibernate教程
• GWT Spring和Hibernate進入數(shù)據(jù)網(wǎng)格世界
• 建立自己的GWT Spring Maven原型
• GWT 2 Spring 3 JPA 2 Hibernate 3.5教程– Eclipse和Maven 2展示
• 使用Spring使用Java發(fā)送電子郵件– GMail SMTP服務(wù)器示例

翻譯自: https://www.javacodegeeks.com/2010/12/dependency-injection-manual-way.html

mockito手動注入依賴

總結(jié)

以上是生活随笔為你收集整理的mockito手动注入依赖_依赖注入–手动方式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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