Интерфейсы: контракты поведения

В прошлом уроке мы научились проносить отмену и дедлайны по цепочке вызовов — и дважды обещали разобраться с одной фразой: context.Context — интерфейс с четырьмя методами. Что такое интерфейс, почему корень дерева и его дети прячутся под одним контрактом и почему тип удовлетворяет этому контракту, не объявляя об этом, — тема сегодняшняя. Это последний кирпич в фундаменте: после него фраза «интерфейс с четырьмя методами» перестанет быть заклинанием.

Интерфейс в Go — это набор методов. Не данные, не поведение по умолчанию, не иерархия классов — просто список сигнатур: «кто умеет вот это — годится». Такой список называют контрактом поведения: он описывает, что тип умеет делать, а не чем он является. fmt.Stringer говорит «умею печатать себя строкой»; io.Reader — «умею отдавать байты»; context.Context — «умею сообщать дедлайн, отмену, причину и значения». Конкретный тип попадает под контракт одним способом — реализуя все методы из списка. Как именно он их реализует и что у него внутри — контракту безразлично.

План урока: неявная реализация и контраст с Java, разбор type Stringer interface на живом примере, маленькие интерфейсы io.Reader и io.Writer как каркас стандартной библиотеки, полиморфизм через срез интерфейсов и параметры-интерфейсы, compile-проверка var _ Interface = (*T)(nil), честная история про nil-интерфейс и nil внутри, и свой тип, который становится полноценным io.Reader. Интерфейсы — сильная сторона песочницы: почти все интерактивы дают одинаковый ответ в обоих движках; где есть исключения — честно отметим.

Если вы приходите из Java или C#, самое странное в Go звучит так: тип не объявляет, чей контракт он выполняет. В Java пишут class Cat implements Stringer — компилятор проверяет заявление в заголовке, и без него тип не пройдёт там, где ждут интерфейс. В Go заявления нет: вы просто пишете метод String() string — и Cat уже можно присвоить переменной типа Stringer. Компилятор сверяет наборы методов: у контракта один список, у типа — свой; список типа покрывает список контракта — тип готов. Эту модель называют структурной типизацией, а в народе — утиной: «если он ходит как утка и крякает как утка — это утка». Родословная не спрашивается.

По запросу interface golang поисковая выдача ведёт на тур Go (go.dev/tour) и Effective Go, раздел Interfaces, — там канон сформулирован одной фразой: интерфейсы задают контракты, которые типы выполняют, не объявляя об этом. Что за этим стоит на практике? Свобода чужого кода. Типы из чужих пакетов — из стандартной библиотеки, из библиотек в Интернете — вы не редактируете: исходники закрыты для правок, а implements в Java надо дописать именно в исходник типа (или городить адаптер). В Go же контракт может появиться после типов: вы объявляете свой интерфейс с двумя методами — и внезапно оказывается, что под него уже подходят три типа из библиотек, о которых авторы интерфейса никогда не слышали. Контракт в Go — это заявление потребителя («дайте мне вот такое поведение»), а не заявление типа («я такой-то»).

Отсюда и разделение, которое вы уже чувствовали по всему курсу: sync.Mutex — конкретный тип со своими методами Lock и Unlock, у него есть внутренности (состояние, очередь ждущих); io.Reader — интерфейс, у него внутренних дел нет вообще, только сигнатуры. Конкретный тип можно инстанцировать и потрогать поля; интерфейс можно только требовать и вызывать. Вся стандартная библиотека построена на простом правиле: функции принимают интерфейсы (минимально узкие), а возвращают конкретные типы.

Разберём контракт вживую. Объявление интерфейса похоже на объявление структуры, только внутри — методы без тел:

type Stringer interface { String() string }

Читается так: «любой тип, у которого есть метод String(), возвращающий string, — это Stringer». В стандартной библиотеке живёт точно такой же контракт — fmt.Stringer из пакета fmt, — и у него особая честь: fmt сам его вызывает. Когда fmt.Println, fmt.Printf с глаголом %v и почти все печатные функции пакета получают значение, они проверяют: реализует ли оно String() string? Реализует — печатают результат этого метода вместо внутренностей. Так fmt печатает время как «2006-01-02», а не структуру из полей: time.Time просто реализует String.

Строительным блоком здесь служат методы, которые вы писали в основном курсе (урок о методах структур): приёмник-значение, приёмник-указатель, вызов через точку. Методы — единственное, что делает тип интерфейсом: нет методов — нет контракта; есть метод String() string — есть Stringer. Одно правило о приёмниках стоит освежить сразу: набор методов значения и набор методов указателя различаются. Метод с приёмником-значением есть и у значения, и у указателя (указатель всегда умеет разыменоваться); метод с приёмником-указателем есть только у указателя. Значит, Cat с String() на значении удовлетворяет Stringer и значением, и указателем, а тот же контракт на *Cat — только указателем. В ранимых блоках урока мы держим приёмники-значения — и контракт, и печать ведут себя одинаково предсказуемо.

