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

Структуры и классы

Проверяет основу темы «Структуры и классы» через чтение кода, предсказание результата и выбор корректной конструкции. Вопросы требуют не только узнать конструкцию, но и проследить выполнение, найти причину дефекта, выбрать исправление и оценить пограничный сценарий. Языковые примеры рассчитаны на Swift 6; задания с Apple SDK рассматриваются в контексте современных платформенных контрактов.

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

⏱ --:--

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

Вопрос 1 из 20

Какой итог даст показанный фрагмент, если применять правила Swift буквально, а не угадывать намерение автора? Сосредоточьтесь на следующем: семантика значения и влияние let на изменяемые свойства.

struct Counter { var value = 0; mutating func inc() { value += 1 } }
var a = Counter()
var b = a
b.inc()
print(a.value, b.value)

Структура имеет семантику значения: после копирования b изменяется независимо, вывод — не «0 1». Фрагмент не требует отдельного условия: присваивание структуры разделяет идентичность исходного экземпляра. Структура имеет семантику значения: после копирования b изменяется независимо, вывод — «0 2». Структура имеет семантику значения: после копирования b изменяется независимо, вывод — «1 1». Структура имеет семантику значения: после копирования b изменяется независимо, вывод — «0 1».

Вопрос 2 из 20

Какой из пяти выводов подтверждается построчной трассировкой? Сосредоточьтесь на следующем: ссылочная идентичность и двухфазная инициализация.

final class Box { var value: Int; init(_ value: Int) { self.value = value } }
let a = Box(1)
let b = a
b.value = 9
print(a.value)

Обе константы хранят ссылку на один объект, поэтому изменение через b видно через a и печатается 9. Наблюдаемый результат определяется тем, что присваивание структуры разделяет идентичность исходного экземпляра. Обе константы хранят ссылку на один объект, поэтому изменение через b видно через a и печатается 10. Операция с `Box` корректна, поскольку выбор между struct и class определяется только размером типа. Для этого примера достаточно учесть, что `let` запрещает изменение всех свойств ссылочного объекта.

Вопрос 3 из 20

Как поведёт себя программа в этом коротком сценарии, связанном с «Инициализация»? Здесь оценивается полная инициализация и место проверки инвариантов.

struct Point {
    let x: Int
    let y: Int
    init(_ both: Int) { x = both; y = both }
}
print(Point(3))

Последняя строка ведёт себя именно так, потому что memberwise initializer автоматически синтезируется для любого класса. Для этого примера достаточно учесть, что `let` запрещает изменение всех свойств ссылочного объекта. Пользовательский инициализатор присваивает все let-свойства до завершения, поэтому создаётся Point(x: 3, y: 3). Пользовательский инициализатор присваивает все let-свойства до завершения, поэтому создаётся Point(x: 3, y: 4). Пользовательский инициализатор присваивает все let-свойства до завершения, поэтому создаётся Point(x: 4, y: 3).

Вопрос 4 из 20

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

struct Money { let cents: Int }
var invoice = Money(cents: 100)
var copy = invoice
copy = Money(cents: 250)
print(invoice.cents)

Фрагмент не требует отдельного условия: memberwise initializer автоматически синтезируется для любого класса. Переназначение копии не меняет исходное значение invoice, поэтому печатается 101. Последняя строка ведёт себя именно так, потому что `let` запрещает изменение всех свойств ссылочного объекта. Переназначение копии меняет исходное значение invoice, поэтому печатается 100. Переназначение копии не меняет исходное значение invoice, поэтому печатается 100.

Вопрос 5 из 20

На проверку кода принесли этот фрагмент. Какой диагноз точнее всего объясняет проблему в части «Структуры»? Проверяется семантика значения и влияние let на изменяемые свойства.

struct User { var name: String }
let user = User(name: "A")
user.name = "B"

Причина сбоя в том, что `let` запрещает изменение всех свойств ссылочного объекта. Код не компилируется: экземпляр классы, связанный через let, нельзя мутировать даже при var-свойстве. Код не компилируется: экземпляр структуры, связанный через let, можно мутировать даже при var-свойстве. Код компилируется: экземпляр структуры, связанный через let, нельзя мутировать даже при var-свойстве. Код не компилируется: экземпляр структуры, связанный через let, нельзя мутировать даже при var-свойстве.

Вопрос 6 из 20

Какой разбор отличает реальную причину от сопутствующего риска? Здесь оценивается ссылочная идентичность и двухфазная инициализация.

class Parent {
    let id: Int
    init(id: Int) { self.id = id }
}

class Child: Parent {
    let name: String
    init(name: String) { self.name = name }
}

_ = Child(name: "Ada")

Инициализатор Child компилируется: после инициализации собственных свойств он обязан вызвать super.init(id:). Отчёт об ошибке должен указывать, что `let` запрещает изменение всех свойств ссылочного объекта. Инициализатор Child проходит проверку типов: после инициализации собственных свойств он обязан вызвать super.init(id:). Инициализатор Child не компилируется: после инициализации собственных свойств он обязан вызвать super.init(id:). Проблема возникает из-за правила: выбор между struct и class определяется только размером типа.

