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

Структуры и методы

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

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

⏱ --:--

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

Вопрос 1 из 20

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

// Фрагмент для трассировки.
package main
import "fmt"
type Box struct{ Items []int }
func main(){ a:=Box{[]int{1}}; b:=a; b.Items[0]=7; fmt.Println(a.Items[0]) }

После `b := a` поле-срез в обеих структурах указывает на один массив, поэтому изменение элемента видно через обе копии. `makeInt` возвращает корректный указатель; значение не исчезает после выхода из функции. После первого `append` с достаточной ёмкостью новый элемент записывается в тот же массив; после исчерпания ёмкости возможен новый массив. Изменение `left[1]` меняет `right[0]`, потому что оба элемента соответствуют одной ячейке базового массива. `p := &n` создаёт указатель на `n`, и сравнение `p == &n` истинно в рамках этого значения.

Вопрос 2 из 20

Команда проверяет решение по теме «Структуры». Что здесь следует изменить прежде всего?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "fmt"
type Box struct{ Items []int }
func main(){ a:=Box{[]int{1}}; b:=a; b.Items[0]=7; fmt.Println(a.Items[0]) }

Возвращать новое значение вместо мутации, если это делает поток данных проще и копирование недорого. Ориентироваться на семантику владения, а не вручную угадывать стек или кучу; измерять аллокации при реальной необходимости. Делать глубокую копию ссылочных полей, если копия структуры должна владеть независимым состоянием. Копировать данные через `copy` или `append([]T(nil), src...)`, когда нужен независимый снимок. Передавать большой массив указателем либо срезом, если полная копия не является частью замысла.

Вопрос 3 из 20

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

// Определите правило Go, которое объясняет результат.
package main
import "fmt"
type Box struct{ Items []int }
func main(){ a:=Box{[]int{1}}; b:=a; b.Items[0]=7; fmt.Println(a.Items[0]) }

Оператор `&` получает адрес адресуемого значения; получившийся указатель имеет тип `*T`. Длина входит в тип массива; `[3]int` и `[4]int` — разные типы, а присваивание массива копирует все элементы. Компилятор может разместить локальное значение в куче, если указатель на него переживает вызов; возвращать такой указатель безопасно. Структура копируется как значение, но ссылочные поля внутри копии могут продолжать указывать на общие данные. Два среза могут видеть один базовый массив; запись через один срез отражается в другом, если их диапазоны пересекаются.

Вопрос 4 из 20

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

Указатель на элемент среза может стать указателем на старый массив после перераспределения при `append`. Маленький подсрез способен удерживать в памяти большой базовый массив. Escape analysis может изменить размещение после небольшой правки или обновления компилятора. Сравнивать структуру оператором `==` можно только тогда, когда сравнимы все её поля. Переназначение локального параметра-указателя не меняет указатель у вызывающего кода.

Вопрос 5 из 20

Фрагмент относится к теме «Структуры». Какой выбор лучше отражает баланс простоты и контроля?

Массив фиксирует размер в типе и полезен для точных структур, но срез гибче на границах API. Структуры удобны как значения, но наличие карт, срезов и указателей требует отдельно определить семантику копирования. Совместное владение экономит копирование, но требует ясного контракта мутации и времени жизни данных. Явное разыменование показывает мутацию, но API с множеством указателей часто сигнализирует о неясном владении. Возврат указателя иногда экономит копию, но может добавить аллокацию и нагрузку на сборщик мусора.

Вопрос 6 из 20

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

// Фрагмент для трассировки.
package main
type Point struct{ X int }
func (p Point) Move(){ p.X++ }
func main(){ p:=Point{}; p.Move(); _=p.X }

Вызов `p.Move()` не меняет `p.X`, потому что получатель `Point` скопирован. После `b := a` изменение `b[0]` не меняет `a[0]`, потому что массив скопирован как значение. `makeInt` возвращает корректный указатель; значение не исчезает после выхода из функции. `p := &n` создаёт указатель на `n`, и сравнение `p == &n` истинно в рамках этого значения. Изменение `left[1]` меняет `right[0]`, потому что оба элемента соответствуют одной ячейке базового массива.

Вопрос 7 из 20

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type Point struct{ X int }
func (p Point) Move(){ p.X++ }
func main(){ p:=Point{}; p.Move(); _=p.X }

