Полиморфизм и пустой интерфейс

Слово «полиморфизм» обычно тянет за собой багаж из мира классов: иерархии наследования, виртуальные методы, таблицы вызовов. В Go всё скромнее и жёстче: полиморфизм — это свойство значений разных конкретных типов отвечать на один и тот же вызов по-разному, потому что все они лежат под одним контрактом. Никаких предков объявлять не нужно — есть набор методов, есть переменная интерфейсного типа, и вызов всегда уходит динамическому типу, тому самому, который записан в паре «динамический тип + значение» внутри интерфейсной переменной.

В десятом уроке мы уже видели этот механизм в работе: срез []fmt.Stringer хранил кота, пса и робота, и каждый отвечал на String() своим текстом. Сегодня — та же фигура, но глубже: разберём, почему она работает, а затем пойдём в крайность. Крайность называется пустой интерфейс: контракт без единого метода, которому удовлетворяет буквально всякое значение в программе. У него есть официальное короткое имя — any — и тяжёлая репутация: это самый гибкий и самый опасный тип в языке. Мы разберём и его срезы ([]any), и его роль внутри fmt.Println, и то, почему компилятор перестаёт вас защищать, как только вы пишете any вместо конкретного контракта.

План урока: углубить срез интерфейсов из прошлого урока, вскрыть any и его историю (interface{} до версии 1.18, алиас any после), запустить свой вариадик ...any, сравнить any с конкретным интерфейсом на живом примере, углубить обещанную ловушку typed-nil до производственной формы func f() error, и обозначить границы — где any уместен, а где дженерики (тринадцатый урок). Интерактивы спроектированы под оба движка песочницы: там, где движки расходятся, будет честная оговорка.

Начнём с повторения, но с подсветкой механики. Объявление zoo := []Speaker{Cat{...}, Dog{...}, Robot{...}} делает три вещи. Во-первых, создаёт срез, каждый элемент которого — интерфейсное значение Speaker: пара «динамический тип + значение», а не структура и не указатель. Во-вторых, при каждом присваивании элемента компилятор сверяет набор методов конкретного типа с контрактом: у Cat есть Speak() — вписывается, у int нет — не впишется, ошибка сборки. В-третьих, цикл for _, s := range zoo на каждом шаге зовёт s.Speak() — и вызов уходит динамическому типу текущего элемента. Вот весь полиморфизм: одна точка вызова, много реализаций, решение принимается по данным, а не по коду.

Ключевое следствие пары «тип + значение»: добавление нового типа не требует трогать старый код. Написали Bird с методом Speak() — и он вписывается в существующий срез, потому что контракт проверяется по фактам набора методов, а не по родословной. Именно поэтому в прошлом уроке мы называли это расширением без правок: срез, цикл и интерфейс остаются нетронутыми, растёт только множество типов под контрактом.

И ещё одна деталь, которая сегодня станет главной героиней: если бы контракта не было вовсе — если бы срез принимал всё — компилятор перестал бы проверять хоть что-нибудь. Цикл не знал бы, какой метод звать: у него не было бы ни одного гарантированного. Эта пустота — не абстракция, а конкретный тип: any. Разберёмся, откуда он взялся и как устроен.

Интерфейс — это набор методов. Логичный предельный случай: набор из нуля методов. Такой контракт не требует ничего — и потому ему удовлетворяет каждое значение в программе: число, строка, структура, функция, карта, другой интерфейс. Это и есть пустой интерфейс. Исторически он записывался как interface{} — слово interface, пустые фигурные скобки: «набор методов, перечисленный внутри, — пуст». Так писали с первых версий Go, и в миллионах строк существующего кода вы встретите именно эту форму.

В Go 1.18 (релиз с дженериками, до которого мы доберёмся в тринадцатом уроке) пустому интерфейсу дали короткий алиас: `any`. Алиас — это второе имя того же типа, а не новый тип: var v any и var v interface{} — буквально одно и то же, компилятор разворачивает одно в другое. В свежем коде принято писать any; встречая interface{}, читайте «any». В этом уроке мы пишем any, но все примеры работают и со старой формой — проверить можно в любом из ранимых блоков.

Внутри any — всё та же пара «динамический тип + значение». Пустая пара, когда any-переменная объявлена без присваивания, — это nil; заполненная пара после v = 42 — (int, 42); после v = "семь" — (string, "семь"). Любое присваивание any-переменной — это упаковка: значение вместе со своим типом заворачивается в пару. Отсюда два следствия, которые мы сегодня проверим руками. Первое: any-параметр функции принимает всё — сигнатура func show(v any) — универсальный зев. Второе, неприятное: у any нет ни одного метода, значит функция с any-параметром не может вызвать у аргумента ничего — только передать дальше или распаковать. Компиляторные гарантии, ради которых мы брали конкретные контракты, исчезли. Это и есть цена, за которую платят гибкостью.

