GO Go · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Интерфейсы

Проверяет неявную реализацию, `any`, утверждения типа, `nil` внутри интерфейса и проектирование небольших контрактов. В тесте 20 вопросов, из них 12 требуют чтения кода, команд или диагностических фрагментов. Задания опираются на устойчивые правила современного Go; если поведение зависит от версии, это оговорено в самом вопросе.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом вопросе верен только один вариант. После завершения вы увидите общий результат и результаты по 4 тематическим шкалам с объяснениями и практическими рекомендациями.

Вопрос 1 из 20

Команда проверяет решение по теме «Неявная реализация». Как точнее всего описать выполнение фрагмента?

// Фрагмент для трассировки.
package main
type Namer interface{ Name() string }
type File struct{}
func (File) Name() string { return "x" }
var _ Namer = File{}
func main(){}

Функция принимает только `Get`, поэтому и рабочий клиент, и маленькая заглушка удовлетворяют контракту. Тип `File` удовлетворяет `Namer`, потому что имеет метод `Name() string` с точной сигнатурой. Команда `go mod tidy` добавляет необходимые требования и удаляет неиспользуемые с учётом импортов и тестов. Поле `Name` доступно из другого пакета, а поле `age` — нет. Тип `Age` допускается ограничением `~int`, хотя это отдельный именованный тип.

Вопрос 2 из 20

Перед публикацией кода по теме «Неявная реализация» нужно уточнить контракт. Какая доработка делает поведение явным для вызывающего кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type Namer interface{ Name() string }
type File struct{}
func (File) Name() string { return "x" }
var _ Namer = File{}
func main(){}

Обновлять зависимость явной командой и проверять `go.mod`, `go.sum`, тесты и заметки о выпуске. Хранить `go.mod` и `go.sum` в системе версий и проверять изменения зависимостей как обычный код. Определять интерфейс рядом с потребителем и проверять соответствие через `var _ Interface = (*Type)(nil)` там, где это помогает сопровождению. Планировать расширение через структуры параметров или опции, поддерживать старый контракт в пределах крупной версии. Разделять пакеты по устойчивой ответственности, а не создавать пакет на каждый тип или технический слой без необходимости.

Вопрос 3 из 20

В рабочем примере по теме «Неявная реализация» важно отделить гарантию от догадки. Какое правило достаточно применить для проверки ответа?

// Определите правило Go, которое объясняет результат.
package main
type Namer interface{ Name() string }
type File struct{}
func (File) Name() string { return "x" }
var _ Namer = File{}
func main(){}

Тип реализует интерфейс автоматически, если его набор методов содержит все методы интерфейса; отдельного объявления `implements` нет. Идентификатор экспортируется, если начинается с заглавной Unicode-буквы и объявлен на подходящем уровне. Добавление экспортированной функции обычно совместимо, а изменение сигнатуры, удаление имени или добавление метода в интерфейс ломает пользователей. Все обычные `.go`-файлы одного каталога должны объявлять один пакет; пакет задаёт единицу компиляции и повторного использования. Параметр типа объявляется в квадратных скобках и получает конкретный тип при инстанцировании функции или типа.

Вопрос 4 из 20

Фрагмент относится к теме «Неявная реализация». Какой граничный случай нужно проверить отдельно?

Экспортированное поле структуры нельзя позднее скрыть без нарушения совместимости пользователей пакета. Ограничение `int` без `~` допускает сам `int`, но не произвольный `type Age int`. Метод с получателем `*T` входит в набор методов `*T`, но не обязательно `T`. Крупная версия `v2+` обычно входит в путь импорта, например `/v2`, поэтому это отдельный модульный путь. Директива `replace` удобна локально, но случайная публикация замены на путь файловой системы ломает сборку у других.

Вопрос 5 из 20

На ревью разбирают тему «Неявная реализация». Какой инженерный компромисс здесь действительно существует?

Неявная реализация снижает связанность, но слишком широкие интерфейсы трудно удовлетворять и подменять. Хорошая документация уменьшает неверное использование, но избыточное описание реализации быстро устаревает. Приближённый тип делает API дружелюбнее к доменным типам, но слишком широкое объединение усложняет сообщение об ошибке. Фиксация версий делает сборку повторяемой, но слишком редкие обновления накапливают риски миграции и уязвимости. Строгая совместимость снижает стоимость обновления, но иногда оправдана новая крупная версия с ясной миграцией.

Вопрос 6 из 20

Перед публикацией кода по теме «Пустой интерфейс» нужно уточнить контракт. Что именно произойдёт при выполнении показанного фрагмента?

// Фрагмент для трассировки.
package main
func main(){ var x any = 3; _, ok := x.(int); _ = ok }

Тип `Age` допускается ограничением `~int`, хотя это отдельный именованный тип. Функция `Has` принимает ключ любого сравнимого типа, согласованного с ключами карты. Универсальная функция копирования среза возвращает `[]T`, не заставляя вызывать утверждение типа. Компилятор выводит `T=int` из аргументов `Min(3,5)`, если ограничение допускает `int`. После `var x any = 3` динамический тип интерфейса — `int`, а само значение не становится нетипизированным.

