使用dagger2來做依賴注入（通俗易懂）

阿新 • • 發佈：2019-02-01

http://chriszou.com/2016/05/10/android-unit-testing-di-dagger.html

問題

在前一篇文章中，我們講述了依賴注入的概念，以及依賴注入對單元測試極其關鍵的重要性和必要性。在那篇文章的結尾，我們遇到了一個問題，那就是如果不使用DI框架，而全部採用手工來做DI的話，那麼所有的Dependency都需要在最上層的client來生成，這可不是件好事情。繼續用我們前面的例子來具體說明一下。
假設有一個登入介面，LoginActivity，他有一個LoginPresenter，LoginPresenter用到了UserManager和PasswordValidator

，為了讓問題變得更明顯一點，我們假設UserManager用到SharedPreference（用來儲存一些使用者的基本設定等）和UserApiService，而UserApiService又需要由Retrofit建立，而Retrofit又用到OkHttpClient（比如說你要自己控制timeout、cache等東西）。
應用DI模式，UserManager的設計如下：

public class UserManager {
    private final SharedPreferences mPref;
    private final UserApiService mRestAdapter 
;

    public UserManager(SharedPreferences preferences, UserApiService userApiService) {
        this.mPref = preferences;
        this.mRestAdapter = userApiService;
    }

    /**Other code*/
}

LoginPresenter的設計如下：

public class LoginPresenter {
    private final UserManager mUserManager;
    private 
 final PasswordValidator mPasswordValidator;

    public LoginPresenter(UserManager userManager, PasswordValidator passwordValidator) {
        this.mUserManager = userManager;
        this.mPasswordValidator = passwordValidator;
    }

    /**Other code*/
}

在這種情況下，最終的client LoginActivity裡面要new一個presenter，需要做的事情如下：

public class LoginActivity extends AppCompatActivity {
    private LoginPresenter mLoginPresenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        OkHttpClient okhttpClient = new OkHttpClient.Builder()
                .connectTimeout(30, TimeUnit.SECONDS)
                .build();
        Retrofit retrofit = new Retrofit.Builder()
                .client(okhttpClient)
                .baseUrl("https://api.github.com")
                .build();
        UserApiService userApiService = retrofit.create(UserApiService.class);
        SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(this);
        UserManager userManager = new UserManager(preferences, userApiService);

        PasswordValidator passwordValidator = new PasswordValidator();
        mLoginPresenter = new LoginPresenter(userManager, passwordValidator);
    }
}

這個也太誇張了，LoginActivity所需要的，不過是一個LoginPresenter而已，然而它卻需要知道LoginPresenter的Dependency是什麼，LoginPresenter的Dependency的Dependency又是什麼，然後new一堆東西出來。而且可以預見的是，這個app的其他地方也需要這裡的OkHttpClient、Retrofit、SharedPreference、UserManager等等dependency，因此也需要new這些東西出來，造成大量的程式碼重複，和不必要的object instance生成。然而如前所述，我們又必須用到DI模式，這個怎麼辦呢？

想想，如果能達到這樣的效果，那該有多好：我們只需要在一個類似於dependency工廠的地方統一生產這些dependency，以及這些dependency的dependency。所有需要用到這些Dependency的client都從這個工廠裡面去獲取。而且更妙的是，一個client（比如說LoginActivity）只需要知道它直接用到的Dependency（LoginPresenter），而不需要知道它的Dependency（LoginPresenter）又用到哪些Dependency（UserManager和PasswordValidator）。系統自動識別出這個依賴關係，從工廠裡面把需要的Dependency找到，然後把這個client所需要的Dependency創建出來。

有這樣一個東西，幫我們實現這個效果嗎？相信聰明的你已經猜到了，回答是肯定的，它就是我們今天要介紹的dagger2。

解藥：Dagger2

在dagger2裡面，負責生產這些Dependency的統一工廠叫做 Module ，所有的client最終是要從module裡面獲取Dependency的，然而他們不是直接向module要的，而是有一個專門的“工廠管理員”，負責接收client的要求，然後到Module裡面去找到相應的Dependency，提供給client們。這個“工廠管理員”叫做 Component。基本上，這是dagger2裡面最重要的兩個概念。

