2015-04-09 2 views
1

В документации говорится, что методы @Provides могут иметь зависимости от их собственного, как:Обеспечить метод dependendies

@Provides Pump providePump(Thermosiphon pump) { 
    return pump; 
} 

Что бы изменилось, если бы я написать это так:

@Provides Pump providePump() { 
    return new Thermosiphon(); 
} 

И в первом отрезаемом: откуда этот метод получает свой насос?

ответ

2

документация также показывает Thermosiphon класс:

class Thermosiphon implements Pump { 
    private final Heater heater; 

    @Inject 
    Thermosiphon(Heater heater) { 
    this.heater = heater; 
    } 

    ... 
} 

Конструктор этого класса с аннотацией @Inject. Это позволяет Dagger знать, использовать этот конструктор всякий раз, когда нужен Thermosiphon, и автоматически отправляет на него экземпляр Heater, так что вам не нужно.

Это идеальное решение для создания нового Thermospihon экземпляра, но Кинжал избавит вас от неприятностей, сделав это так. Например, вам нужно будет получить ссылку Heater где-нибудь, если вы сделаете это вручную. Вот что такое Кинжал, поэтому вам не нужно делать утомительную повторяющуюся работу.

+0

Я все еще пытаюсь обернуть голову вокруг этого материала кинжалом. Итак, @Inject в основном имеет два разных значения. Если он аннотирует поле, это означает, что инжектор вводит это поле. Если он комментирует конструктор, значит, он использует этот конструктор для вставки этого объекта где-то еще (и необходимых аргументов в этот конструктор)? – Kuno

+0

@ Куно Более или менее. Вы можете прочитать [JSR 330] (https://jcp.org/en/jsr/detail?id=330) (раздел 4) для подробного объяснения аннотации '@ Inject'. – nhaarman

+0

@ IsaiahvanderElst Я не совсем следую за тобой. Не могли бы вы уточнить? – nhaarman

2

Это фактически то же самое IF новый экземпляр Thermosiphon.class создается каждый раз, когда вы запрашиваете экземпляр. Если это синглтон (или каким-либо образом), то у нас есть разница.

Если у вас есть следующее, то первым примером является псевдоним одиночного элемента. Второй пример, однако, все равно будет создавать новые экземпляры каждый раз.

@Provides 
@Singleton 
Thermosiphon provideThermosiphon() { 
    return new Thermosiphon(); 
} 



Лично мне нравится первый подход лучше. Используя первый подход, вы можете добавить или изменить поставщика позже и настроить область действия или состояние экземпляра, прежде чем он будет передан псевдониму. Это кажется немного более гибким.

0

Он ищет другие бобы объявленным в модуле

Например:

@Module 
public class MainModule { 


    @Provides 
    public EmailServiceApiGateway provideEmailServiceApiGateway() { 
     return new EmailServiceApiGateway(); 
    } 

    @Provides 
    public EmailSendingActivityPresenter provideEmailSendingActivityPresenter(EmailServiceApiGateway emailServiceApiGateway) { 
     return new EmailSendingActivityPresenterImpl(emailServiceApiGateway); 
    } 
} 

Таким образом, в приведенном выше случае, EmailServiceApiGateway получает автоматически впрыскивается в EmailSendingActivityPresenter.

Смежные вопросы