Вопрос 7 из 20

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Сосредоточьтесь на следующем: полная инициализация и место проверки инвариантов.

struct Account {
    let id: Int
    var name: String
    init(name: String) { self.name = name }
}

_ = Account(name: "Main")

Код компилируется: сохранённое свойство id не имеет значения к моменту завершения init. Отчёт об ошибке должен указывать, что `let` запрещает изменение всех свойств ссылочного объекта. Код компилируется и проходит проверку типов: сохранённое свойство id не имеет значения к моменту завершения init. Код не компилируется: сохранённое свойство id не имеет значения к моменту завершения init. Наблюдаемый симптом объясняется тем, что memberwise initializer автоматически синтезируется для любого класса.

Вопрос 8 из 20

Какую причину стоит указать в отчёте об ошибке, прежде чем предлагать исправление? Важно учесть: инженерный выбор между независимым значением и общей идентичностью.

final class Settings { var theme = "light" }
func preview(_ settings: Settings) {
    settings.theme = "dark"
}

Причина сбоя в том, что два экземпляра класса с равными полями имеют одну идентичность. Функция с именем preview неожиданно меняет общий объект; дефект в синтаксисе, а в скрытом разделяемом состоянии. Функция с именем preview неожиданно меняет общий объект; дефект не в синтаксисе, а в скрытом разделяемом состоянии. Первой нарушенной гарантией здесь является предположение, что memberwise initializer автоматически синтезируется для любого класса. Функция с именем preview неожиданно не меняет общий объект; дефект не в синтаксисе, а в скрытом разделяемом состоянии.

Вопрос 9 из 20

Какое решение одновременно исправляет код и оставляет понятную границу для дальнейших изменений? Проверяется семантика значения и влияние let на изменяемые свойства.

struct User { var name: String }
let user = User(name: "A")
user.name = "B"

Объявить переменную через var только если изменение экземпляра не входит в сценарий; иначе создавать новое значение с нужными данными. Достаточно изменить работу с `User`, исходя из того, что присваивание структуры разделяет идентичность исходного экземпляра. Правка сводится к локальному обходу: два экземпляра класса с равными полями имеют одну идентичность. Объявить переменную через var только если изменение экземпляра входит в сценарий; иначе создавать новое значение с нужными данными. Исправление — оставить контракт прежним и учитывать, что выбор между struct и class определяется только размером типа.

Вопрос 10 из 20

Какая правка решает проблему на том уровне, где она возникла? Сосредоточьтесь на следующем: ссылочная идентичность и двухфазная инициализация.

class Parent {
    let id: Int
    init(id: Int) { self.id = id }
}

class Child: Parent {
    let name: String
    init(name: String) { self.name = name }
}

_ = Child(name: "Ada")

Достаточно изменить работу с `Parent`, исходя из того, что `let` запрещает изменение всех свойств ссылочного объекта. Исправление — оставить контракт прежним и учитывать, что memberwise initializer автоматически синтезируется для любого класса. Передать необходимые данные родительскому инициализатору и вызвать super.init после инициализации собственных сохранённых свойств. Правка сводится к локальному обходу: выбор между struct и class определяется только размером типа. Сигнатуру можно не менять, если считать, что присваивание структуры разделяет идентичность исходного экземпляра.

Вопрос 11 из 20

Какая правка делает намерение кода явным и проверяемым? Важно учесть: полная инициализация и место проверки инвариантов.

struct Account {
    let id: Int
    var name: String
    init(name: String) { self.name = name }
}

_ = Account(name: "Main")

Достаточно изменить работу с `Account`, исходя из того, что memberwise initializer автоматически синтезируется для любого класса. Инициализировать каждое сохранённое свойство, дать ему значение при объявлении или сделать вычисляемым, если оно выводится из других данных. Исправление — оставить контракт прежним и учитывать, что два экземпляра класса с равными полями имеют одну идентичность. Правка сводится к локальному обходу: `let` запрещает изменение всех свойств ссылочного объекта. Нужно адаптировать только вызов `Account`, поскольку присваивание структуры разделяет идентичность исходного экземпляра.

Вопрос 12 из 20

Какая правка решает проблему на том уровне, где она возникла? Не упускайте из виду следующее: инженерный выбор между независимым значением и общей идентичностью.

final class Settings { var theme = "light" }
func preview(_ settings: Settings) {
    settings.theme = "dark"
}

Для безопасного предварительного просмотра передавать неизменяемое значение или создавать явную копию настроек, а не мутировать общий экземпляр. Исправление — оставить контракт прежним и учитывать, что выбор между struct и class определяется только размером типа. Для безопасного предварительного просмотра передавать неизменяемое значение или создавать явную копию настроек, а мутировать общий экземпляр. Достаточно изменить работу с `Settings`, исходя из того, что присваивание структуры разделяет идентичность исходного экземпляра. Нужно адаптировать только вызов `Settings`, поскольку `let` запрещает изменение всех свойств ссылочного объекта.