下面，我們來看看這兩個概念，對應到程式碼裡面，是怎麼樣的。

生產Dependency的工廠：Module

首先是Module，一個Module對應到程式碼裡面就是一個類，只不過這個類需要用dagger2裡面的一個annotation @Module來標註一下，來表示這是一個Module，而不是一個普通的類。我們說Module是生產Dependency的地方，對應到程式碼裡面就是Module裡面有很多方法，這些方法做的事情就是建立Dependency。用上面的例子中的Dependency來說明：

@Module
public class AppModule {

    public OkHttpClient provideOkHttpClient() {
        OkHttpClient okhttpClient = new OkHttpClient.Builder()
                .connectTimeout(30, TimeUnit.SECONDS)
                .build();
        return okhttpClient;
    }

    public Retrofit provideRetrofit(OkHttpClient okhttpClient) {
        Retrofit retrofit = new Retrofit.Builder()
                .client(okhttpClient)
                .baseUrl("https://api.github.com")
                .build();
        return retrofit;
    }
}

在上面的Module（AppModule）中，有兩個方法provideOkHttpClient()和provideRetrofit(OkHttpClient okhttpClient)，分別建立了兩個Dependency，OkHttpClient和Retrofit。但是呢，我們也說了，一個Module就是一個類，這個類有一些生產Dependency的方法，但它也可以有一些正常的，不是用來生產Dependency的方法。那怎麼樣讓管理員知道，一個Module裡面哪些方法是用來生產Dependency的，哪些不是呢？為了方便做這個區分，dagger2規定，所有生產Dependency的方法必須用 @Provides這個annotation標註一下。所以，上面的 AppModule正確的寫法應該是：

@Module
public class AppModule {
    @Provides
    public OkHttpClient provideOkHttpClient() {
        OkHttpClient okhttpClient = new OkHttpClient.Builder()
                .connectTimeout(30, TimeUnit.SECONDS)
                .build();
        return okhttpClient;
    }

    @Provides
    public Retrofit provideRetrofit(OkHttpClient okhttpClient) {
        Retrofit retrofit = new Retrofit.Builder()
                .client(okhttpClient)
                .baseUrl("https://api.github.com")
                .build();
        return retrofit;
    }
}

這種用來生產Dependency的、用 @Provides修飾過的方法叫Provider方法。這裡要注意第二個Provider方法 provideRetrofit(OkHttpClient okhttpClient)，這個方法有一個引數，是OkHttpClient。這是因為建立一個Retrofit物件需要一個OkHttpClient的物件，這裡通過引數傳遞進來。這樣做的好處是，當Client向管理員（Component）索要一個Retrofit的時候，Component會自動找到Module裡面找到生產Retrofit的這個 provideRetrofit(OkHttpClient okhttpClient)方法，找到以後試圖呼叫這個方法建立一個Retrofit物件，返回給Client。但是呼叫這個方法需要一個OkHttpClient，於是Component又會去找其他的provider方法，看看有沒有哪個會生產OkHttpClient。於是就找到了上面的第一個provider方法： provideOkHttpClient()。找到以後，呼叫這個方法，建立一個OkHttpClient物件，再呼叫 provideRetrofit(OkHttpClient okhttpClient)方法，把剛剛建立的OkHttpClient物件傳進去，創建出一個Retrofit物件，返回給Client。當然，如果最後找到的 provideOkHttpClient()方法也需要其他引數，那麼管理員還會繼續遞迴的找下去，直到所有的Dependency都被滿足了，再一個一個建立Dependency，然後把最終Client需要的Dependency呈遞給Client。
很好，現在我們把文章開頭的例子中的所有Dependency都用這種方式，在 AppModule裡面宣告一個provider方法：

@Module
public class AppModule {
    @Provides
    public OkHttpClient provideOkHttpClient() {
        OkHttpClient okhttpClient = new OkHttpClient.Builder()
                .connectTimeout(30, TimeUnit.SECONDS)
                .build();
        return okhttpClient;
    }

    @Provides
    public Retrofit provideRetrofit(OkHttpClient okhttpClient) {
        Retrofit retrofit = new Retrofit.Builder()
                .client(okhttpClient)
                .baseUrl("https://api.github.com")
                .build();
        return retrofit;
    }

