VS
Если они вызывают один код, то как они могут быть не одинаковыми?)
Size: a a a
2021 May 04
ЕО
Если один интерфейс используется в нескольких местах, то стоит его вынести в отдельный интерфейсный пакет. Но нужно это делать умно. Часто несколько мест, использующих "один интерфейс", то на самом деле это разные интерфейсы, в определённый момент времени выглядящие как один
VS
Зачем?
Какой профит мы получаем благодаря дополнительному коду?
Какой профит мы получаем благодаря дополнительному коду?
DP
наши пакеты становятся самодостаточными
VS
Зачем его выносить в интерфейсный пакет? Это явно не про «high cohesion»
ЕО
В определённый момент времени вам может потребоваться вызвать не этот код, а некую прослойку. Например, если вы будете один сервис пилить на два, то "демоны" уже будут не ваш код вызывать, а некий grpc api, который будет по сети ходить в старый сервис. И там постепенно может API поменяться. А если вы сразу сделаете два интерфейса, то развязывание этих зависимостей потребует меньше рефакторинга
VS
Он не будет самодостаточным, если зависит от структур, которые объявлены в другом пакете
RC
обращаются к бизнес логике? тогда при чем тут интерфейсы? мы же не мокаем бизнес логику? ну и бизнес-логика на вход принимает либо свои известные структуры, либо свои же интерфейсы, число которых равно числу бизнес-логик (т.е. 1)
AK
Тот пакет который реализует интерфейс должен зависеть от структур того пакета который интерфейс объявляет, а не наоборот.
VS
В смысле не мокаем бизнес-логику?
Хэндлеры и без тестов обойдутся? :D
Хэндлеры и без тестов обойдутся? :D
VS
Ну вот
Поэтому иногда реализацию логично разместить в том же пакете, что и абстракцию
Поэтому иногда реализацию логично разместить в том же пакете, что и абстракцию
RC
нет не обойдутся (хотя это тоже тот еще вопрос, надо ли такое примитивное тестировать). но и бизнес логику для тестов мокать то зачем?
VS
Чтобы не зависеть от реализации, нет?)
Для чего ещё делают моки
Для чего ещё делают моки
AK
Реализация тут не при чем. У вас есть абстракция (интерфейс), есть данные которые она принимает на вход, есть данные которые возвращает. Данные которыми абстракция оперирует кладутся рядом с абстракцией. Реализация может быть где угодно.
IZ
недавно думал о том же: если у меня есть интерфейс с методом, который принимает дтошку - куда класть интерфейс? и куда класть дтошку? самый простой и, имхо, логичный ответ - положить все туда же, где будет лежать реализация
IZ
есть также вариант класть интерфейсы с дтошками в отдельный пакет вообще, но чем это принципиально отличается от объявления интерфейса в месте реализации?
VS
Есть сущности
Some, Ingredients
Есть интерфейс
SomeMaker { MakeSome(Ingredients) Some }
Ну и есть реализация
Есть grpc, http и mq транспорты до этой логики
Где должны быть объявлены сущности и интерфейс?
Some, Ingredients
Есть интерфейс
SomeMaker { MakeSome(Ingredients) Some }
Ну и есть реализация
Есть grpc, http и mq транспорты до этой логики
Где должны быть объявлены сущности и интерфейс?
AK
Интерфейс здесь зачем? Каждый транспорт может напрямую использовать любые сущности и любые сервисы бизнес логики. Траспорт зависит от бизнес-логики (бизнес-логика ничего не знает о транспорте).
Если хочется транспорт отдельно тестировать, без бизнес логики, тогда вы просто на уровне транспорта создаете интерфейс.
Если нет необходимости тестить транспорт в изоляции, не создаете
Если хочется транспорт отдельно тестировать, без бизнес логики, тогда вы просто на уровне транспорта создаете интерфейс.
Если нет необходимости тестить транспорт в изоляции, не создаете
VS
Чтобы не зависеть от реализации
Очевидно же
Все интерфейсы для этого нужны
Очевидно же
Все интерфейсы для этого нужны