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

Свойства и методы

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

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

⏱ --:--

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

Вопрос 1 из 20

Как поведёт себя программа в этом коротком сценарии, связанном с «Хранимые свойства»? Важно учесть: различие свойств экземпляра и типа, а также мутация value type.

@MainActor
struct Cache {
    static var hits = 0
    var key: String
}

var cache = Cache(key: "x")
Cache.hits += 1
print(cache.key, Cache.hits)

Фрагмент не требует отдельного условия: наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства. key принадлежит экземпляру, а hits — не типу; код печатает «x 1». key принадлежит экземпляру, а hits — типу; код печатает «x 1». Наблюдаемый результат определяется тем, что метод типа имеет неявный доступ к свойствам конкретного экземпляра. key принадлежит экземпляру, а hits — типу; код печатает «x 2».

Вопрос 2 из 20

Где окажется состояние программы после выполнения всех показанных операций? Не упускайте из виду следующее: отсутствие отдельного хранилища и контракт get/set.

struct Rectangle {
    var width: Double
    var height: Double
    var area: Double { width * height }
}
var r = Rectangle(width: 3, height: 4)
r.width = 5
print(r.area)

area вычисляется при каждом чтении из текущих width и height, поэтому печатается 20. Наблюдаемый результат определяется тем, что наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства. Фрагмент не требует отдельного условия: вычисляемое свойство обязательно хранит отдельное значение в экземпляре. Последняя строка ведёт себя именно так, потому что `static` и `class` одинаково разрешают переопределение в наследнике. area вычисляется при каждом чтении из текущих width и height, поэтому печатается 21.

Вопрос 3 из 20

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

struct Meter {
    var value = 0 {
        willSet { print("next", newValue) }
        didSet { print("old", oldValue) }
    }
}
var m = Meter()
m.value = 2

При присваивании сначала печатается «next 2», затем «old 1». Операция с `Meter` корректна, поскольку ленивое свойство можно читать из неизменяемого экземпляра структуры без мутации. Для этого примера достаточно учесть, что `static` и `class` одинаково разрешают переопределение в наследнике. При присваивании сначала печатается «next 2», затем «old 0». При присваивании сначала печатается «next 3», затем «old 0».

Вопрос 4 из 20

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

@MainActor
struct ID {
    private static var next = 0
    static func make() -> Int {
        next += 1
        return next
    }
}

print(ID.make(), ID.make())

Статический метод структуры меняет статическое состояние и возвращает 1, затем 2. Статический метод структуры меняет статическое состояние и возвращает 1, затем 3. Статический метод структуры меняет статическое состояние и возвращает 2, затем 2. Статический метод классы меняет статическое состояние и возвращает 1, затем 2. Наблюдаемый результат определяется тем, что `static` и `class` одинаково разрешают переопределение в наследнике.

Вопрос 5 из 20

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

struct Session {
    let id: Int
    var token: String
}
let s = Session(id: 1, token: "a")
s.token = "b"

Причина сбоя в том, что `static` и `class` одинаково разрешают переопределение в наследнике. Несмотря на var у token, экземпляр структуры связан через let, поэтому изменение свойства разрешено. Первой нарушенной гарантией здесь является предположение, что ленивое свойство можно читать из неизменяемого экземпляра структуры без мутации. Несмотря на var у token, экземпляр классы связан через let, поэтому изменение свойства запрещено. Несмотря на var у token, экземпляр структуры связан через let, поэтому изменение свойства запрещено.

Вопрос 6 из 20

Разработчик видит симптом, но ищет первопричину. Какое объяснение выдерживает проверку кодом? Важно учесть: отсутствие отдельного хранилища и контракт get/set.

struct Temperature {
    var celsius: Double
    var fahrenheit: Double {
        get { celsius * 9 / 5 + 32 }
    }
}
var t = Temperature(celsius: 0)
t.fahrenheit = 68

