Всем доброго времени суток! Мне стало интересно, а как правильно

оформлять комментарии к коду в случае если есть файл в котором интерфейс + его реализация. Вот пример того о чем я говорю:


# main.go

type Servicer interface {
Foo(a string) error
Bar(b int) error
}


type Service struct {}
func (s *Service) Foo(a string) error {…}
func (s *Service) Bar(b int) error {…}


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

неправильно свзывать интерфейс с реализацией, для начала

в плане моего понимания или кода выше?) Ну вот допустим интерфейс описывает поведение какого-то круда где будет куча бизнес логики (подразумевается что это находится в слое service из примеров чистая архитектура/DDD) Интерфейс с реализациями же всегда будет связан как не крути. А вот куда комменты в этом случае запихнуть я не знаю)

а зачем вам нужен отдельный интерфейс круда? что бы было?

в случае с интерфейсами этот код легко тестировать, потому что любой метод можно мокнуть

Ну вот и описывайте интерфейсом используемую часть круда в том месте, где он используется У вас в голове все еще парадигма других языков программирования, что есть абстрактный класс- интерфейс, а есть его реализация, но в го нет абстрактных классов, а интерфейс это просто контракт

Интерфейс должен лежать там где его используешь. Используешь в нескольких местах пишешь несколько интерфейсов(всё равно с течением времени разойдутся) Если интерфейс прям во многих местах используется можно ему отдельный пакет дать...

А где посоветуете про это почитать?

"в го нет абстрактных классов" ну почему ж, автогенеренный мок для интерфейса, где каждый метод вызывает panic("implement me") - ведь почти тоже самое, что абстрактный класс по поведению. ну да, классов и иерархии в принципе нет.

нет, не то же самое,это называется писать джавовый код на го🤣

https://golang.org/doc/effective_go

я вот не заметил по вопросу документирования интерфейса и реализации, что это попахивает джавой 🙂

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

если представить типичную (в моем понимании) реализацию веб-сервера с простым крудом, это будет выглядеть примерно вот так: Слой #0 - модели (они же выступают доменной зоной) Слой #1 - интерфейс репозитория (взаимодействует с моделями) Слой #2 - интерфейс сервиса с бизнес логикой который взаимодействует с моделями и интерфейсом репозитория Слой #3 - хэндлеры используемые веб-фреймворком которые дергают интерфейс сервиса и только. Это все достаточно удобно по частям покрывать юнит тестами и в принципе работать с этим Но получается с вашим подходом я должен определять в хэндлерах интерфейс сервиса который отвечает за круд? Тогда это будет какая-то путаница, по крайней мере сейчас в моей голове) А есть примеры кода где можно посмотреть на такой подход? Потому что все что я гуглил про интерфейсы сводилось к описанию слоев которое я прикрепил выше

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

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

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

Вы написали только горизонтальные слои. По моему небольшому опыту, если горизонтальные слои разделять интерфесами(а других не вводить), то современем они обрастают гиганскими интерфейсами, которые устанешь мокать и которые приводят к сильной связанности. Используйте "ещё вертикальные" слои внутри горизонтальных. Т.е. нужен хендлеру из всего CRUD только метод R, то пусть и интерфейс у него будет только с одним R. А уже реализация может реализовывать несколько интерфейсов без проблем...

Я тоже что то сходу не нашел все те статьи, что в свое время читал при входе в го, все потонуло в шлаке про ca и ddd...

Проблема не в примерах а в понимании концепций слабой связаности