Почему интерфейсы лучше размещать в месте использования - GoLang best practices

Почему важно описывать интерфейсы не рядом с реализацией, а в месте использования.
----
❤️ Если у вас есть желание поддержать развитие канала:

Секретный телеграм-канал:

Другие проекты:
----

Тайм-коды

00:00 Вступление
00:32 Минималистичность интерфейсов
00:43 Независимость от реализации
00:57 Пример веб-сервиса
01:30 Чем этот сервис плох?
02:42 Как исправить? Интерфейсы по месту использования!
04:52 Уменьшилась связность системы
05:39 Улучшили понятность кода
07:02 Увеличили гибкость системы
08:03 Тестирование и моки
09:06 Минусы подхода
11:58 Утинная типизация - что это?
13:52 Заключение

#golang #ntuzov

[nikolay_tuzov]

❤ Если у вас есть желание поддержать развитие канала:


Секретный телеграм-канал:

[BabyTigerOnTheSunflower]

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

[ТимофейЁлкин-ое]

Про моки очень интересно) И вообще, хотелось бы плейлист про тестирование целый. Успехов автору и развития каналу. Всем Go!

[def-an-fq]

Как всегда отличное видео!) Спасибо за труд!

[СергейМельниченко-уп]

Спасибо, ты лучший из ютуберов по го) по поводу mockery, использую эту библиотеку для юнит тестирования, но к сожалению опыта в тестах пока имею мало. Так что жду более широкого раскрытия данной темы)

[jojomajo]

Вкатываюсь в го после котлин по вашим роликам, все четко и понятно, спасибо)

[ТимофейЁлкин-ое]

Николай, благодарю за науку. Этой информации о том, как использовать "кубики" очень не хватает в курсах. В книгах это может быть, но часто это ещё и в голове нужно уложить. А тут инфа от практикующего кодера из первых уст т.с.

[МишаСелятин-лф]

Спасибо за видео!
Очень доступно и понятно объснил.

[invisibleinvisible]

Спасибо самые лучшие видео по golang ❤❤❤🙏🏻 А будут ли видео про многопоточность в golang, ещё бы очень интересно было послушать про профилирование. Спасибо за видео. Процветания каналу

[dmitriysuhinin]

если мы будем рассматривать handler из реальной жизни, который оркестрирует например базой данный, кешем, дергает какие-то third party библиотеки ну и еще много чего он может делать у себя под капотом. обычно таких вот handler-ов может бы очень много если мы говорим о реальном приложении. так вот в таком случае получается будет очень много вот таких вот мелких интерфейсов, плюс многие из них будут/могут пересекаться своими методами. так же будет большая пачка моков делающих практически одно и тоже(их можно не хранить в самом проекте а генерировать только по надобности до запуска тестов). в общем в реальном приложении получается слишком большой оверхед по тому, сколько надо писать и поддерживать. к этому всему мы подключаем упомянутый факт, что иногда нам надо что-то поменять и тут начнется самое интересно даже при условии что IDE будет в этом помогать. в общем достаточно неоднозначный подход с большим количеством минусов на самом деле.

[Санёчек-ыж]

Отличный ролик! Жду с нетерпением ролик про моки

[ДенисДавыдов-цх]

Свичнулся в Go с другого языка в котором стандартная номинативная типизация и такой подход конечно кажется конечно не говнокодом, но болью. Тут следует смотреть, что мы чаще делаем с кодом. Есть такая аксиома в программировании - "код чаще читается, чем пишется". С этой позиции конечно с кодом становится работать куда менее удобно, придется 100500 файлов облазить, о чем сказано в видео. Этот недостаток лично для меня нивелирует преимущества от разделения интерфейсов.

[eleimt]

Будет видео о gRPC? Не соображу как в проекте добавить клиент для gRPC. Спасибо за труд и стримы.

[parvizyuldashev]

Классное объяснение. Пошел внедрять в проекты! Ждем ролик по мокам)

[БанинЕгор]

Перемещение интерфейса к месту использования — это инверсия зависимости (soliD). Утиная типизация не убирает эту зависимость, и код репозитория должен соответствовать интерфейсу объявленному в пакете хэндлеров. Количество зависимостей (зацепление, а не связность) не уменьшилось, изменилось только направление зависимости.

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

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

[antosha]

Спасибо за видео. Да, подобный подход очень каноничный для го. Но это выглядит как противопоставление чистой архитектуре со своими плюсами и минусами

[vladimireliseev]

Благодарю за видео!

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

[dmitryibaranov]

Что выходит. Если в 2 разных местах надо получать пользователя, то будут описаны 2 интерфейса, которые полностью совпадают, но описаны в разных местах ? Таким образом получается некое нарушение dry ?

[НиколаевВалентин-рц]

Добрый день, спасибо за видео. На практике столкнулись с тем, что такой подход не удобен в случае, если необходимо вернуть интерфейс.
Например, есть некое хранилище балансов. Баланс реализован сложно на основе event sourcing. Хранилище дальше инъецируется в другие структуры.
В этом случае, если использовать такой подход, то это значительно усложняет тестирование, потому что возвращается именно баланс с конкретной реализацией, который совсем не просто привести в нужное состояние.
Если же сделать хранилище с возвращаемым интерфейсом, то утиная типизация перестаёт работать. Go не может понять, что передаваемый извне интерфейс, пусть и совпадающий по сигнатуре, соответствует локальному интерфейсу баланса.
В итоге, для таких случаев приходится делать один внешний общий интерфейс балансов, который уже используется везде.

[UAStriker]

Спасибо за ваш труд. Жду ролик про моки