Класс настройки - лучшая практика с Guice - PullRequest
Новая
       0

Класс настройки - лучшая практика с Guice

4 голосов
/ 16 сентября 2011

Справочная информация: я использую Google Guice, и поэтому проще пройти через класс конфигурации, но я думаю, что это не лучший способ.

У меня есть класс конфигурации, в котором хранятся некоторые пути: 

class Configuration{
   String getHomePath();
   String getUserPath();
}

Также у меня есть класс "a", которому нужен "homepath", и класс "b", которому нужен "userpath".

Лучше ли передавать класс конфигурации через конструкторкласса А и В или только пройти по определенному пути?

Ответы [ 3 ]

3 голосов
/ 25 сентября 2011

Если вы действительно правильно используете Guice, вся ваша конфигурация должна отображаться в методе configure модулей. Итак:

  1. Удалить класс конфигурации.
  2. Создание классов аннотаций, которые, вероятно, называются HomePath и UserPath.
  3. Если класс a использует getHomePath(), замените его полевым элементом String с именем homePath.
  4. Если в классе b используется getUserPath(), замените его на строковый член с именем userPath.
  5. Измените конструкторы классов a и b так, чтобы они были @Inject аннотированы (уже должны быть), и примите параметр String, соответственно аннотированный @HomePath и @UserPath, и назначьте элемент поля String, который вставил значение.
  6. Создайте привязки в методе настройки вашего модуля, используя .annotatedWith(), которые определяют правильные значения; если они доступны только во время выполнения, свяжите провайдера.

Е.Г. 

class a {
  private String homePath;
  @Inject
  public a(@HomePath String homePath) {
    this.homePath = homePath;
  }
  public String tellMeAboutHome() {
    return "We live in a nice home called " + homePath;
  }
}

class customModule extends AbstractModule {
  public static final String userPath = "/home/rafael";

  public void configure() {
    bind(String.class).annotatedWith(HomePath.class).to("/home/");
    bind(String.class).annotatedWith(UserPath.class).to(userPath);
  }
}

Если создание аннотаций слишком сложная задача, используйте @Named annotation Guice поставляется с .

1 голос
/ 20 сентября 2011

Нет однозначного ответа на ваш вопрос, есть только варианты на выбор, в зависимости от вашей конкретной ситуации.

Если вы знаете, что ваш Configuration класс будет расти И , если это вероятно для ваших A и B классов будет использовать больше от него, тогда передайте весь объект Configuration их конструкторы. NB: я знаю, что это противоречит принципу YAGNI, но иногда вы можете знать, что он вам понадобится; -)

В противном случае вы можете рассмотреть возможность использования @Named внедрения ваших путей, чтобы свести к минимуму зависимости классов A и B до их минимума, что является хорошей практикой проектирования.

1 голос
/ 16 сентября 2011

Общее правило - это код, делающий граф зависимостей (о котором классы знают или зависят от других классов / интерфейсов) максимально простым, регулярным и фиксированным.

Если не передать класс Configuration, a или b будут иметь нулевую зависимость от пользовательских классов или необходимо избежать цикла зависимостей, тогда используйте отдельные строки пути. В противном случае, если имеет больше смысла говорить «этот класс имеет доступ к информации о конфигурации, что может измениться в будущем», передайте класс.

Я бы избегал одноэлементного подхода, особенно если у вас уже настроен Guice.

...