Вопрос 7 из 20

В рабочем примере по теме «Пустой интерфейс» важно отделить гарантию от догадки. Как исправить основной риск без ненужной перестройки решения?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func main(){ var x any = 3; _, ok := x.(int); _ = ok }

Планировать расширение через структуры параметров или опции, поддерживать старый контракт в пределах крупной версии. Использовать конкретный тип или параметр типа, если допустимые значения известны заранее; `any` оставлять для действительно открытых границ. Добавлять исполняемые Example для основного пути и разделять обязательные гарантии от деталей реализации. Использовать `~`, когда алгоритму важны операции базового представления и нужно сохранить пользовательский именованный тип. Не обобщать функцию, если конкретная версия короче, яснее и не дублируется в реальных местах.

Вопрос 8 из 20

Фрагмент относится к теме «Пустой интерфейс». Какой принцип позволяет вывести ответ без запуска программы?

// Определите правило Go, которое объясняет результат.
package main
func main(){ var x any = 3; _, ok := x.(int); _ = ok }

Ограничение задаёт множество допустимых типов и доступные операции; `comparable` разрешает `==` и использование как ключа карты. Обобщения хорошо сохраняют точный тип данных, но не выполняют динамическую диспетчеризацию поведения сами по себе. `any` — псевдоним `interface{}` и может хранить значение любого типа, но операции требуют проверки динамического типа. Файл `go.mod` задаёт путь модуля, версию языка и требования к модулям, но не хранит исходный код зависимостей. Параметр типа объявляется в квадратных скобках и получает конкретный тип при инстанцировании функции или типа.

Вопрос 9 из 20

На ревью разбирают тему «Пустой интерфейс». Какой контрпример разрушит слишком широкое толкование правила?

Добавление поля в экспортированную структуру может сломать внешние позиционные литералы без имён полей. Экспортированное поле структуры нельзя позднее скрыть без нарушения совместимости пользователей пакета. Интерфейс с типизированным `nil`-указателем внутри не равен `nil`. Нельзя использовать утверждение типа непосредственно для обычного значения параметра типа без преобразования к интерфейсу. Тестовый файл может использовать пакет `store_test`, чтобы проверять только экспортированный контракт.

Вопрос 10 из 20

В разделе «Пустой интерфейс» показан конкретный случай. Что важно учесть помимо формальной корректности?

`any` удобен для декодирования и инфраструктуры, но переносит ошибки типов из компиляции во время выполнения. Структурированная ошибка богаче, но простой sentinel легче для редкого бинарного случая. Обобщения дают статическую безопасность коллекций, а интерфейсы лучше выражают открытый набор реализаций поведения. Обобщение устраняет копирование алгоритма, но не должно заменять простой интерфейс поведения. Приближённый тип делает API дружелюбнее к доменным типам, но слишком широкое объединение усложняет сообщение об ошибке.

Вопрос 11 из 20

В рабочем примере по теме «Утверждение типа» важно отделить гарантию от догадки. Какое описание результата совпадает с правилами Go?

// Фрагмент для трассировки.
package main
func main(){ var x any = "7"; n, ok := x.(int); _, _ = n, ok }

Для строки внутри `any` выражение `n, ok := x.(int)` даст `0, false` без паники. Тип `Age` допускается ограничением `~int`, хотя это отдельный именованный тип. Компилятор выводит `T=int` из аргументов `Min(3,5)`, если ограничение допускает `int`. Поле `Name` доступно из другого пакета, а поле `age` — нет. Новая опция через функциональный параметр позволяет расширить конструктор без изменения старых вызовов.

Вопрос 12 из 20

Фрагмент относится к теме «Утверждение типа». Какая правка устраняет причину, а не маскирует её проявление?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func main(){ var x any = "7"; n, ok := x.(int); _, _ = n, ok }

Начинать с конкретного типа и вводить интерфейс при появлении второго потребителя или подмены с реальной пользой. Использовать `~`, когда алгоритму важны операции базового представления и нужно сохранить пользовательский именованный тип. Использовать двухзначную форму или type switch, когда несовпадение является ожидаемым входом. Не обобщать функцию, если конкретная версия короче, яснее и не дублируется в реальных местах. Делать ограничение минимальным и выражать только реально используемые операции.

Вопрос 13 из 20

На ревью разбирают тему «Утверждение типа». Что именно гарантирует Go в этой ситуации?

// Определите правило Go, которое объясняет результат.
package main
func main(){ var x any = "7"; n, ok := x.(int); _, _ = n, ok }

Утверждение типа в двухзначной форме возвращает значение и `ok`; однозначная форма вызывает панику при несовпадении. Параметр типа объявляется в квадратных скобках и получает конкретный тип при инстанцировании функции или типа. Элемент `~T` в ограничении включает именованные типы, чей базовый тип равен `T`. Добавление экспортированной функции обычно совместимо, а изменение сигнатуры, удаление имени или добавление метода в интерфейс ломает пользователей. Интерфейс определяет потребитель; часто достаточно одного метода, который функция действительно вызывает.