Проверять возможность `nil` на границе и не разносить необязательный указатель глубже без необходимости. Копировать данные через `copy` или `append([]T(nil), src...)`, когда нужен независимый снимок. Передавать адрес только когда требуется общая мутация, идентичность или избегание значимой копии. Передавать большой массив указателем либо срезом, если полная копия не является частью замысла. Использовать значимый получатель для небольших неизменяемых значений и указательный — когда метод меняет состояние или копирование дорого.

Вопрос 8 из 20

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

// Определите правило Go, которое объясняет результат.
package main
type Point struct{ X int }
func (p Point) Move(){ p.X++ }
func main(){ p:=Point{}; p.Move(); _=p.X }

Оператор `&` получает адрес адресуемого значения; получившийся указатель имеет тип `*T`. Метод со значимым получателем работает с копией значения; изменения обычных полей не сохраняются в исходной структуре. Компилятор может разместить локальное значение в куче, если указатель на него переживает вызов; возвращать такой указатель безопасно. Передача `*T` позволяет функции менять исходное значение, потому что копируется сам адрес, указывающий на тот же объект. Оператор `*p` читает или изменяет значение по адресу; разыменование `nil` вызывает панику.

Вопрос 9 из 20

Фрагмент относится к теме «Методы значения». Где корректный фрагмент легко становится ошибочным?

Сравнение массивов допустимо только тогда, когда тип их элементов сравним. Даже значимый получатель может менять объект через ссылочное поле, например элемент общего среза. Нельзя взять адрес элемента карты, потому что элементы карты не являются адресуемыми значениями. Переназначение локального параметра-указателя не меняет указатель у вызывающего кода. Указатель на указатель имеет другой уровень разыменования и не заменяется автоматически обычным указателем.

Вопрос 10 из 20

На ревью разбирают тему «Методы значения». Что учитывать при выборе этого приёма для публичного API?

Значимые методы поддерживают семантику значения, но крупные структуры могут копироваться дороже и случайно разделять внутренние ссылки. Указатель избегает копирования и передаёт идентичность, но увеличивает число разделяемых состояний и проверок `nil`. Предварительный `make` с разумной ёмкостью ускоряет рост, но точная оценка не должна превращаться в удержание огромного массива. Массив фиксирует размер в типе и полезен для точных структур, но срез гибче на границах API. Совместное владение экономит копирование, но требует ясного контракта мутации и времени жизни данных.

Вопрос 11 из 20

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

// Фрагмент для трассировки.
package main
type Point struct{ X int }
func (p *Point) Move(){ p.X++ }
func main(){ p:=Point{}; p.Move(); _=p.X }

После `*p = 8` исходная переменная `n` равна 8. Вызов `p.Move()` корректен для переменной `p`: компилятор использует `(&p).Move()`, и `X` станет 1. После первого `append` с достаточной ёмкостью новый элемент записывается в тот же массив; после исчерпания ёмкости возможен новый массив. `makeInt` возвращает корректный указатель; значение не исчезает после выхода из функции. `p := &n` создаёт указатель на `n`, и сравнение `p == &n` истинно в рамках этого значения.

Вопрос 12 из 20

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type Point struct{ X int }
func (p *Point) Move(){ p.X++ }
func main(){ p:=Point{}; p.Move(); _=p.X }

Проверять `nil`-получатель только если методы типа действительно обещают осмысленное поведение для `nil`. Передавать адрес только когда требуется общая мутация, идентичность или избегание значимой копии. Проверять возможность `nil` на границе и не разносить необязательный указатель глубже без необходимости. Передавать большой массив указателем либо срезом, если полная копия не является частью замысла. Возвращать новое значение вместо мутации, если это делает поток данных проще и копирование недорого.

Вопрос 13 из 20

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

// Определите правило Go, которое объясняет результат.
package main
type Point struct{ X int }
func (p *Point) Move(){ p.X++ }
func main(){ p:=Point{}; p.Move(); _=p.X }

`append` может использовать прежний базовый массив либо выделить новый; это зависит от ёмкости. Компилятор может разместить локальное значение в куче, если указатель на него переживает вызов; возвращать такой указатель безопасно. Длина входит в тип массива; `[3]int` и `[4]int` — разные типы, а присваивание массива копирует все элементы. Оператор `*p` читает или изменяет значение по адресу; разыменование `nil` вызывает панику. Метод с получателем `*T` может менять исходное значение; компилятор часто автоматически берёт адрес адресуемой переменной.

Вопрос 14 из 20

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

