Интерфейсы и идентичность типов
Представление и диспетчеризация интерфейсов, утверждения типов, typed nil и сравнимость типов.
13 вопросов
JuniorТеорияОчень частоЧто такое interface в Go и как он удовлетворяется?
Что такое interface в Go и как он удовлетворяется?
interface — это тип, заданный набором методов. Любой конкретный тип, у которого есть эти методы, удовлетворяет interface неявно: нет ключевого слова implements и явного объявления. Значение interface хранит пару (динамический тип, значение). Пустой interface interface{} / any удовлетворяется любым типом, а интерфейсы дают Go полиморфизм и развязку.
Типичные ошибки
- ✗Искать ключевое слово
implements— Go удовлетворяет interface неявно - ✗Думать, что interface хранит только значение, а не и его динамический тип
- ✗Считать, что
anyисключает некоторые типы — его удовлетворяет любой тип
Уточняющие вопросы
- →Чем nil interface отличается от interface, хранящего nil-указатель?
- →Когда присваивание в interface выделяет память в куче?
MiddleТеорияОчень частоКак работают утверждения типа и type switch на интерфейсных значениях в Go?
Как работают утверждения типа и type switch на интерфейсных значениях в Go?
Утверждение типа x.(T) проверяет динамический тип интерфейса и извлекает конкретное значение; форма с одним результатом паникует при несовпадении, а форма с comma-ok v, ok := x.(T) сообщает о неудаче через ok. Type switch switch v := x.(type) диспетчеризует по динамическому типу сразу по нескольким ветвям.
Типичные ошибки
- ✗Использовать форму
x.(T)с одним результатом на недоверенном вводе и получать панику вместо проверкиok - ✗Думать, что утверждение типа преобразует или переинтерпретирует биты, а не проверяет динамический тип
- ✗Полагать, что type switch проваливается или выполняет несколько ветвей, как C-
switch
Уточняющие вопросы
- →Что возвращают
vиokвx.(T), когда самxравенnil? - →Чем утверждение к интерфейсному типу отличается от утверждения к конкретному типу?
JuniorТеорияЧастоКакие типы в Go сравнимы и годятся как ключи map?
Какие типы в Go сравнимы и годятся как ключи map?
Сравнимы оператором ==: булевы, числовые типы, строки, указатели, каналы, интерфейсы и структуры/массивы, у которых каждое поле сравнимо. slices, maps и функции НЕ сравнимы — только с nil — и потому не годятся в ключи map, а ключ обязан быть сравнимым.
Типичные ошибки
- ✗Думать, что
sliceилиmapможно использовать ключом map — оба не компилируются - ✗Считать, что
==для структуры работает всегда, независимо от типов её полей - ✗Ожидать, что
slice == sliceсравнит элементы, а не выдаст ошибку компиляции
Уточняющие вопросы
- →Как сделать ключом map содержимое среза?
- →Почему сравнение двух интерфейсов может вызвать панику в рантайме?
MiddleДебаггингЧастоПочему этот кэш всегда промахивается, и Get всегда возвращает nil?
Почему этот кэш всегда промахивается, и Get всегда возвращает nil?
Несовпадение типов. Set кладёт значение: s.cache.Put(wh.Id, *wh) разыменовывает указатель, поэтому динамический тип в кэше — warehouse.Warehouse. А Get ассертит указатель: item.(*warehouse.Warehouse). Этот ассерт никогда не проходит, и Get всегда доходит до return nil, и кэш не попадает. Исправление: класть и ассертить один тип — класть wh, ассертить *warehouse.Warehouse.
Типичные ошибки
- ✗Не замечать, что
*whразыменовывает указатель, кладя значение, а не указатель - ✗Считать, что type assertion автоматически конвертирует между значением и указателем
- ✗Винить вытеснение, типы ключей или гонку вместо несовпадения значение/указатель
Уточняющие вопросы
- →Почему
item.(*warehouse.Warehouse)возвращаетok == false, а не паникует? - →Что вернул бы
item.(warehouse.Warehouse)при текущемSet?
MiddleТеорияЧастоГде объявлять интерфейс в Go — рядом с реализацией или рядом с потребителем?
Где объявлять интерфейс в Go — рядом с реализацией или рядом с потребителем?
Объявляйте интерфейс в пакете-потребителе — там, где значение используется, а не там, где реализуется. Поскольку Go удовлетворяет интерфейсам неявно (duck typing), потребитель определяет ровно тот маленький набор методов, что ему нужен. Это отвязывает потребителя от конкретных типов и упрощает подмену на mock в тестах. Реализациям не нужно импортировать интерфейс.
Типичные ошибки
- ✗Класть интерфейсы рядом с реализацией, как в Java/C#, а не у потребителя
- ✗Определять один большой интерфейс вместо маленького под нужды потребителя
- ✗Думать, что реализующий тип должен импортировать или называть интерфейс
Уточняющие вопросы
- →Как объявление на стороне потребителя упрощает подмену на mock в тестах?
- →Почему меньший интерфейс (меньше методов) даёт более слабую связанность?
MiddleТеорияЧастоКак интерфейсное значение представлено в памяти в Go (iface против eface)?
Как интерфейсное значение представлено в памяти в Go (iface против eface)?
Интерфейсное значение — это два слова. Для интерфейса с методами (iface) первое слово указывает на itab — пару конкретного типа и его набора методов — а второе на данные. Для пустого интерфейса any (eface) первое слово — лишь дескриптор *_type, второе — указатель на данные.
Типичные ошибки
- ✗Думать, что интерфейс — одно слово: на самом деле два — слово типа/itab и слово данных
- ✗Полагать, что
efaceнесётitab— толькоifaceнесёт;efaceхранит голый*_type - ✗Считать, что конкретное значение хранится внутри интерфейса, а не за указателем на данные
Уточняющие вопросы
- →Когда слово данных указывает на кучу, а когда хранит указатель напрямую?
- →Как
itabстроится и кэшируется при первой встрече конкретного типа с интерфейсом?
MiddleКодЧастоПочему вызов hello() на nil-указателе *gopher проходит успешно, а не паникует?
Почему вызов hello() на nil-указателе *gopher проходит успешно, а не паникует?
Метод с указателем-получателем — функция с указателем первым аргументом, поэтому вызов на nil-указателе допустим, пока тело не разыменовывает этот указатель. hello лишь печатает константу и не трогает g.name, поэтому отрабатывает. Обращение к g.name паникнуло бы с nil-разыменованием.
Типичные ошибки
- ✗Считать, что любой вызов метода на
nil-указателе паникует в точке вызова - ✗Думать, что Go выделяет нулевое значение для
nil-получателя - ✗Забывать, что паника возникает, только когда тело разыменовывает
nil-указатель (например,g.name)
Уточняющие вопросы
- →Какая именно ошибка runtime возникнет, если
helloпрочитаетg.nameнаnil-получателе? - →Как некоторые типы (например,
nil*Tree) намеренно полагаются на методы с nil-получателем?
MiddleКодЧастоЧто выведут a == b и m[b] для двух равных структур point и почему?
Что выведут a == b и m[b] для двух равных структур point и почему?
Выведет true и p. Структуры сравнимы через ==, когда каждое поле сравнимо, сравнение идёт поле за полем. Поскольку a == b, они хешируются в один ключ map, поэтому m[b] находит значение под a. Поле-срез сделало бы и ==, и ключ map некомпилируемыми.
Типичные ошибки
- ✗Думать, что
==для структур сравнивает идентичность, а не значения полей - ✗Считать, что структура с полем-срезом или map всё ещё сравнима — она не компилируется
- ✗Забывать, что две равные структуры хешируются в один ключ map
Уточняющие вопросы
- →Какие типы полей делают структуру несравнимой и какая будет ошибка компиляции?
- →Как всё же использовать структуру с полем-срезом в качестве ключа map?
MiddleТеорияЧастоПочему интерфейс, хранящий nil-указатель, может оказаться не равен nil в Go?
Почему интерфейс, хранящий nil-указатель, может оказаться не равен nil в Go?
Интерфейс равен nil только когда оба его слова нулевые. Присваивание nil-указателя *T ставит слово типа в *T, а слово данных остаётся нулевым — интерфейс становится non-nil «typed nil». Классическая ловушка — возврат такого значения из функции, чей тип результата — интерфейс.
Типичные ошибки
- ✗Возвращать конкретный nil
*Tиз функции с интерфейсным типом результата и ждать, что== nilистинно - ✗Думать, что для равенства
nilважно лишь слово данных — слово типа тоже должно быть нулевым - ✗Считать, что печать
<nil>черезfmtдоказывает равенство самого интерфейса nil
Уточняющие вопросы
- →Как корректно вернуть nil-интерфейс из функции вместо typed nil?
- →Паникует ли вызов метода на typed-nil интерфейсе и когда?
MiddleКодИногдаЧто выведет эта программа с typed-nil интерфейсом и двумя утверждениями типа?
Что выведет эта программа с typed-nil интерфейсом и двумя утверждениями типа?
Печатает i is nil, затем i value is nil — две строки. После i = t, где t — nil *Type, интерфейс хранит слово типа *Type и nil-данные, поэтому i == nil ложно и эта ветвь пропускается. Но i.(*Type) извлекает сам указатель, который nil, поэтому сравнение истинно. После t = &Type{} указатель не nil, и последняя ветвь пропускается.
Типичные ошибки
- ✗Ждать, что второе
i == nilистинно, раз хранимый указатель nil - ✗Думать, что
i.(*Type)заново оборачивает nil и потому паникует, а не выдаёт nil-указатель - ✗Путать
i == nil(сравнивает весь интерфейс) иi.(*Type) == nil(сравнивает извлечённый указатель)
Уточняющие вопросы
- →Сработала бы вторая ветвь, будь
tобъявлен какInterface, а не*Type? - →Что сделает
i.(*Type), если в этот момент интерфейс хранит другой конкретный тип?
MiddleТеорияИногдаКакую проблему решают generics в Go, и почему их хотели вместо interface{}?
Какую проблему решают generics в Go, и почему их хотели вместо interface{}?
Generics позволяют написать одну типобезопасную реализацию, работающую для многих типов и проверяемую на этапе компиляции. Прежняя альтернатива — interface{} — теряет статическую типобезопасность: нужны runtime type assertions, значения упаковываются (лишние аллокации), а ошибки типов всплывают в runtime. Generics также убирают копипасту одной и той же функции под каждый конкретный тип.
Типичные ошибки
- ✗Считать
interface{}типобезопасным, а не откладывающим все проверки типов на runtime - ✗Думать, что generics добавляют runtime-стоимость как рефлексия, а не разрешаются при компиляции
- ✗Полагать, что generics полностью заменяют интерфейсы, а не дополняют их
Уточняющие вопросы
- →Чем ограничение типа (constraint) отличается от обычного интерфейса в роли типа параметра?
- →Что такое вывод типов, и когда аргумент типа всё же надо указывать явно?
SeniorТеорияРедкоКакова стоимость вызова метода через интерфейс в Go и что такое itab?
Какова стоимость вызова метода через интерфейс в Go и что такое itab?
Вызов через интерфейс идёт косвенно через itab — структуру на пару (интерфейс, конкретный тип), хранящую конкретный *_type и срез указателей на функции набора методов. Вызов читает цель из этой таблицы и прыгает: малая предсказуемая стоимость, не бесплатно и в общем случае без девиртуализации.
Типичные ошибки
- ✗Утверждать, что вызовы через интерфейс всегда девиртуализуются в прямые с нулевыми накладными расходами
- ✗Думать, что
itabперестраивается при каждом вызове, а не создаётся один раз и кэшируется - ✗Полагать, что диспетчеризация масштабируется с общим числом методов программы, а не является фиксированным косвенным прыжком
Уточняющие вопросы
- →Когда компилятор Go реально может девиртуализовать вызов через интерфейс в прямой?
- →Почему вызов через интерфейс обычно мешает инлайнингу функций?
SeniorТеорияРедкоКак работают параметры типа и ограничения в дженериках Go?
Как работают параметры типа и ограничения в дженериках Go?
С Go 1.18 функция или тип объявляет параметры типа в квадратных скобках, [T Constraint]. Ограничение — это интерфейс, который может перечислять набор методов и/или объединение типов; comparable — частый пример. Компилятор инстанцирует обобщённый код через GC-shape stenciling со словарями, а не чистой мономорфизацией на тип.
Типичные ошибки
- ✗Думать, что ограничения обобщений ограничены наборами методов и не выражают объединения типов
- ✗Полагать, что каждое инстанцирование даёт полностью отдельную мономорфизованную копию, как шаблоны C++
- ✗Считать, что обобщения упаковывают аргументы в
anyи диспетчеризуют рефлексией во время выполнения
Уточняющие вопросы
- →Что такое словарь в реализации обобщений Go и что он несёт?
- →Почему существует ограничение
comparableвместо простогоany?