Stringer — пример важнейшего вкусового канона Go: интерфейсы должны быть маленькими. Чем меньше методов в контракте, тем больше типов ему удовлетворяют — и тем шире применение кода, который контракт принимает. Один метод — идеал: Stringer, io.Reader, io.Writer, fmt.GoStringer. Есть и легендарные двух-трёхметодные (io.ReadWriteCloser, http.Handler), но правило вкуса одно: объявляйте интерфейс тогда, когда вам нужно поведение, а не «всё подряд», и не раздувайте список «на будущее» — реализаций станет меньше, а пользы не прибавится. Каноническая цитата из доков Rob Pike: «чем больше интерфейс, тем слабее типизация» (The bigger the interface, the weaker the abstraction).

Главный контракт всего серверного Go — io.Reader. Вот его сигнатура целиком:

Read(p []byte) (n int, err error)

Три части: p — буфер, который даёт вам потребитель («вот память, заполняй»); n — сколько байт вы реально записали (может быть меньше длины буфера — и это норма, а не ошибка); err — ошибка, и особая её форма — io.EOF: «данные кончились». EOF — не катастрофа, а штатный сигнал конца потока, и весь код чтения в экосистеме крутится вокруг пары «прочитал n — проверь err». io.Writer — зеркальный контракт: Write(p []byte) (n int, err error) — «вот байты, возьми их, сколько взял — скажи». Файловая система, сеть, буферы в памяти, HTTP-тела, шифрование, сжатие — всё говорит на этих двух сигнатурах. Поэтому fmt.Fprintf(w io.Writer, ...) печатает хоть в файл, хоть в сеть, хоть в strings.Builder: функция не знает, куда она пишет, — она знает только, что туда можно Write. Это и есть контракт поведения в действии: потребитель объявляет минимальное поведение, а поставщиков — сотни.

Теперь плоды. Полиморфизм — разное поведение у значений под одним контрактом — в Go делается без наследования и без виртуальных таблиц на виду: значение интерфейса хранит пару «динамический тип + значение», и вызов метода идёт к динамическому типу. Практическая фигура номер один — срез интерфейсов: []fmt.Stringer или ваш собственный []Speaker. В одной корзине лежат значения разных конкретных типов, и цикл for зовёт один и тот же метод — каждый раз свой. Добавить новый вид «говорящего» — значит написать новый тип с нужным методом; цикл и срез не меняются. Это расширение без правок старого кода — то самое, ради чего в других языках строят иерархии классов.

Фигура номер два — интерфейс как параметр функции. Функция func hello(g Greetable) string принимает любой тип с методом Greet() string: и кота, и человека, и робота. Внутри функции доступно только поведение из контракта — вызвать Greet, и всё; поля name у Greetable не существует, ведь у одного динамического типа оно есть, у другого — нет. Это ограничение — сила: функция, написанная против маленького контракта, работает сегодня с котом, завтра с HTTP-запросом, послезавтра с фейком из тестов.

Обратная сторона той же монеты: в возвращаемых значениях идиома наоборот — возвращайте конкретные типы, а не интерфейсы. Конкретный тип несёт вызывающему все свои методы и поля; интерфейс отрезал бы всё, кроме контракта, — без пользы, ведь вызывающий знает, что именно вернул его код. Правило доков: «будьте консервативны в том, что принимаете, либеральны в том, что возвращаете» — тут оно перевёрнуто относительно многих языков и проверено десятилетиями.

Неявная реализация имеет цену: в Java «интересно, реализует ли Cat интерфейс» видно по заголовку класса; в Go надо смотреть наборы методов. Когда тип далеко (в другом пакете) или контракт менялся, у Go есть идиома compile-проверки — заявление, которое живёт на уровне пакета и не даёт контракту тихо расползтись:

var _ fmt.Stringer = Robot{}

Читается: «переменная-пустышка _ типа fmt.Stringer получает значение Robot». Компилятор обязан проверить присваивание: если набор методов Robot не покрывает fmt.Stringer — программа не соберётся, прямо здесь, а не в тесте на проде. Пустой идентификатор _ выбрасывает значение, ничего в памяти не живёт, строчки кода исполнения не занимает — чистое заявление контракта.

В исходниках стандартной библиотеки чаще встречается форма с указателем:

var _ fmt.Stringer = (*Robot)(nil)