Заглянем в исходники стандартной библиотеки, которые вы зовёте каждый день. Пакет fmt объявляет печать так:

func Println(a ...any) (n int, err error)

Вот откуда берётся магия «печатай что угодно»: fmt.Println принимает вариадик any — срез пустых интерфейсов, в который упаковываются все ваши аргументы. Передали fmt.Println("баланс:", 1000, "ок", true) — fmt получил []any из четырёх элементов, прошёл по срезу циклом, для каждого элемента посмотрел на динамический тип и выбрал формат. Динамический тип решает всё: для string — сырой текст, для int — цифры, а если динамический тип реализует fmt.Stringer — зовётся метод String() (десятый урок). Значит, когда вы пишете fmt.Println(кот) и получаете красивую строку — это полиморфизм в чистом виде: одна функция печати, сотни типов, решение по данным.

Тот же приём у fmt.Printf(format string, a ...any), errors.New в паре с fmt.Errorf(format string, a ...any) и у половины пакета fmt. Вариадик any — идиома «принимаю что угодно, разберусь сам»: она законна там, где функция специализируется на незнании — печать, сериализация, логирование. Но у неё есть жёсткая граница: внутри такой функции с каждым элементом можно сделать только то, что умеет any, — то есть почти ничего, кроме передачи дальше. Хочется вызвать метод — нужен конкретный контракт, а не any.

Раз any влезает в параметр, он влезает и в срез: `[]any` — срез, где в одной корзине лежат значения разных типов, каждое упакованное в свою пару «тип + значение». Это самый гибкий контейнер в Go: box := []any{42, "кот", 3.14, true} собирается без вопросов, append доливает элементы любого типа, len и range работают как обычно. Внутри box нет ни одного значения «в чистом виде» — все упакованы, и компилятор не помнит ни одного конкретного типа.

Сравните с []fmt.Stringer из прошлого урока. Внешне фигуры похожи: и там, и там срез интерфейсных пар, и там, и там полиморфизм. Разница — в контракте. []fmt.Stringer гарантирует: у каждого элемента есть метод String() string, и цикл может звать его легально — компилятор проверил при упаковке. []any не гарантирует ничего: у элементов нет ни одного общего метода, цикл может их только печатать fmt-ом или перекладывать дальше. Формула простая: чем пустее контракт, тем больше типов влезает — и тем меньше можно с ними сделать. []fmt.Stringer — корзина «всё, что умеет печатать себя»; []any — корзина «всё».

Где []any всё-таки нужен? Там, где разнородность — суть данных: распакованный JSON с неизвестной заранее структурой (так устроен json.Unmarshal в any), печать отладочных значений, слои кода, которые перекладывают данные, не вникая, что внутри. Правило вкуса: если для ваших данных существует осмысленный контракт хотя бы из одного метода — берите контракт, а не any; any оставьте на случаи, когда контракта действительно нет.

Теперь честный разговор о цене. Type safety — типобезопасность — это свойство языка, при котором классы ошибок ловятся компилятором до запуска: вызов несуществующего метода, сложение строки с числом, передача аргумента не того типа. Go в обычной жизни типобезопасен жёстко, и это его главный подарок рефакторингу: переименовали поле — компилятор указал на все места использования. Проблема any в том, что он выключает эту защиту локально: как только значение упаковано в пару «any + значение», компилятор забывает динамический тип и перестаёт проверять всё, что вы с ним делаете.

По запросу any interface golang поисковая выдача быстро приводит к дискуссиям «any considered harmful» и к правилам линтеров, запрещающим any в публичных API. Аргумент всегда один и тот же, и мы его уже видели в коде: у any нет методов. var v any = c принимает кота — но v.String() не скомпилируется; box := []any{...} соберётся — но box[0] + 1 не скомпилируется; функция func show(v any) съест всё — но не сможет вызвать у аргумента ничего. Каждый шаг «сделаем тип свободнее» — это шаг «сделаем компилятор слепее». Ошибки не исчезают: они переезжают из стадии компиляции в стадию исполнения, где за них платит пользователь паниками и мусорными данными.

