Приведи 2 примера, когда бы ты использовал Interface в Go

Роль интерфейсов в Go: два практических примера

В Go интерфейсы — это один из краеугольных камней системы типов, реализующий полиморфизм через утиную типизацию (duck typing). Они определяют не конкретную реализацию, а поведение (набор методов), которое должен реализовать тип. Вот два характерных примера, где интерфейсы становятся незаменимыми.

---

Пример 1: Абстракция над хранилищем данных (Storage Layer)

Частая задача — работать с различными хранилищами (база данных, файловая система, in-memory кэш), не привязывая бизнес-логику к конкретной реализации. Интерфейс позволяет определить общий контракт.

// Объявляем интерфейс, описывающий поведение "хранилища пользователей"
type UserRepository interface {
    GetByID(id int) (*User, error)
    Save(user *User) error
    Delete(id int) error
}

// Структура, представляющая доменную сущность
type User struct {
    ID   int
    Name string
    Email string
}

// Реализация интерфейса для PostgreSQL
type PostgresUserRepository struct {
    db *sql.DB
}

func (r *PostgresUserRepository) GetByID(id int) (*User, error) {
    // Реализация запроса к PostgreSQL
    // ...
}

func (r *PostgresUserRepository) Save(user *User) error {
    // Реализация сохранения в PostgreSQL
    // ...
}

func (r *PostgresUserRepository) Delete(id int) error {
    // Реализация удаления из PostgreSQL
    // ...
}

// Реализация интерфейса для in-memory хранилища (например, для тестов)
type InMemoryUserRepository struct {
    users map[int]*User
    mu    sync.RWMutex
}

func (r *InMemoryUserRepository) GetByID(id int) (*User, error) {
    r.mu.RLock()
    defer r.mu.RUnlock()
    user, exists := r.users[id]
    if !exists {
        return nil, fmt.Errorf("user not found")
    }
    return user, nil
}
// ... (реализация остальных методов)

// Сервис бизнес-логики, который зависит от АБСТРАКЦИИ (интерфейса),
// а не от конкретной реализации
type UserService struct {
    repo UserRepository // Здесь может быть ЛЮБОЙ тип, реализующий UserRepository
}

func (s *UserService) GetUserProfile(id int) (*UserProfile, error) {
    user, err := s.repo.GetByID(id) // Вызов метода через интерфейс
    if err != nil {
        return nil, err
    }
    // ... бизнес-логика
    return &UserProfile{Name: user.Name}, nil
}

Преимущества такого подхода:

• Тестируемость: Для юнит-тестов UserService легко подставить мок (InMemoryUserRepository) вместо реальной базы данных.
• Гибкость архитектуры: Переход с PostgreSQL на MongoDB потребует лишь написания новой реализации UserRepository и изменения инъекции зависимости, а код UserService останется неизменным.
• Соблюдение DIP (Принцип инверсии зависимостей): Модули верхнего уровня (сервисы) не зависят от модулей нижнего уровня (конкретные репозитории), оба зависят от абстракции.

---

Пример 2: Плагинная архитектура или обработка разных типов входных данных

Интерфейсы идеально подходят для создания расширяемых систем, где набор обрабатываемых типов может расти.

// Интерфейс, определяющий контракт для "декодера", способного
// преобразовать сырые байты в нашу внутреннюю структуру данных.
type Decoder interface {
    Decode(data []byte) (*Payload, error)
}

// Структура, в которую декодируются данные
type Payload struct {
    Data map[string]interface{}
}

// Реализация декодера для JSON
type JSONDecoder struct{}

func (d JSONDecoder) Decode(data []byte) (*Payload, error) {
    var p Payload
    if err := json.Unmarshal(data, &p.Data); err != nil {
        return nil, err
    }
    return &p, nil
}

// Реализация декодера для YAML
type YAMLDecoder struct{}

func (d YAMLDecoder) Decode(data []byte) (*Payload, error) {
    var p Payload
    p.Data = make(map[string]interface{})
    if err := yaml.Unmarshal(data, &p.Data); err != nil {
        return nil, err
    }
    return &p, nil
}

// Процессор, который может работать с ЛЮБЫМ декодером
type DataProcessor struct {
    decoder Decoder
}

func (p *DataProcessor) Process(rawData []byte) error {
    payload, err := p.decoder.Decode(rawData) // Ключевой вызов через интерфейс
    if err != nil {
        return fmt.Errorf("decode failed: %w", err)
    }

    // Единая логика обработки Payload, независимо от формата исходных данных
    for key, value := range payload.Data {
        fmt.Printf("Processing key: %s, value: %v\n", key, value)
    }
    return nil
}

// Использование: система легко расширяется новыми декодерами
func main() {
    jsonData := []byte(`{"name": "Alice", "age": 30}`)
    yamlData := []byte(`name: Bob\nage: 25`)

    // Обработка JSON
    jsonProcessor := &DataProcessor{decoder: JSONDecoder{}}
    _ = jsonProcessor.Process(jsonData)

    // Обработка YAML
    yamlProcessor := &DataProcessor{decoder: YAMLDecoder{}}
    _ = yamlProcessor.Process(yamlData)

    // Добавление поддержки нового формата (например, TOML) потребует
    // ТОЛЬКО создания нового типа, реализующего интерфейс Decoder.
}

Преимущества такого подхода:

• Расширяемость (Open/Closed Principle): Чтобы добавить поддержку нового формата данных (например, XML или CSV), не нужно изменять код DataProcessor. Достаточно создать новый тип, реализующий интерфейс Decoder.
• Унификация обработки: Вся последующая бизнес-логика в Process написана единообразно для Payload, ей безразлично, как этот Payload был получен.
• Чистота кода: Отсутствуют громоздкие switch или цепочки if-else, определяющие тип данных.

---

Заключение

Эти примеры иллюстрируют две фундаментальные парадигмы использования интерфейсов в Go:

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

Ключевая сила интерфейсов Go — в их неявной реализации. Тип автоматически удовлетворяет интерфейсу просто наличием требуемых методов. Это позволяет создавать малоразмерные, целевые интерфейсы (часто из одного метода, как io.Reader), и комбинировать их, что является основой идиоматичного дизайна в Go.