    @Provides
    public UserApiService provideUserApiService(Retrofit retrofit) {
        return retrofit.create(UserApiService.class);
    }

    @Provides
    public SharedPreferences provideSharedPreferences(Context context) {
        return PreferenceManager.getDefaultSharedPreferences(context);
    }

    @Provides
    public UserManager provideUserManager(SharedPreferences preferences, UserApiService service) {
        return new UserManager(preferences, service);
    }

    @Provides
    public PasswordValidator providePasswordValidator() {
        return new PasswordValidator();
    }

    @Provides
    public LoginPresenter provideLoginPresenter(UserManager userManager, PasswordValidator validator) {
        return new LoginPresenter(userManager, validator);
    }
}

上面的程式碼如果你仔細看的話，會發現一個問題，那就是其中的SharedPreference provider方法 provideSharedPreferences(Context context)需要一個context物件，但是 AppModule裡面並沒有context 的Provider方法，這個怎麼辦呢？對於這個問題，你可以再建立一個context provider方法，但是context物件從哪來呢？我們可以自定義一個Application，裡面提供一個靜態方法返回一個context，這種做法相信大家都幹過。Application類如下：

public class MyApplication extends Application {
    private static Context sContext;

    @Override
    public void onCreate() {
        super.onCreate();
        sContext = this;
    }

    public static Context getContext() {
        return sContext;
    }
}

provider方法如下：

    @Provides
    public Context provideContext() {
        return MyApplication.getContext();
    }

但是這種方法不是很好，為什麼呢，因為context的獲得相當於是寫死了，只能從MyApplication.getContext()，如果測試環境下想把Context換成別的，還要給MyApplication定義一個setter，然後呼叫MyApplication.setContext(...)，這個就繞的有點遠。更好的做法是，把Context作為 AppModule的一個構造引數，從外面傳進來（應用DI模式，還記得嗎？）：

@Module
public class AppModule {
    private final Context mContext;

    public AppModule(Context context) {
        this.mContext = context;
    }

    @Provides
    public Context provideContext() {
        return mContext;
    }

    //其他的provider方法

}

是的，一個Module就是一個正常的類，它也可以有構造方法，以及其他正常類的特性。你可能會想那給建構函式的context物件從哪來呢？別急，這個問題馬上解答。

Dependency工廠管理員：Component

前面我們講了dagger2的一半，就是生產Dependency的工廠：Module。接下來我們講另一半，工廠管理員：Component。跟Module不同的是，我們在實現Component時，不是定義一個類，而是定義一個介面（interface）：

public interface AppComponent {
}

名字可以隨便取，跟Module需要用 @Module修飾一下類似的，一個dagger2的Component需要用 @Component修飾一下，來標註這是一個dagger2的Component，而不是一個普通的interface，所以正確的定義方式是：

@Component
public interface AppComponent {
}

在實際情況中，可能有多個Module，也可能有多個Component，那麼當Component接收到一個Client的Dependency請求時，它怎麼知道要從哪個Module裡面去找這些Dependency呢？它不可能遍歷我們的每一個類，然後找出所有的Module，再遍歷所有Module的Provider方法，去找Dependency，這樣先不說能不能做到，就算做得到，效率也太低了。因此dagger2規定，我們在定義Component的時候，必須指定這個管理員“管理”哪些工廠（Module）。指定的方法是，把需要這個Component管理的Module傳給 @Component這個註解的modules屬性（或者叫方法？），如下：

@Component(modules = {AppModule.class})  //<=
public interface AppComponent {
}

modules屬性接收一個數組，裡面是這個Component管理的所有Module。在上面的例子中，AppComponent只管理AppModule一個。

Component給Client提供Dependency的方法

前面我們講了Module和Component的實現，接下來就是Component怎麼給Client提供Dependency的問題了。一般來說，有兩種，當然總共不止這兩種，只不過這兩種最常用，也最好理解，一般來說用這兩種就夠了，因此這裡不贅述其他的方法。

方法一：在Component裡面定義一個返回Dependency的方法

