Весна как прославленная фабрика; это приемлемо?

Question

Я только что унаследовал Java-приложение, и после проверки кода я вижу, что IMHO является бастардизацией среды Spring. Видите ли, команда Java, похоже, не любит интерфейсы, поэтому мы в итоге получаем такие вещи:

@Autowired
private SomeConcreteFinalClass _myField;

Нет конфигурации Spring, не определен bean-компонент, нет шансов, что я смогу протестировать содержащий объект изолированно. По сути, это фабрика на основе аннотаций с накладными расходами Spring.

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

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

Здесь нет тайны, я надеюсь. Если у меня есть конкретный класс, который не за интерфейсом, и нет соответствующего Spring боб для «установки» объект, то это бесспорно прославленный завод, который может быть реализован с 10 строк кода.

Spring не используется никаким другим способом в системе; это оно.

Мои цели прямо сейчас:

• Институт политики тестирования
• Обучать команда по достоинствам компонента изоляция
• Переместить эти поля с автопроводкой за интерфейсами

Полагаю, последний вопрос: есть ли польза от сохранения этих полей в Autowired, если мы не тестируем или каким-либо другим образом используем фреймворк? Я бы точно так же new обьект, если зависимость неизменна.

Answer 1

Это, конечно, ограничивает то, что возможно, но это также не пустая трата времени.

Поскольку типом запроса является final, его нельзя легко смоделировать для изолированного тестирования.

Однако экземпляры этого типа могут по-прежнему настраиваться с помощью своих свойств. Использование Spring для внедрения экземпляра, который правильно сконфигурирован во время выполнения, значительно упрощает содержащий класс. Класс может сосредоточиться на своих обязанностях, полагаясь на то, что Spring предоставит ему необходимых сотрудников.

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

Answer 2

Я бы согласился с вами, что это злоупотребление тем, что может делать Spring (в отличие от того, что должен делать Spring). Человек, который разработал приложение таким образом? Было бы интересно услышать их обоснование для создания приложения таким образом.

Answer 3

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

Если вы жалуетесь на тот факт, что статический тип этого объекта не является интерфейсом, у вас может быть точка. Но даже это трудно отличить от этой единственной строки кода. Это действительно сервис или класс репозитория без интерфейса? Если так, я согласен. Если нет, мне нужно знать больше.

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

Возможно, у вас есть точка зрения, но я не уверен в вашем первоначальном вопросе. Может быть, вы можете редактировать более подробно.

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

Answer 4

Не могу сказать, что полностью вижу смысл. В конце концов, для соединения системы в методе main, скорее всего, потребуется несколько строк кода, и тогда у вас не будет зависимости от Spring.

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