Мне действительно нужно создавать интерфейсы в Spring?

Question

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

public interface UserService

, а затем реализовать, например,

public class UserServiceImpl implements UserService

Поскольку нет шансов, что UserService у меня будет больше реализаций. Мне действительно надоело эти Impl суффиксы, и чем больше я читаю (например, эта статья ), я понимаю, что у меня есть причины болеть

IНа прошлой неделе у меня была беседа с другом из команды, и я поделился с ним своими мыслями, но он ответил: «В принципе, вы правы, но Spring любит интерфейсы и работает с ними лучше, чем с классами».

К сожалению, я не эксперт в Spring, и, хотя я пытался найти некоторые аргументы, я не смог найти ответ, был ли он прав.

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

Answer 1

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

Конечно, вы можете писать и повторно использовать реализации тестов, но вы можетепроделайте то же самое с mocks, например, с mockito и перезапишите поведение вашего класса реализации для тестовых случаев.

Answer 2

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

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

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

Обратите внимание, что использование Spring или нет не играет роли в использовании DI / не использовать решение DI.

Answer 3

Совершенно не нужно, в настоящее время популярны микро-сервис или мини-кодовая база.Как правило, в rest api backend у вас действительно нет возможности использовать несколько реализаций для определенного интерфейса.В этой ситуации достаточно конкретного класса с @Serivice.

Answer 4

Как и предполагали другие, это действительно зависит от вариантов использования. Хотя Spring и Java в целом начинались как многословный язык с дизайном, где интерфейсы должны действовать как то, что клиент, классы реализации, могут видеть, но я нахожу все меньше и меньше подробного кода в наши дни, особенно. с Spring Boot и такими библиотеками, как lombok.

Таким образом, создание интерфейсов для Service, DAO не обязательно, но предпочтительно, если вы работаете на довольно средней базе кода, где есть несколько разработчиков и, возможно, клиенты, использующие эти API также вне приложения. Но если вы работаете над небольшим проектом или проверкой концептуальных проектов, вы можете также создать приложение CRUD для одного класса Java.

Answer 5

Это не обязательно и, возможно, основано на мнении, но вы добавляете интерфейс для обеспечения будущей гибкости обслуживания,

Хотя вы не видите реального использования, это позволит вам использовать другую реализациюотдельных сервисов внутри модуля / интеграционного теста

Вы можете добавить тестовую реализацию вместо текущей реализации и использовать ее вместо реальной службы при выполнении теста (например, с использованием другого профиля Spring)

Это можетбыть сделано, используя насмешки, как @Simulant указывает