第一種是在Component裡面定義一個返回Dependency的方法，比如LoginActivity需要LoginPresenter，那麼我們可以在AppComponent裡面定義一個返回LoginPresenter的方法：

@Component(modules = {AppModule.class})
public interface AppComponent {
    LoginPresenter loginPresenter();
}

你可能會好奇，為什麼Component只需要定義成介面就行了，不是應該定義一個類，然後自己使用Module去做這件事嗎？如果是這樣的話，那就太low了。dagger2的工作原理是，在你的java程式碼編譯成位元組碼的過程中，dagger2會對所有的Component（就是用 @Component修飾過的interface）進行處理，自動生成一個實現了這個interface的類，生成的類名是Component的名字前面加上“Dagger”。比如我們定義的 AppComponent，對應的自動生成的類叫做DaggerAppComponent。我們知道，實現一個interface需要實現裡面的所有方法，因此，DaggerAppComponent是實現了 loginPresenter();這個方法的。實現的方式大致就是從 AppComponent管理的 AppModule裡面去找LoginPresenter的Provider方法，然後呼叫這個方法，返回一個LoginPresenter。

因此，使用這種方式，當Client需要Dependency的時候，首先需要用DaggerAppComponent這個類建立一個物件，然後呼叫這個物件的 loginPresenter()方法，這樣Client就能獲得一個LoginPresenter了，這個DaggerAppComponent物件的建立及使用方式如下：

public class LoginActivity extends AppCompatActivity {
    private LoginPresenter mLoginPresenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        AppComponent appComponent = DaggerAppComponent.builder().appModule(new AppModule(this)).build();  //<=
        mLoginPresenter = appComponent.loginPresenter();   //<=
    }
}

總結一下，我們到現在為止，做了什麼：

我們定義了一個 AppModule類，裡面定義了一些Provider方法
定義了一個 AppComponent，裡面定義了一個返回LoginPresenter的方法loginPresenter()。

就這樣，我們便可以使用 DaggerAppComponent.builder().appModule(new AppModule(this)).build().loginPresenter(); 來獲取一個LoginPresenter物件了。
這簡直就是magic，不是嗎？
如果不是dagger2，而是我們自己來實現這個AppComponent interface，想想我們需要做哪些事情：

定義一個Constructor，接受一個AppModule物件，儲存在field中（mAppModule)
實現loginPresenter()方法，呼叫mAppModule的provideLoginPresenter(UserManager userManager, PasswordValidator validator)方法，這時候發現這個方法需要兩個引數 UserManager和PasswordValidator。
呼叫provideUserManager(SharedPreferences preferences, UserApiService service)來獲取一個UserManager，這時候發現這個方法又需要兩個引數 SharedPreferences和 UserApiService。
呼叫provideSharedPreferences(Context context)來獲取一個SharedPreference，這時候發現先要有一個context
。。。
。。。
。。。

說白了，就是把文章開頭我們寫的那段程式碼又實現了一遍，而使用dagger2，我們就做了前面描述的兩件事而已，這裡面錯綜複雜的Dependency關係dagger2幫我們自動理清了，生成相應的程式碼，去呼叫相應的Provider方法，滿足這些依賴關係。
也許這裡舉得這個例子不足以讓你覺得有什麼大不了的，但是你要知道，一個正常的App，可不僅僅有一個Login page而已，稍微大點的App，Dependency都有幾百甚至上千個，對於伺服器程式來說，Dependency則更多。對於這點，大家可以去看Dagger2主要作者的這個視訊，他裡面提到了Google一個android app有3000行程式碼專門來管理Dependency，而一個Server app甚至有10萬行這樣的程式碼。這個時候要去手動new這些dependency、並且要以正確的順序new出來，簡直會要人命。而且讓問題更加棘手的是，隨著app的演進需求的變更，Dependency之間的關係也在動態的變化。比如說UserManager不再使用SharedPreference，而是使用database，這個時候UserManager的建構函式裡面少了一個SharedPreferences，多了一個DatabaseHelper這樣的東西，那麼如果使用正常的方式管理Dependency，所有new UserManager的地方都要改，而是用dagger2，你只需要在 AppModule裡面新增一個DatabaseHelper Provider方法，同時把UserManager的provider方法第一引數從SharedPreferences改成DatabaseHelper就好了，所有用到UserManager的地方不需要做任何更改，LoginPresenter不需要做任何更改，LoginActivity不需要任何更改，這難道不是magic嗎？