Вопрос 14 из 20

В разделе «Утверждение типа» показан конкретный случай. Что нельзя автоматически переносить на похожий код?

Методы не могут вводить собственные дополнительные параметры типов сверх параметров типа получателя. Тестовый файл может использовать пакет `store_test`, чтобы проверять только экспортированный контракт. Экспортированный широкий интерфейс трудно расширять без поломки внешних реализаций. Ограничение `int` без `~` допускает сам `int`, но не произвольный `type Age int`. Утверждение проверяет динамический тип интерфейсного значения, а не выполняет произвольное преобразование типов.

Вопрос 15 из 20

Команда проверяет решение по теме «Утверждение типа». Как оценить этот подход для производственного кода?

Крупный пакет проще навигации до определённого размера, а мелкие пакеты снижают связанность лишь при реальной границе ответственности. Малый контракт улучшает совместимость, но интерфейс ради одной реализации внутри пакета может быть лишним слоем. Фиксация версий делает сборку повторяемой, но слишком редкие обновления накапливают риски миграции и уязвимости. Однозначная форма короче при доказанном инварианте, но делает нарушение инварианта паникой. Приближённый тип делает API дружелюбнее к доменным типам, но слишком широкое объединение усложняет сообщение об ошибке.

Вопрос 16 из 20

Фрагмент относится к теме «Малые контракты». Какой итог можно предсказать без пробного запуска?

// Фрагмент для трассировки.
package main
import "io"
func count(r io.Reader) (int, error) {
    buf:=make([]byte,32); n,err:=r.Read(buf); return n,err
}
func main(){}

Функции достаточно `io.Reader`, если она только читает поток; требование конкретного файла излишне сужает применение. Файлы `a.go` и `b.go` с `package store` компилируются вместе, даже если объявления распределены между файлами. Новая опция через функциональный параметр позволяет расширить конструктор без изменения старых вызовов. Команда `go mod tidy` добавляет необходимые требования и удаляет неиспользуемые с учётом импортов и тестов. Функция принимает только `Get`, поэтому и рабочий клиент, и маленькая заглушка удовлетворяют контракту.

Вопрос 17 из 20

На ревью разбирают тему «Малые контракты». Как изменить решение, не ломая его исходную задачу?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "io"
func count(r io.Reader) (int, error) {
    buf:=make([]byte,32); n,err:=r.Read(buf); return n,err
}
func main(){}

Не обобщать функцию, если конкретная версия короче, яснее и не дублируется в реальных местах. Экспортировать минимальный устойчивый контракт и оставлять детали реализации неэкспортируемыми. Делать ограничение минимальным и выражать только реально используемые операции. Использовать `~`, когда алгоритму важны операции базового представления и нужно сохранить пользовательский именованный тип. Принимать минимальный интерфейс, а возвращать конкретный тип, когда вызывающему коду полезны его возможности.

Вопрос 18 из 20

В разделе «Малые контракты» показан конкретный случай. Какое утверждение остаётся верным на всех поддерживаемых платформах?

// Определите правило Go, которое объясняет результат.
package main
import "io"
func count(r io.Reader) (int, error) {
    buf:=make([]byte,32); n,err:=r.Read(buf); return n,err
}
func main(){}

Добавление экспортированной функции обычно совместимо, а изменение сигнатуры, удаление имени или добавление метода в интерфейс ломает пользователей. Интерфейс с одним-двумя методами легче реализовать, тестировать и комбинировать; контракт должен отражать потребность вызывающего кода. Комментарий экспортированного имени объясняет назначение, контракт, ошибки и конкурентную безопасность, а не повторяет сигнатуру. Интерфейс определяет потребитель; часто достаточно одного метода, который функция действительно вызывает. Публичный API должен позволять программно распознавать значимые категории через `errors.Is/As`, сохраняя контекст.

Вопрос 19 из 20

Команда проверяет решение по теме «Малые контракты». Какое условие нельзя считать выполненным по умолчанию?

Добавление метода в опубликованный интерфейс ломает все внешние реализации этого интерфейса. Методы не могут вводить собственные дополнительные параметры типов сверх параметров типа получателя. Директива `replace` удобна локально, но случайная публикация замены на путь файловой системы ломает сборку у других. Каждая новая sentinel-ошибка становится частью публичного протокола и может закрепить внутреннюю деталь. Тестовый файл может использовать пакет `store_test`, чтобы проверять только экспортированный контракт.

Вопрос 20 из 20

Перед публикацией кода по теме «Малые контракты» нужно уточнить контракт. Какой вариант честно называет и преимущество, и издержку?

Широкое ограничение повышает применимость, но может не дать операций, нужных алгоритму. Малый интерфейс улучшает заменяемость, но бессмысленное дробление без реальных потребителей создаёт лишние имена. Крупный пакет проще навигации до определённого размера, а мелкие пакеты снижают связанность лишь при реальной границе ответственности. Хорошая документация уменьшает неверное использование, но избыточное описание реализации быстро устаревает. Обобщения дают статическую безопасность коллекций, а интерфейсы лучше выражают открытый набор реализаций поведения.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу