Комментарии 8
Автор открыл для себя «The Clean Architecture». https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
У вас будут имена вроде controller.UserController, в которых вы дублируете имя пакета в имени типа.
Можно ведь controller.Users?
Опять же, ужасные имена вроде users.User и та же проблема с круговыми зависимостями, когда наш accounts.Controller должен взаимодействовать с users.Controller и наоборот.
С чего вдруг один контроллер должен вдруг взаимодействовать с другим? Такого вообще не должно быть.
us := &postgres.UserService{DB: db}
Ой, какая красота! Сиди и думай, что это за UserService такой у постгреса. В документации нет, а он вот он. Ой! postgres для инициализации UserService требует какую-то DB.
interface в Go придуманы для слабаков. Ой! А UserService ещё в myapp есть. Странная декомпозиция…
Выгода от дублирования имени будет в том, что вы изолируете весь HTTP код внутри вашего http пакета:
Выгода?
package http
import (
«net/http»
«github.com/benbjohnson/myapp»
)
Дайте угадаю: в myapp будет import «github.com/benbjohnson/http»
Дайте угадаю: в myapp будет import «github.com/benbjohnson/http»
Нет, myapp это корневой пакет — там только типы и интерфейсы, у которых нет зависимостей.
Если приложение станет реально большим, с большим кол-вом юнит-тестов, то с таким подходом вы огребете с временем компиляции, потому как у вас жесткая связка всех зависимостей.
Используйте интерфейсы для зависимостей как можно чаще и проблем будет меньше.
Используйте интерфейсы для зависимостей как можно чаще и проблем будет меньше.
то с таким подходом вы огребете с временем компиляции, потому как у вас жесткая связка всех зависимостей.
Про какое время компиляции речь? Секунды, минуты, часы? И какое это имеет отношение к тому, что автор комментатория неверно понял предложенную в статье модель?
Используйте интерфейсы для зависимостей как можно чаще и проблем будет меньше.
Автор статьи использует интерфейсы. Совет «как можно чаще» тоже не совсем верен. Интерфейсы абьюзить тоже не нужно без повода.
Секунды и минуты, конечно.
Все внешние зависимости через интерфейсы. Никто не призывает абьюзить. Просто создавать свой пакет для мнимой «изоляции» — это не путь Go. Путь Go — это объявить интерфейс для внешней зависимости и работать с ним, а не с конкретной реализацией. Тогда и тесты легко писать и заменять зависимости легко.
Все внешние зависимости через интерфейсы. Никто не призывает абьюзить. Просто создавать свой пакет для мнимой «изоляции» — это не путь Go. Путь Go — это объявить интерфейс для внешней зависимости и работать с ним, а не с конкретной реализацией. Тогда и тесты легко писать и заменять зависимости легко.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация кода в Go