Интерфейсы в Go

Реализация без объявления

Условие одно: у типа есть все методы интерфейса с точно такими же сигнатурами. Никакого ключевого слова implements, никакой связи между пакетами. Тип из библиотеки, написанной пять лет назад, спокойно удовлетворяет интерфейсу, который ты объявил сегодня утром.

Отсюда главное архитектурное следствие: направление зависимости переворачивается. Интерфейс принадлежит не тому, кто его реализует, а тому, кто его использует. Пакет-потребитель объявляет, что ему нужно, и не зависит от конкретных реализаций вообще.

Практический эффект виден в тестах. Чтобы подменить хранилище заглушкой, не нужно ни менять пакет хранилища, ни договариваться с его автором: объявляешь у себя интерфейс из двух нужных методов и пишешь заглушку на пятнадцать строк.

// Обратная сторона - опечатку компилятор поймает не там, где ты её сделал, а там, где тип попытались подставить. Лечится строчкой var _ Iface = (*MyType)(nil) рядом с объявлением типа: она ничего не создаёт, но проверяет соответствие прямо в родном файле.

Интерфейс - это пара из двух слов

Внутри переменная интерфейсного типа - пара: указатель на информацию о динамическом типе и указатель на само значение. Проверяется размером: unsafe.Sizeof для any возвращает 16 байт при размере обычного указателя 8. Ровно два машинных слова.

Из этой пары следует всё остальное поведение. Интерфейс равен nil, только когда пусты оба слова. Если тип записан, а значение нулевое - интерфейс уже не nil, и это порождает знаменитую ловушку typed nil, которой посвящена отдельная подтема.

Оттуда же ограничение на сравнение. Интерфейсы сравниваются, если совпали и динамический тип, и значение: два any с числом 1 равны, проверено. А вот два any со слайсами внутри дают панику runtime error: comparing uncomparable type []int, потому что слайсы сравнивать нельзя в принципе. Компилятор это не ловит - падает во время работы.

// Практический вывод: не используй интерфейсные значения как ключи мапы, если не уверен в динамическом типе. Один слайс внутри - и запись в мапу уронит процесс на данных, которых не было в тестах.

динамический тип

реальный тип значения, лежащего внутри интерфейсной переменной

Чем уже, тем полезнее

io.Reader состоит из одного метода Read. io.Writer - из одного Write. Это не аскетизм ради красоты: чем меньше методов, тем больше типов подходят и тем проще написать свой. Файл, сетевое соединение, буфер в памяти, архиватор, счётчик байтов - все они Reader, и любую пару можно соединить.

Обратный пример знаком всем: интерфейс Repository с двадцатью методами. Реализовать его заглушкой в тесте - полдня; добавить метод - сломать всех реализующих. Такой интерфейс не абстракция, а копия конкретного типа с лишним шагом.

Правило, вытекающее из неявной реализации: объявляй интерфейс у потребителя и включай в него ровно то, что этот потребитель вызывает. Если сервису от хранилища нужны GetUser и SaveUser, его интерфейс состоит из двух методов, а не из всех, что умеет база.

// И не заводи интерфейс на всякий случай, когда реализация одна и другой не предвидится. Пустая абстракция усложняет чтение и ничего не даёт: в Go добавить интерфейс задним числом дёшево именно потому, что реализующему типу для этого ничего делать не нужно.

// плохо: интерфейс у поставщика, двадцать методов
// хорошо: у потребителя, ровно то, что он зовёт
type userStore interface {
    GetUser(ctx context.Context, id int64) (*User, error)
    SaveUser(ctx context.Context, u *User) error
}

func NewService(s userStore) *Service { return &Service{store: s} }

Как отвечать: «Как тип реализует интерфейс и где его объявлять?»

Реализация в Go неявная: достаточно, чтобы у типа были все методы интерфейса с теми же сигнатурами. Никакого implements писать не нужно, и связи между пакетами не возникает - тип из чужой библиотеки удовлетворяет интерфейсу, о котором ничего не знает. Из этого следует главное правило: интерфейс объявляют у потребителя, а не у поставщика. Пакет говорит, что ему нужно, и не зависит от конкретных реализаций, а подменить их в тесте можно, не трогая чужой код. И делаю я такие интерфейсы максимально узкими: если сервису от хранилища нужны два метода, в интерфейсе два метода, а не двадцать. Образец тут - io.Reader и io.Writer по одному методу, поэтому им удовлетворяет буквально всё и любые два куска можно соединить. Минус неявной реализации один: опечатка в сигнатуре всплывает не в файле типа, а в месте подстановки. Лечу строчкой var _ Iface = (*MyType)(nil) рядом с объявлением - она ловит несоответствие прямо там, где тип живёт.

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

На чём валят

• −Объявляют интерфейс рядом с реализацией и тянут зависимость не в ту сторону.
• −Пишут интерфейс на двадцать методов и потом не могут написать заглушку для теста.
• −Заводят интерфейс при единственной реализации, которая и не собиралась меняться.
• −Забывают, что интерфейс - это пара из двух слов, и удивляются typed nil.
• −Кладут интерфейсные значения в ключи мапы и ловят панику на несравнимом типе.
• −Не ставят проверку var _ I = (*T)(nil) и ищут опечатку в сигнатуре по чужим пакетам.