說點題外話，這種把問題(我們這裡是依賴關係)描述出來，而不是把實現過程寫出來的程式設計風格叫Declarative programming，跟它對應的叫Imperative Programming，相對於後者，前者的優勢是：可讀性更高，side effect更少，可擴充套件性更高等等。這是一種程式設計風格，跟語言、框架無關。當然，有的語言或框架天生就能讓程式設計師更容易的使用這種style來程式設計。這方面最顯著的當屬Prolog，有興趣的可以去了解下，絕對mind-blowing！
對於Java或Android開發者來說，想讓我們的程式碼更加declarative，最好的方式是使用dagger2和RxJava。

方法二：Field Injection

話說回來，我們繼續介紹dagger2，前面我們介紹了Component給Client提供Dependency的第一種方式，接下來繼續介紹第二種方式，這種方式叫 Field injection 。這裡我們繼續用LoginActivity的例子來說明，LoginActivity需要一個LoginPresenter。那麼使用這種方式的做法是，我們就在LoginActivity裡面定義一個LoginPresenter的field，這個field需要使用 @Inject修飾一下：

public class LoginActivity extends AppCompatActivity {
    @Inject                             //<=
    LoginPresenter mLoginPresenter;     //<=

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

然後在onCreate()裡面，我們把DaggerAppComponent物件創建出來，呼叫這個物件的inject方法，把LoginActivity傳進去：

public class LoginActivity extends AppCompatActivity {
    @Inject                             
    LoginPresenter mLoginPresenter;     

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        AppComponent appComponent = DaggerAppComponent.builder().appModule(new AppModule(this)).build(); //<=
        appComponent.inject(this); //<=

        //從此之後，mLoginPresenter就被例項化了
        //mLoginPresenter.isLogin()
    }
}

當然，我們需要先在AppComponent裡面定義一個inject(LoginActivity loginActivity)方法：

@Component(modules = {AppModule.class})
public interface AppComponent {
    void inject(LoginActivity loginActivity);  //<=
}

DaggerAppComponent實現這個方法的方式是，去LoginActivity裡面所有被 @Inject修飾的field，然後呼叫 AppModule相應的Provider方法，賦值給這個field。這裡需要注意的是，@Inject field不能使private，不然dagger2找不到這個field。
通常來說，這種方式比第一種方式更簡單，程式碼也更簡潔。假設LoginActivity還需要其他的Dependency，比如需要一個統計打點的Dependency（StatManager），那麼你只需要在AppModule裡面定義一個Provider方法，然後在LoginActivity裡面宣告另外一個field就好了：

public class LoginActivity extends AppCompatActivity {
    @Inject                             
    LoginPresenter mLoginPresenter;  

    @Inject
    StatManager mStatManager;   //<=

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        AppComponent appComponent = DaggerAppComponent.builder().appModule(new AppModule(this)).build();
        appComponent.inject(this);
    }
}

無論有多少個@Inject field，都只需要呼叫一次appComponent.inject(this);。用過了你就會覺得，恩，好爽！
不過，需要注意的一點是，這種方式不支援繼承，比如說LoginActivity繼承自一個 BaseActivity，而@InjectStatManager mStatManager;是放在BaseActivity裡面的，那麼在LoginActivity裡面呼叫 appComponent.inject(this);並不會讓BaseActivity裡面的 mStatManager得到例項化，你必須在 BaseActivity裡面也呼叫一次appComponent.inject(this);。

@Singleton和Constructor Injection

到這裡，Client從Component獲取Dependency的兩種方式就介紹完畢。但是這裡有個問題，那就是每次Client向Component索要一個Dependency，Component都會建立一個新的出來，這可能會導致資源的浪費，或者說很多時候不是我們想要的，比如說，SharedPreferences、UserManager、OkHttpClient, Retrofit這些都只需要一份就好了，不需要每次都建立一個instance，這個時候我們可以給這些Dependency的Provider方法加上@Singleton就好了。如：

