Гайс, где храните интерфейсы и их реализации? В одном файле,

либо в разных файлах одного пакета, либо реализацию в подпакете?

И про нейминг тоже интересно. UserRepo и UserRepoImpl, либо можно и интерфейс, и реализацию называть UserRepo, но в разных пакетах хранить.

У кого какие предпочтения с вытекающими плюсами и минусами?

Предыдущий язык был c++?

скорее всего, оба будут просто Repo

Интерфейсы там, где их использование/потребитель

Если интерфейсы вообще нужны

Уже год на Го. Просто везде по-разному, вот и интересно мнение

Не совсем понял. То есть, если есть сервис, то интерфейс UserRepo хранить в пакете сервиса?

Смысл в том, что это так не работает. Надо найти где-то пост про концепт. Не спеку, а именно описание, паттерны и примеры

Ну условно у меня CRUD по слоям: контроллер, сервис, репо. В пример, могу привести эту структуру проекта, которая мне нравится: https://github.com/evt/rest-api-example Но там интерфейс сервиса хранится с реализацией в одном пакете, а с репо - в подпакете. Показалось довольно странным

Для меня этот шаблон является бессмысленным набором слов. Смысл в том, что интерфейс описывается там, гле будет использоваться. Что такое "использоваться"? А это там, где у вас будет заявлена переменная типа интерыейса. Яркий пример - пакет fmt. Там Printf проверяет, что если аргумент реализует интерфейс fmt.Stringer, то при форматтере %s будет вызван метод String() переменной, а не попытка самому создать вид.

Реализация же String() вообще гле-то в ваших пакетах в этом примере

если у вас сервис вызывает UserRepo - имеет смысл описать UserRepo именно в сервисе именно как интерфейс

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

ну, если вы любите монолиты - описывайте в ядре, чо

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

У интерфейса ничего не должно быть. Он может быть вообще в вакууме. Ярчайший пример - пакет io

вот-вот, все зависит от того для чего разрабатывается интерфейс, кто будет делать имплементации, не получится ли cyclic import, одна из причин почему я за то чтобы интерфейсы хранились в неком ядре - избежать циклических импортов

Нет, не зависит. Нет никакого разнообразия "всё зависит от" в случае интерфейсов

поясните свою мысль сударь ? :)

хм, да.

Ещё вопрос) А если я захочу использовать UserRepo в другом сервисе, то имеет смысл интерфейс UserRepo хранить в своём пакете (возможно, в пакете имплементации)? Просто, не вижу смысла в пакете другого сервиса объявлять ещё раз UserRepo

"все зависит от того для чего разрабатывается интерфейс" - это бессмысленный набор утверждений. Нет никакого "разрабатывается интерфейс"

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

Пойду запишу цитату мудреца в блокнотик. Это гениально же

ИМХО: интерфейс всегда надо хранить в месте его использования

ну вот, прочтите вопрос от человека: Ещё вопрос) А если я захочу использовать UserRepo в другом сервисе, то имеет смысл интерфейс UserRepo хранить в своём пакете (возможно, в пакете имплементации)? Просто, не вижу смысла в пакете другого сервиса объявлять ещё раз UserRepo Помоему вопрос уместный.

А смысл есть. Это же, по факту, не связанные UserRepo. Вот и не надо на ровном месте coupling повышать

т.е. если есть несколько реализаций этого UserRepo и несколько мест его использования? в идеале надо IUserRepo бить на более мелкие IUserRepoStat IUserRepoCrud IUserRepoAdmin и класть их туда где они применяются но я с таким не сталкивался

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