Зачем через (*T)(nil)? Она проверяет указательный набор методов: тип с приёмниками-указателями обязан покрыть контракт указателем, и конверсия (*Robot)(nil) — создание nil-указателя Robot без единого выделения памяти. Если String написан на значении, а контракт требуют у *Robot — компилятор ругнётся немедленно. Обе формы — норма продакшена: в пакетах stdlib такие строки стоят рядом с объявлением типа как страховка. И одна честная нота про песочницу: форму (*Robot)(nil) резервный движок не парсит (основной — компилирует), поэтому в живом блоке ниже — форма со значением, а указательная — в статичном блоке здесь.

Раз ловушка Typed-nil всплыла — аккуратно разложим nil-словарь интерфейсов, без которых в Go не прожить. Нулевое значение интерфейса — nil, и это пара из двух nil: ни динамического типа, ни значения. var s fmt.Stringer — именно она. Проверка s == nil возвращает true, вызов метода на такой переменной роняет программу с паникой «nil pointer dereference» — контракту нечего вызывать, динамического типа нет. Правило простое: прежде чем звать метод, убедитесь, что переменной что-то присвоено — или проверьте на nil, если она приходит извне.

Как только интерфейсу присвоили значение — любая nil-пара исчезает: присваивание s = Cat{} кладёт пару (Cat, значение), и s == nil уже false, даже если сам Cat внутри нулевой. Отсюда правило для авторов функций, возвращающих интерфейсы (чаще всего — error, который тоже интерфейс из одного метода Error() string): возвращайте голый nil как nil. Строчка return nil кладёт пару (nil, nil) — вызывающий увидит err == nil и спокойно пойдёт дальше. А вот var e *MyErr = nil; return e кладёт пару (*MyErr, nil) — err не равен nil, хотя внутри ничего нет, и проверка вызывающего обманута. Это и есть ловушка Typed-nil целиком; сегодня достаточно узнавать её в лицо и держать привычку return nil.

И симметричная деталь, которую стоит знать базово: интерфейс с заполненным типом, но nil-значением внутри — не то же самое, что nil-интерфейс, и методы на нём иногда вызываются спокойно (метод с приёмником-указателем, который не трогает поля, отработает), а иногда паникуют (разыменование nil внутри метода). Не полагайтесь на «повезёт»: пустые указатели под контрактом — ошибка проектирования, а не фича. В одиннадцатом и двенадцатом уроках вернёмся к этому сюжету с инструментами — пустым интерфейсом any и type assertion-ом, которые позволяют отличать динамические типы честно.

Финальный номер — собрать собственный io.Reader. Зачем? Затем, что io.Reader — это разъём: любой тип с методом Read(p []byte) (int, error) втыкается в любую функцию, которая читает. Источники — файлы, сеть, строки — вам знакомы; самое вкусное начинается, когда контракт используется для декораторов: тип, который сам является Reader-ом и внутри себя держит другой Reader, читая через него и преобразуя данные. Так устроены bufio.Reader, gzip.Reader, crypto-обёртки — всё держится на том, что внешняя обёртка и внутренний источник говорят на одной сигнатуре.

Соберём shoutReader: структура с полем src io.Reader (уже контракт! — источник может быть чем угодно), метод Read читает порцию из источника, поднимает строчные латинские буквы в верхний регистр и отдаёт наружу с результатом источника — включая io.EOF в конце. Источник возьмём strings.NewReader — Reader из строки, он же удобен в тестах. В main переменная var r io.Reader принимает нашего шаутера — и дальше с ним можно делать всё, что делается с любым Reader: цикл чтения до io.EOF, передача в io.Copy, в http-ответ. Программа не знает, что источник — самодельный: контракт обеспечил совместимость. Это и есть «методы делают тип интерфейсом» на максимальной громкости: один метод Read — и ваш тип втянут в экосистему из сотен функций.

Оглянемся на четыре урока подряд: каналы и горутины научили программы общаться, мьютексы — не мешать друг другу, контекст — вовремя останавливаться, а сегодня интерфейсы научили код договариваться: функции объявляют минимальное поведение, типы выполняют контракты неявно, и всё это собирается в срезы, параметры и разъёмы вроде io.Reader. У вас есть и страховка — var _ Interface = (*T)(nil) — и фильтр для ловушки typed-nil. Весь курс с этого места разворачивается от механики к стилю.

Следующий шаг — «Полиморфизм и пустой интерфейс»: одиннадцатый урок заберётся внутрь пары «тип + значение», познакомит с any — контрактом без единого метода, которому удовлетворяет всё, — и покажет, где гибкость становится ценой: type safety, срезы интерфейсов в больших программах и границы применимости. После него ловушка Typed-nil из сегодняшнего quiz-а получит полное вооружение — type assertion и переключение по типу, это территория двенадцатого урока. Интерфейсный фундамент, на котором стоит всё серверное Go — от io.Reader до context.Context — у вас теперь на руках.