Разве плохо использовать инжекторы конструктора и конструкторы по умолчанию вместе?

Question

В настоящее время я пытаюсь улучшить тестируемость устаревшей системы, написанной на Java. Наиболее существенная проблема - это наличие «внутренних» зависимостей, которые нельзя исключить. Решение этой проблемы довольно простое: введите внедрение зависимости.

К сожалению, кодовая база довольно большая, поэтому было бы огромным усилием внедрить внедрение зависимостей во всем приложении, вплоть до «начальной загрузки». Для каждого класса, который я хочу протестировать, мне нужно будет изменить еще сотню (может быть, я немного преувеличиваю здесь, но это определенно будет много) классов, которые зависят от измененного компонента.

Теперь к моему вопросу: было бы нормально использовать два конструктора, конструктор по умолчанию, который инициализирует поля экземпляра значениями по умолчанию, и еще один, чтобы разрешить внедрение зависимостей? Есть ли недостатки при использовании этого подхода? Это позволит внедрить зависимости для будущего использования, но все же не требует изменения существующего кода (несмотря на тестируемый класс).

Текущий код («внутренние» зависимости):

public class ClassUnderTest {

  private ICollaborator collab = new Collaborator();

  public void methodToTest() {
    //do something
    collab.doComplexWork();
    //do something
  }

}

С конструктором по умолчанию / di:

public class ClassUnderTest {

  private ICollaborator collab;

  public ClassUnderTest() {
    collab = new Collaborator();
  }

  public ClassUnderTest(ICollaborator collab) {
    this.collab = collab;
  }

  public void methodToTest() {
    //do something
    collab.doComplexWork();
    //do something
  }

}

Answer 1

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

Я бы более осторожно добавил функцию setCollaborator(), потому что это радикальноизменяет контракт (и допущения) для ClassUnderTest, что приведет к странным сценариям ошибок, если он вызывается из кода, написанного кем-то, кто не знает историю, не прочитал документы должным образом (или, возможно, нет никаких документов ввсе ...)

Answer 2

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

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

Это не такой хороший шаблон, как полноценное внедрение зависимостей, но это не всегда вариант.