Вопрос 13 из 20

На какой границе входов, владения или времени жизни результат может стать другим? Проверяется семантика значения и влияние let на изменяемые свойства.

Копирование классы может быть оптимизировано, но наблюдаемая семантика должна оставаться независимой от реализации копирования. Копирование структуры не может быть оптимизировано, но наблюдаемая семантика должна оставаться независимой от реализации копирования. Пограничный случай связан с тем, что memberwise initializer автоматически синтезируется для любого класса. Граница применимости проходит там, где два экземпляра класса с равными полями имеют одну идентичность. Копирование структуры может быть оптимизировано, но наблюдаемая семантика должна оставаться независимой от реализации копирования.

Вопрос 14 из 20

Где заканчивается гарантия, продемонстрированная в обычном примере «Классы»? Сосредоточьтесь на следующем: ссылочная идентичность и двухфазная инициализация.

let у ссылки на класс запрещает переназначение ссылки, но не делает var-свойства объекта неизменяемыми. Правило меняется только в ситуации, где два экземпляра класса с равными полями имеют одну идентичность. let у ссылки на класс запрещает переназначение ссылки, но делает var-свойства объекта неизменяемыми. let у ссылки на структура запрещает переназначение ссылки, но не делает var-свойства объекта неизменяемыми. Ограничение определяется предположением, что memberwise initializer автоматически синтезируется для любого класса.

Вопрос 15 из 20

Какой пограничный случай способен изменить вывод, хотя синтаксис останется почти тем же? Здесь оценивается полная инициализация и место проверки инвариантов.

Failable initializer возвращает nil и позволяет отвергнуть некорректный вход до появления частично допустимого значения. Граница применимости проходит там, где memberwise initializer автоматически синтезируется для любого класса. Пограничный случай связан с тем, что `let` запрещает изменение всех свойств ссылочного объекта. Failable initializer не возвращает nil и позволяет отвергнуть некорректный вход до появления частично допустимого значения. Контрпример появляется, когда два экземпляра класса с равными полями имеют одну идентичность.

Вопрос 16 из 20

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

У структуры тоже могут быть ссылочные поля, поэтому поверхностная семантика значения гарантирует глубокую независимость всей объектной графики. Контрпример появляется, когда memberwise initializer автоматически синтезируется для любого класса. У структуры тоже могут быть ссылочные поля, поэтому поверхностная семантика значения не гарантирует глубокую независимость всей объектной графики. Ограничение определяется предположением, что два экземпляра класса с равными полями имеют одну идентичность. У классы тоже могут быть ссылочные поля, поэтому поверхностная семантика значения не гарантирует глубокую независимость всей объектной графики.

Вопрос 17 из 20

Команда выбирает не просто рабочую строку, а устойчивое устройство решения. Какой подход сильнее? Сосредоточьтесь на следующем: семантика значения и влияние let на изменяемые свойства.

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

Вопрос 18 из 20

Какое замечание на проверке кода поможет предотвратить повторение такого дефекта? Важно учесть: ссылочная идентичность и двухфазная инициализация.

Архитектуру стоит строить из предположения, что `let` запрещает изменение всех свойств ссылочного объекта. Класс оправдан при общей идентичности, наследовании или управляемом совместном состоянии; иначе структура обычно проще для рассуждения. При расширении системы нужно опираться на то, что memberwise initializer автоматически синтезируется для любого класса. Для устойчивого решения достаточно принять, что выбор между struct и class определяется только размером типа. Класс оправдан при общей идентичности, наследовании или управляемом совместном состоянии; иначе класс обычно проще для рассуждения.

Вопрос 19 из 20

Какое решение уменьшит число скрытых состояний и упростит расследование следующего сбоя? Не упускайте из виду следующее: полная инициализация и место проверки инвариантов.

При расширении системы нужно опираться на то, что memberwise initializer автоматически синтезируется для любого класса. Для устойчивого решения достаточно принять, что выбор между struct и class определяется только размером типа. Инварианты лучше устанавливать в init, чтобы остальной код не проверял заново, может ли объект находиться в запрещённом состоянии. Архитектуру стоит строить из предположения, что `let` запрещает изменение всех свойств ссылочного объекта. Инварианты лучше устанавливать в init, чтобы остальной код не проверял заново, не может ли объект находиться в запрещённом состоянии.

Вопрос 20 из 20

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

Любое изменяемое состояние требует класса, даже если значения должны копироваться независимо. Выбор определяется прежде всего размером типа: маленькие типы всегда должны быть структурами, большие — классами. Выбор struct или class должен исходить из идентичности и владения, а не из размера типа или привычки команды. Структура автоматически решает вопросы владения вложенными ссылочными объектами. Достаточно сравнить скорость одной операции; идентичность и совместное владение на архитектурный выбор не влияют.

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

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

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

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