@Module
public class AppModule {

    @Provides
    @Singleton          //<=
    public OkHttpClient provideOkHttpClient() {
        OkHttpClient okhttpClient = new OkHttpClient.Builder()
                .connectTimeout(30, TimeUnit.SECONDS)
                .build();
        return okhttpClient;
    }

    //other method
}

這樣，當Client第一次請求一個OkHttpClient，dagger2會建立一個instance，然後儲存下來，下一次Client再次請求一個OkHttpClient是，dagger2會直接返回上次建立好的，而不用再次建立instance。這就相當於用一種更簡便、而且DI-able的方式實現了singleton模式。

這裡再給大家一個bonus，如果你不需要做單元測試，而只是使用dagger2來做DI，組織app的結構的話，其實AppModule裡面的很多Provider方法是不需要定義的。比如說在這種情況下，LoginPresenter的Provider方法 provideLoginPresenter(UserManager userManager, PasswordValidator validator) 就不需要定義，你只需要在定義LoginPresenter的時候，給它的Constructor加上 @Inject修飾一下：

public class LoginPresenter {
    private final UserManager mUserManager;
    private final PasswordValidator mPasswordValidator;

    @Inject
    public LoginPresenter(UserManager userManager, PasswordValidator passwordValidator) {
        this.mUserManager = userManager;
        this.mPasswordValidator = passwordValidator;
    }

    //other methods
}

dagger2會自動建立這個LoginPresenter所需要的Dependency是它能夠提供的，所以會去Module裡面找到這個LoginPresenter所需的Dependency，交給LoginPresenter的Constructor，建立好這Dependency，交給Client。這其實也是Client通過Component使用Dependency的一種方式，叫 Constructor injection （上一篇文章也提到Constructor injection，不過稍微有點不同，注意區分一下）同樣的，在那種情況下，UserManager的Provider方法也不需要定義，而只需要給UserManager的Constructor加上一個@Inject就好了。說白了，你只需要給那些不是通過Constructor來建立的Dependency（比如說SharedPreferences、UserApiService等）定義Provider方法。
有了 Constructor injection ，我們的程式碼又能得到進一步的簡化，然而遺憾的是，這種方式將導致我們做單元測試的時候無法mock這中間的Dependency。說到單元測試，我們別忘了這個系列的主題T_T。。。那麼接下來就介紹dagger2在單元測試裡面的使用，以及為什麼 Constructor injection 將導致單元測試裡面無法mock這個Dependency。

使用dagger2來做依賴注入（通俗易懂）

問題

解藥：Dagger2

生產Dependency的工廠：Module

Dependency工廠管理員：Component

Component給Client提供Dependency的方法

方法一：在Component裡面定義一個返回Dependency的方法

方法二：Field Injection

@Singleton和Constructor Injection

使用dagger2來做依賴注入（通俗易懂）

Android單元測試（6）：使用dagger2來做依賴注入

HDFS檔案讀寫操作（通俗易懂）

傅立葉變換的意義和理解（通俗易懂）

Vue實戰指南之依賴注入（provide / inject）

SIR疾病傳播模型理論（通俗易懂）

spring依賴注入（Depondency Injection）

4. IOC容器的依賴注入（原始碼解讀）

資料庫三大正規化詳解（通俗易懂）

什麼是分散式系統（通俗易懂）

JavaScript 觀察者模式（通俗易懂）

websocket 簡介（通俗易懂）

關於java中的鎖的理解（通俗易懂）

C++中類與物件的講解（通俗易懂）

epoll底層實現原理（通俗易懂）

Spring AOP概念理解（通俗易懂）

我徹底服了，大牛講解訊號與系統（通俗易懂）

執行緒同步之互斥物件（通俗易懂）

Spring：依賴注入（註解方式）、泛型依賴注入

如何從零開始搭建自己的部落格（通俗易懂）

使用dagger2來做依賴注入（通俗易懂）

問題

解藥：Dagger2

生產Dependency的工廠：Module

Dependency工廠管理員：Component

Component給Client提供Dependency的方法

方法一：在Component裡面定義一個返回Dependency的方法

方法二：Field Injection

@Singleton和Constructor Injection

相關推薦