Отсюда рабочий критерий. any — это признание незнания: «на этом слое кода я не знаю и не хочу знать, что внутри, — я перекладываю, печатаю или сериализую». Если вы знаете, что аргумент умеет печатать себя, — берите fmt.Stringer; если умеет читать, — io.Reader; если это число или строка — берите конкретный тип. Пустой интерфейс — крайний случай, когда честного контракта нет. Уместен он в fmt-пакете, в распаковке JSON, в редких служебных слоях — и почти никогда в бизнес-логике. А ещё полезно помнить направление эволюции языка: дженерики в 1.18 появились во многом затем, чтобы закрыть главную причину, по которой люди тянулись к any, — «нужна функция для многих типов». Об этом — тринадцатый урок.

Десятый урок обещал вернуться к ловушке typed-nil «в одиннадцатом и двенадцатом уроках» — время платить. Напомним базу: интерфейс — пара «динамический тип + значение»; nil-интерфейс — пара из двух nil; присваивание типизированного nil-указателя заполняет половину пары, и == nil для интерфейса становится false. Тогда мы смотрели на это на переменных; в проде ловушка живёт в функциях, возвращающих error — а error, как мы помним, интерфейс из одного метода Error() string.

Каноническая производственная ошибка выглядит так: функция-помощник объявляет переменную-ошибку заранее и возвращает её в конце:

func f() error { var e *MyErr = nil; ...; return e }

Похоже на безобидный стиль «объявим наверху, вернём внизу». Но return e возвращает не «ничего», а пару (*MyErr, nil): динамический тип в паре заполнен. Вызывающий делает if err != nil — и получает true: ошибка «есть», хотя внутри nil. Дальше обычно следует паника при попытке вызвать err.Error() или, хуже, молчаливый отправленный клиенту фиктивный "500". И обратите внимание: форма return (*MyErr)(nil) — литеральный типизированный nil — даёт тот же эффект: err != nil — TRUE.

Способ избежать — один и абсолютный: возвращайте голый nil явно. return nil кладёт пару (nil, nil), проверка вызывающего работает. Практическое правило: в ветке «ошибки нет» пишите return nil дословно, а не return e с e, объявленной где-то наверху; если стилистика «один return» нужна, возвращайте конкретный тип-указатель, а не интерфейс, либо собирайте результат через именованные возвраты аккуратно. Проверять это удобнее всего компилятором-соседом: var _ error = (*MyErr)(nil) гарантирует контракт, а привычка return nil — честность пары.

Мы дважды упёрлись в одну стену: any-значение не даёт вызвать ни метод, ни операцию. Как из пары «тип + значение» достать тип обратно? У Go есть специальная конструкция — type switch, переключение по динамическому типу:

switch x := v.(type) { case int: ... case string: ... }

На каждой ветке переменная x — уже конкретного типа: в ветке case int это int, и арифметика снова легальна; в case string — строка. Это «распаковка пары» на максимуме: конструкция перебирает типы и выбирает совпавший с динамическим. Родственный ей инструмент — одиночный type assertion v.(T) с ok-формой x, ok := v.(T): «достань T, и скажи честно, получилось ли». Обе конструкции — это то, что превращает any из чёрной дыры в управляемый контейнер, и это целиком территория двенадцатого урока: там будут и правила паники одиночной формы, и идиомы ok-формы, и ошибки interface conversion.

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

Пройден ещё один виток: срезы интерфейсов получили внутреннюю механику — пара «динамический тип + значение» объясняет и полиморфный цикл, и то, почему typed-nil обманывает проверку; пустой интерфейс any показал себя и универсальным зевом (func show(v any), fmt.Println(a ...any)), и дырой в type safety. Вы умеете выбирать между []fmt.Stringer и []any осознанно: первый — корзина поведения, второй — корзина незнания. Контекст из девятого урока и каналы четвёртого из середины курса теперь стоят в одном ряду с интерфейсами: это всё инструменты контрактов — только контракты там про отмену и передачу данных, а здесь про поведение типов.

Поиск any interface golang теперь ведёт вас дальше по той же тропе. Следующие два шага закрывают оставленные хвосты. «Приведение типов и type assertion» — двенадцатый урок: одиночная форма v.(T) с её паникой interface conversion, ok-форма x, ok := v.(T), type switch во всей красе — инструменты честной распаковки any, про которые сегодня только тизер. Тринадцатый урок — дженерики: func Map[T, R any](...)... и то, как язык 1.18 научился давать гибкость «для многих типов», не выключая type safety, — прямая альтернатива many-случаям, где раньше писали any. Весь курс движется к проектированию API — с типизированными инструментами вместо пустых корзин.