Библиотека Go для собеса | вопросы с собеседований

💬 В каких случаях следует использовать интерфейсы в Go?



🤔 Это довольно обширная и сложная тема, но если отвечать кратко, то интерфейсы в Go следует создавать в нескольких сценариях:



1️⃣ Общее поведение — использование интерфейсов, когда несколько типов реализуют общее поведение. Тогда можно заключить это поведение внутрь какого-то интерфейса.



В стандартной библиотеке много таких примеров. Например, сортировка какой-либо коллекции может быть разложена на три действия:



✹ Получение данных о количестве элементов в коллекции.

✹ Сообщение о том, должен ли один элемент быть размещен перед другим.

✹ Перестановка двух элементов.



2️⃣ Снижение связанности (decoupling) — отделение кода от его реализации. Если мы полагаемся на абстракцию вместо конкретной реализации, сама реализация может быть заменена на другую без необходимости менять код. Это и есть принцип подстановки Лисков. Одно из преимуществ снижения связанности может относиться к юнит-тестам.



3️⃣ Ограничение поведения. Представим, что мы реализуем конфигурационный пакет для работы с динамической конфигурацией. Мы создаем специальный контейнер для конфигураций int с помощью структуры IntConfig, в которой определены два метода: Get и Set. Вот как будет выглядеть такой код:

type IntConfig struct {

    // ... 

}

func (c *IntConfig) Get() int {

    // Получить конфигурацию

}

func (c *IntConfig) Set(value int) {

    // Обновить конфигурацию

}

✹ Теперь предположим, что мы получили IntConfig, который содержит в себе определенную конфигурацию, например какое-то пороговое значение. Но в нашем коде нас интересует только получение значения этой конфигурации, и мы хотим предотвратить его обновление. Как мы можем обеспечить, чтобы семантически эта конфигурация была доступна только для чтения, если мы не хотим изменять пакет конфигурации?



✹ Cоздав абстракцию, которая ограничивает поведение только получением значения конфигурации:

type intConfigGetter interface {

    Get() int 

}

Тогда в коде можно указать только intConfigGetter вместо конкретной реализации:

type Foo struct {

    threshold intConfigGetter

}



func NewFoo(threshold intConfigGetter) Foo {

    return Foo{threshold: threshold}

}



func (f Foo) Bar() {

    threshold := f.threshold.Get()

    // ... 

}

✹ В примере геттер конфигурации внедряется в фабричный метод NewFoo. Он не влияет на потребителя этой функции, поскольку он по-прежнему может передавать структуру IntConfig по мере реализации intConfigGetter. Затем в методе Bar можно только прочитать конфигурацию, но не изменить ее. Поэтому мы также можем использовать интерфейсы, чтобы ограничить тип определенным поведением, например, если нужно соблюсти семантику.