Присваивание компилируется: computed property определяет только get и является доступным лишь для чтения. Присваивание компилируется и проходит проверку типов: computed property определяет только get и является доступным лишь для чтения. Присваивание не компилируется: computed property определяет только get и является доступным лишь для чтения. Причина сбоя в том, что `static` и `class` одинаково разрешают переопределение в наследнике. Проблема возникает из-за правила: вычисляемое свойство обязательно хранит отдельное значение в экземпляре.

Вопрос 7 из 20

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

struct Clamped {
    var value = 0 {
        didSet { if value < 0 { value = 0 } }
    }
}
var c = Clamped()
c.value = -1
print(c.value)

didSet может скорректировать значение; повторное присваивание внутри наблюдателя вызывает наблюдатель рекурсивно, итог равен 0. didSet может скорректировать значение; повторное присваивание внутри наблюдателя не вызывает наблюдатель рекурсивно, итог равен 0. Причина сбоя в том, что наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства. Проблема возникает из-за правила: метод типа имеет неявный доступ к свойствам конкретного экземпляра. didSet может скорректировать значение; повторное присваивание внутри наблюдателя не вызывает наблюдатель рекурсивно, итог равен 1.

Вопрос 8 из 20

Что именно делает этот фрагмент неверным или неочевидным с точки зрения «Методы типа»? Важно учесть: диспетчеризация методов типа и цена общего состояния.

class Base {
    static func label() -> String { "base" }
}

class Child: Base {
    override class func label() -> String { "child" }
}

_ = Child.label()

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

Вопрос 9 из 20

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

struct Session {
    let id: Int
    var token: String
}
let s = Session(id: 1, token: "a")
s.token = "b"

Создать новый Session либо хранить экземпляр в var, если мутация токена действительно не требуется. Создать новый Session либо хранить экземпляр в var, если мутация токена действительно требуется. Нужно адаптировать только вызов `Session`, поскольку ленивое свойство можно читать из неизменяемого экземпляра структуры без мутации. Исправление — оставить контракт прежним и учитывать, что метод типа имеет неявный доступ к свойствам конкретного экземпляра. Достаточно изменить работу с `Session`, исходя из того, что наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства.

Вопрос 10 из 20

Что следует изменить, чтобы исправить первопричину, а не подогнать ожидаемый результат? Сосредоточьтесь на следующем: отсутствие отдельного хранилища и контракт get/set.

struct Temperature {
    var celsius: Double
    var fahrenheit: Double {
        get { celsius * 9 / 5 + 32 }
    }
}
var t = Temperature(celsius: 0)
t.fahrenheit = 68

Правка сводится к локальному обходу: метод типа имеет неявный доступ к свойствам конкретного экземпляра. Добавить осмысленный setter, который обновляет celsius, либо оставить свойство read-only и изменять базовое состояние напрямую. Сигнатуру можно не менять, если считать, что наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства. Нужно адаптировать только вызов `Temperature`, поскольку вычисляемое свойство обязательно хранит отдельное значение в экземпляре. Исправление — оставить контракт прежним и учитывать, что `static` и `class` одинаково разрешают переопределение в наследнике.

Вопрос 11 из 20

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

struct Clamped {
    var value = 0 {
        didSet { if value < 0 { value = 0 } }
    }
}
var c = Clamped()
c.value = -1
print(c.value)

Для сложной валидации предпочесть метод или закрытый setter: наблюдатели должны оставаться короткими и предсказуемыми. Нужно адаптировать только вызов `Clamped`, поскольку вычисляемое свойство обязательно хранит отдельное значение в экземпляре. Для сложной валидации предпочесть метод или закрытый setter: наблюдатели не должны оставаться короткими и предсказуемыми. Исправление — оставить контракт прежним и учитывать, что `static` и `class` одинаково разрешают переопределение в наследнике. Достаточно изменить работу с `Clamped`, исходя из того, что ленивое свойство можно читать из неизменяемого экземпляра структуры без мутации.

Вопрос 12 из 20

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

class Base {
    static func label() -> String { "base" }
}

class Child: Base {
    override class func label() -> String { "child" }
}

_ = Child.label()

