Какие плюсы и минусы объявления интерфейса рядом со структурой-реализацией?

Объявление интерфейса в том же пакете, что и его основная реализация — это подход, который часто называют "классическим" или "producer-side" (на стороне производителя). Он распространен в языках вроде Java или C#.

Преимущества (Плюсы):

• Явный контракт пакета: Пакет четко заявляет: "Вот абстракция, которую я предоставляю, и вот её основная реализация". Это служит хорошей документацией и точкой входа для пользователей пакета.
• Централизация: Существует один канонический интерфейс для определенной функциональности (например, io.Reader). Это предотвращает дублирование и создает единый стандарт для взаимодействия.
• Простота для автора пакета: Автору легко определить полный контракт своего типа данных в одном месте.

Недостатки (Минусы):

• Высокая связанность (High Coupling): Потребитель (consumer) вынужден импортировать весь пакет-производитель (producer) только для того, чтобы использовать его интерфейс. Это создает прямую зависимость.
• "Раздутые" интерфейсы (Fat Interfaces): Производитель склонен включать в интерфейс все публичные методы своей структуры. Потребителю же может быть нужна только малая часть этих методов, что нарушает Принцип разделения интерфейса.
• Навязывание абстракции: Производитель диктует, какой должна быть абстракция. Это ограничивает гибкость потребителя, который не может легко подменить реализацию на другую, если та не была изначально спроектирована под этот конкретный интерфейс.

Когда такой подход оправдан?

Несмотря на то, что в Go чаще предпочитают интерфейсы на стороне потребителя, этот подход незаменим в следующих случаях:

1. Стандартные интерфейсы языка и фреймворков: Лучшие примеры — io.Reader, io.Writer, http.Handler. Они определяют общепринятые контракты, которые стали стандартом для всей экосистемы Go.
2. Публичные API библиотек: Когда библиотека предоставляет четко определенный набор функциональности, экспорт интерфейса помогает пользователям создавать свои реализации или моки.
3. Архитектура плагинов: Когда система определяет стандартный интерфейс для плагинов, которые должны быть реализованы сторонними разработчиками.

Пример (пакет userstorage):

// Пакет userstorage определяет и интерфейс, и его реализацию.
package userstorage

// User — это модель данных.
type User struct {
    ID   int
    Name string
}

// 1. Интерфейс определяется на стороне производителя.
// Он описывает полный контракт для работы с хранилищем пользователей.
type Storage interface {
    GetUser(id int) (*User, error)
    SaveUser(user *User) error
}

// 2. Рядом находится конкретная реализация.
type DBStorage struct{
    // ... db connection
}

// Убедимся во время компиляции, что DBStorage реализует Storage.
var _ Storage = (*DBStorage)(nil)

func (s *DBStorage) GetUser(id int) (*User, error) {
    // ... реализация получения из БД
    return &User{ID: id, Name: "John Doe"}, nil
}

func (s *DBStorage) SaveUser(user *User) error {
    // ... реализация сохранения в БД
    return nil
}

// NewDBStorage - конструктор для нашей реализации.
func NewDBStorage() *DBStorage {
    return &DBStorage{}
}