Отсутствии интерфейса допустимо и да класс можно именовать как DeliveryService. Но у этого есть подводные камни. - В случае использования DeliveryService в другом сервисе происходит нарушение принципа Dependency Inversion из SOLID. - В случае использования Spring и например желании сервиса сделать транзакционным вы вынуждаете использовать cglib вместо dynamic proxy. В случае единичной реализации использование Impl допустимо. В случае нескольких реализация нужно действительно использовать осмысленные имена. При наличии abstract реализации лучше тоже не использовать Impl ибо найминг будет неконстстентный AbstractDeliveryService и DeliveryServiceImpl
А как называть в чистой архитектуре, когда у нас есть доменный слой с контрактами (там DeliveryService) и слои которые реализуют контракты за которое отвечают, слой delivery-core (там DeliveryServiceImpl)? Вот в C# тоже самое, но там нейминг interface IDeliveryService и class DeliveryService и всех всё устраивает
@@kotojava так вопрос как раз как тогда добиваться низкой связанности компонентов, если у нас не будет абстракций, все слои приложения обязаны знать имплементацию
@kotojava приведу боевой пример. Есть модуль для работы с БД, он знает про jpa, postgres, имеет библиотеки для работы с ними и реализует интерфейсImpl. Остальные модули знают только про интерфейс и Spring успешно подтягивает реализацию к ним через DI. Если отказаться от интерфейса всем модулям придётся подключать этот модуль как прямую зависимость и они узнают подробности про jpa, postgres и т.п
Не существует ни одной ситуации, когда одного класса достаточно. У каждого DeliveryService всегда существует DeliveryServiceImpl и его мок, например, в тестах. Можно использовать класс напрямую, если не собираетесь писать тесты (и верите, что не породите лишний coupling)
Добавлю, в ожном проекте мы как раз не делаем интерфейсы, т. К. Согдасен с автором тут, зачем делать интерфейс и одну имплементацию. Бред. В другом проекте банка у нас кучу аннотаций свагера, тайминга, mdc и т..п. Интерфейсы служат больше для разгруза всех этих аннотаций, если бы это было все на классе, то это бы была нечитаемая хрень)
Согласен, но забыли ещё один кейс - если у вас монолит и сервис нужен для другого модуля, то сам сервис находится в апи модуле, а имплементация в импл модуле. И тогда название норм. И в этом случае если нужна новая реализация сервиса, то скорее нужна и новая реализация так как могут сигнатуры меняться и тогда все равно будет и New, и v2, и другие)
Отсутствии интерфейса допустимо и да класс можно именовать как DeliveryService. Но у этого есть подводные камни.
- В случае использования DeliveryService в другом сервисе происходит нарушение принципа Dependency Inversion из SOLID.
- В случае использования Spring и например желании сервиса сделать транзакционным вы вынуждаете использовать cglib вместо dynamic proxy.
В случае единичной реализации использование Impl допустимо.
В случае нескольких реализация нужно действительно использовать осмысленные имена.
При наличии abstract реализации лучше тоже не использовать Impl ибо найминг будет неконстстентный AbstractDeliveryService и DeliveryServiceImpl
Спасибо не надо.
В SOLID нет принципа Inversion of Control
@@dlinnozmeyдля тех кто книжек не читал. Имеется ввиду Dependency inversion
@@Skaiiur Спасибо, поправил ответ
А как называть в чистой архитектуре, когда у нас есть доменный слой с контрактами (там DeliveryService) и слои которые реализуют контракты за которое отвечают, слой delivery-core (там DeliveryServiceImpl)? Вот в C# тоже самое, но там нейминг interface IDeliveryService и class DeliveryService и всех всё устраивает
Думаю этот случай показывает что на один контракт - одна реализация бывает нормально
Не нужно делать реализацию для одной абстракции. Это загрязнение кода
@@kotojava так вопрос как раз как тогда добиваться низкой связанности компонентов, если у нас не будет абстракций, все слои приложения обязаны знать имплементацию
@@ДанилДанилов-н7м если не планируется больше чем 1 имплементация то никаких абстракций и не нужно.
@kotojava приведу боевой пример. Есть модуль для работы с БД, он знает про jpa, postgres, имеет библиотеки для работы с ними и реализует интерфейсImpl. Остальные модули знают только про интерфейс и Spring успешно подтягивает реализацию к ним через DI. Если отказаться от интерфейса всем модулям придётся подключать этот модуль как прямую зависимость и они узнают подробности про jpa, postgres и т.п
Не существует ни одной ситуации, когда одного класса достаточно. У каждого DeliveryService всегда существует DeliveryServiceImpl и его мок, например, в тестах. Можно использовать класс напрямую, если не собираетесь писать тесты (и верите, что не породите лишний coupling)
Существует. Моки не являются обязательными для хорошего тестирования.
Вообще то так классы называет самая лучшая IDE. Автор не выспался, а ролик уже записал 😅
Никогда не писал Impl в названии классов, чисто из за эстетических соображений.
Как раз про меня ахахаха
Это напрягает, но приходится так делать.
Добавлю, в ожном проекте мы как раз не делаем интерфейсы, т. К. Согдасен с автором тут, зачем делать интерфейс и одну имплементацию. Бред. В другом проекте банка у нас кучу аннотаций свагера, тайминга, mdc и т..п. Интерфейсы служат больше для разгруза всех этих аннотаций, если бы это было все на классе, то это бы была нечитаемая хрень)
Согласен, но забыли ещё один кейс - если у вас монолит и сервис нужен для другого модуля, то сам сервис находится в апи модуле, а имплементация в импл модуле. И тогда название норм. И в этом случае если нужна новая реализация сервиса, то скорее нужна и новая реализация так как могут сигнатуры меняться и тогда все равно будет и New, и v2, и другие)
Но когда в одном модуле делают и интерфейс и сам сервис это вымораживает)
Очень косноязычная речь, но за смыслы спасибо. Действительно актуально.
Озвучьте, в чем выражается косность - неясность? невнятность? невыразительность?