Маленький подсрез способен удерживать в памяти большой базовый массив. Сравнение массивов допустимо только тогда, когда тип их элементов сравним. Указатель на элемент среза может стать указателем на старый массив после перераспределения при `append`. Нельзя автоматически взять адрес результата функции или другого неадресуемого значения для вызова указательного метода. Escape analysis может изменить размещение после небольшой правки или обновления компилятора.

Вопрос 15 из 20

В разделе «Методы указателя» показан конкретный случай. Как точнее всего описать пользу и цену этого решения?

Возврат указателя иногда экономит копию, но может добавить аллокацию и нагрузку на сборщик мусора. Явное разыменование показывает мутацию, но API с множеством указателей часто сигнализирует о неясном владении. Предварительный `make` с разумной ёмкостью ускоряет рост, но точная оценка не должна превращаться в удержание огромного массива. Указательный получатель позволяет мутацию и избегает копии, но делает совместное состояние частью контракта. Массив фиксирует размер в типе и полезен для точных структур, но срез гибче на границах API.

Вопрос 16 из 20

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

// Фрагмент для трассировки.
package main
type User struct{}
func (User) Name() string { return "u" }
type Admin struct{ User }
func main(){ a:=Admin{}; _=a.Name() }

После `b := a` изменение `b[0]` не меняет `a[0]`, потому что массив скопирован как значение. `makeInt` возвращает корректный указатель; значение не исчезает после выхода из функции. Вызов `p.Move()` не меняет `p.X`, потому что получатель `Point` скопирован. `p := &n` создаёт указатель на `n`, и сравнение `p == &n` истинно в рамках этого значения. `Admin` получает продвинутый метод `Name`, однако значение `Admin` нельзя передать туда, где требуется конкретный `User`.

Вопрос 17 из 20

Фрагмент относится к теме «Встраивание». Какую правку стоит предложить на ревью, сохранив назначение кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type User struct{}
func (User) Name() string { return "u" }
type Admin struct{ User }
func main(){ a:=Admin{}; _=a.Name() }

Возвращать новое значение вместо мутации, если это делает поток данных проще и копирование недорого. Ориентироваться на семантику владения, а не вручную угадывать стек или кучу; измерять аллокации при реальной необходимости. Всегда присваивать результат `append` обратно нужной переменной и не полагаться на сохранение адреса элементов. Использовать встраивание для композиции поведения, а не для имитации наследования и неявной подстановки типов. Передавать адрес только когда требуется общая мутация, идентичность или избегание значимой копии.

Вопрос 18 из 20

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

// Определите правило Go, которое объясняет результат.
package main
type User struct{}
func (User) Name() string { return "u" }
type Admin struct{ User }
func main(){ a:=Admin{}; _=a.Name() }

Оператор `*p` читает или изменяет значение по адресу; разыменование `nil` вызывает панику. Встраивание продвигает поля и методы, но не превращает внешний тип в подтип встроенного. Оператор `&` получает адрес адресуемого значения; получившийся указатель имеет тип `*T`. Компилятор может разместить локальное значение в куче, если указатель на него переживает вызов; возвращать такой указатель безопасно. Длина входит в тип массива; `[3]int` и `[4]int` — разные типы, а присваивание массива копирует все элементы.

Вопрос 19 из 20

В разделе «Встраивание» показан конкретный случай. Какое ограничение опаснее всего пропустить?

Переназначение локального параметра-указателя не меняет указатель у вызывающего кода. Конфликтующие продвинутые имена требуют явного указания пути и не выбираются произвольно. Нельзя взять адрес элемента карты, потому что элементы карты не являются адресуемыми значениями. Указатель на элемент среза может стать указателем на старый массив после перераспределения при `append`. Указатель на указатель имеет другой уровень разыменования и не заменяется автоматически обычным указателем.

Вопрос 20 из 20

Команда проверяет решение по теме «Встраивание». Какой вывод о сопровождении решения наиболее взвешенный?

Явное разыменование показывает мутацию, но API с множеством указателей часто сигнализирует о неясном владении. Указатель избегает копирования и передаёт идентичность, но увеличивает число разделяемых состояний и проверок `nil`. Встраивание сокращает делегирование, но слишком глубокая композиция скрывает происхождение методов. Совместное владение экономит копирование, но требует ясного контракта мутации и времени жизни данных. Мутация через указатель удобна для состояния, но чистая функция проще для параллельного использования и тестов.

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

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

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

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