Погружение в интерфейсы Go

[6ap]

Шикарная статья! Наверное, из скользкого не затронут только указатель на интерфейс, хотя на практике не особо-то и нужно. Может Вы так же «разберётесь» и с шаблонами?

[alivewel]

Благодарю! Это хорошая идея для новой статьи.

[ilving]

Создадим интерфейс UserProvider, в котором будет метод User()

И всё равно у пакета осталась связка со storage/users - хотя бы потому, что там описан возвращаемый тип данных.

Допустим, мы хотим передать вместо сущности Postgres сущность Redis. Чтобы соответствовать данному интерфейсу, нам придется реализовать все его методы, даже если они не используются.

Хм... storage/users/postgres, storage/users/redis... на мой вкус так и задумывалось, что все эти сущности реализуют интерфейс storage/users.Storage. Или, как минимум, в storage/users должно быть два интерфейса - Data и, например, Cache. Тогда users/postgres и users/mysql реализуют интерфейс Data, а users/redis - интерфейс Cache. А иначе может быть как-то ни разу не очевидно зачем нужна такая вот странная структура

• users.go: Файл с реализацией интерфейсов для работы с пользователями.

Разрешите доколебаться: это не реализация, это описание

[alivewel]

Согласен с замечанием, в идеале структуру Users можно вынести в отдельный пакет для уменьшения связности. Тут упрощённый пример.

[evgeniy_kudinov]

Ну наконец в одном месте собрано все что надо для интефейсов на го.
Уточнение: интерфейсы в Go это структурная типизация, то же самое что и утиная для языков c динамической типизацией.
Наверное в описании структуры проекта лучше заменить "Папка" на "Пакет"
Например:

users/: Пакет для управления пользователями.

[alivewel]

Спасибо за замечание! я внесу корректировку в этом месте.

[thmn8]

Классная статья. Доступно написано!