Исправление — оставить контракт прежним и учитывать, что вычисляемое свойство обязательно хранит отдельное значение в экземпляре. Если нужна полиморфная диспетчеризация, объявить базовый метод через struct func и переопределить его как override class func; static оставить для окончательного поведения. Если нужна полиморфная диспетчеризация, объявить базовый метод через class func и переопределить его как override class func; static оставить для окончательного поведения. Если нужна полиморфная диспетчеризация, объявить базовый метод через class func и переопределить его как override class func; class оставить для окончательного поведения. Достаточно изменить работу с `Base`, исходя из того, что `static` и `class` одинаково разрешают переопределение в наследнике.

Вопрос 13 из 20

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

Граница применимости проходит там, где ленивое свойство можно читать из неизменяемого экземпляра структуры без мутации. Lazy stored property инициализируется при первом доступе и потому должна быть var, даже если вычисленное значение затем не меняется. Правило меняется только в ситуации, где наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства. Пограничный случай связан с тем, что метод типа имеет неявный доступ к свойствам конкретного экземпляра. Lazy stored property инициализируется при первом доступе и потому не должна быть var, даже если вычисленное значение затем не меняется.

Вопрос 14 из 20

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

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

Вопрос 15 из 20

На какой границе входов, владения или времени жизни результат может стать другим? Проверяется порядок willSet/didSet и границы побочных эффектов.

Контрпример появляется, когда метод типа имеет неявный доступ к свойствам конкретного экземпляра. Ограничение определяется предположением, что ленивое свойство можно читать из неизменяемого экземпляра структуры без мутации. Наблюдатели сохранённого свойства обычно вызываются во время собственной инициализации типа. Граница применимости проходит там, где наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства. Наблюдатели сохранённого свойства обычно не вызываются во время собственной инициализации типа.

Вопрос 16 из 20

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

static связывает член с конкретным типом, а struct допускает переопределение только для классов. static связывает член с конкретным типом, а class допускает переопределение только для классов. Правило меняется только в ситуации, где наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства. class связывает член с конкретным типом, а class допускает переопределение только для классов. Ограничение определяется предположением, что вычисляемое свойство обязательно хранит отдельное значение в экземпляре.

Вопрос 17 из 20

Что должно определять архитектуру этого участка, когда появятся новые входы и владельцы? Важно учесть: различие свойств экземпляра и типа, а также мутация value type.

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

Вопрос 18 из 20

Что должно определять архитектуру этого участка, когда появятся новые входы и владельцы? Здесь оценивается отсутствие отдельного хранилища и контракт get/set.

При расширении системы нужно опираться на то, что метод типа имеет неявный доступ к свойствам конкретного экземпляра. Для устойчивого решения достаточно принять, что вычисляемое свойство обязательно хранит отдельное значение в экземпляре. Computed property уместно для производного значения, когда его всегда можно восстановить из источника истины. Computed property уместно для производного значения, когда его всегда нельзя восстановить из источника истины. Архитектуру стоит строить из предположения, что наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства.

Вопрос 19 из 20

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

Архитектуру стоит строить из предположения, что наблюдатели `willSet` и `didSet` вызываются при первичной инициализации свойства. Скрытые побочные эффекты в didSet затрудняют тестирование; особенно опасны сеть, диск и уведомления из наблюдателя. При расширении системы нужно опираться на то, что метод типа имеет неявный доступ к свойствам конкретного экземпляра. Главным проектным принципом здесь является утверждение, что ленивое свойство можно читать из неизменяемого экземпляра структуры без мутации. Для устойчивого решения достаточно принять, что вычисляемое свойство обязательно хранит отдельное значение в экземпляре.

Вопрос 20 из 20

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

Глобальное изменяемое состояние за class API удобно, но требует синхронизации и явной стратегии сброса в тестах. Глобальное изменяемое состояние за static API удобно, но не требует синхронизации и явной стратегии сброса в тестах. Глобальное изменяемое состояние за static API удобно, но требует синхронизации и явной стратегии сброса в тестах. Глобальное изменяемое состояние за static API удобно, но требует синхронизации и неявной стратегии сброса в тестах. Архитектуру стоит строить из предположения, что вычисляемое свойство обязательно хранит отдельное значение в экземпляре.

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

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

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

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