Property wrappers — бесплатный тест онлайн

Вопрос 1 из 25

Определите не предполагаемое, а фактическое поведение примера «Основное значение wrappedValue». Важно учесть: преобразование доступа к свойству.

@propertyWrapper struct Clamped19 {
    private var value: Int
    var wrappedValue: Int {
        get { value }
        set { value = min(max(newValue, 0), 100) }
    }
    init(wrappedValue: Int) { value = min(max(wrappedValue, 0), 100) }
}
struct Score19 { @Clamped19 var value = 120 }
print(Score19().value)

Инициализатор обёртка нормализует начальное значение, поэтому печатается 100. Последняя строка ведёт себя именно так, потому что проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Для этого примера достаточно учесть, что setter обёртки не может иметь побочных эффектов кроме сохранения значения. Инициализатор обёртка нормализует начальное значение, поэтому печатается 101. Операция с `Clamped19` корректна, поскольку две обёртки одного типа автоматически разделяют одно хранилище.

Вопрос 2 из 25

Не запуская код, восстановите состояние значений после последней строки. Какой вывод верен для «Проецируемое значение projectedValue»? Проверяется синтез и назначение projectedValue.

@propertyWrapper struct Logged19<T> {
    var wrappedValue: T
    var projectedValue: String { "value=\(wrappedValue)" }
}
struct M19 { @Logged19 var count = 3 }
print(M19().$count)

Синтаксис $count обращается к projectedValue и печатает «nil». Для этого примера достаточно учесть, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Операция с `Logged19` корректна, поскольку обёртка свойства создаётся заново при каждом чтении свойства. Синтаксис $count обращается к projectedValue и печатает «value=3». Синтаксис $count обращается к projectedValue и печатает «value=4».

Вопрос 3 из 25

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

@propertyWrapper struct Boxed19<T> {
    final class Storage { var value: T; init(_ v: T) { value = v } }
    private var storage: Storage
    var wrappedValue: T { get { storage.value } set { storage.value = newValue } }
    init(wrappedValue: T) { storage = Storage(wrappedValue) }
}

Для этого примера достаточно учесть, что две обёртки одного типа автоматически разделяют одно хранилище. Операция с `Boxed19` корректна, поскольку `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Наблюдаемый результат определяется тем, что обёртка свойства создаётся заново при каждом чтении свойства. Обёртка помещает значение в общее ссылочное хранилище, поэтому копии структуры могут наблюдать одну и ту же мутацию. Обёртка помещает значение в общее ссылочное хранилище, поэтому копии классы могут наблюдать одну и ту же мутацию.

Вопрос 4 из 25

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

@propertyWrapper struct NonEmpty19 {
    private var value: String
    var wrappedValue: String {
        get { value }
        set { precondition(!newValue.isEmpty); value = newValue }
    }
    init(wrappedValue: String) { precondition(!wrappedValue.isEmpty); value = wrappedValue }
}

Для этого примера достаточно учесть, что проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Наблюдаемый результат определяется тем, что две обёртки одного типа автоматически разделяют одно хранилище. Операция с `NonEmpty19` корректна, поскольку setter обёртки не может иметь побочных эффектов кроме сохранения значения. Обёртка централизует требование непустой строки, но его нарушение завершает программу через precondition. Фрагмент не требует отдельного условия: `projectedValue` всегда имеет тот же тип, что и `wrappedValue`.

Вопрос 5 из 25

Что увидит разработчик после выполнения этого примера по теме «Проверка обёрток и скрытого хранилища»? Сосредоточьтесь на следующем: наблюдаемое поведение скрытого хранилища.

@propertyWrapper struct CountWrites19<T> {
    var wrappedValue: T { didSet { writes += 1 } }
    private(set) var writes = 0
    var projectedValue: Int { writes }
}
struct Model19 { @CountWrites19 var value = 0 }
var model19 = Model19(); model19.value = 1
print(model19.$value)

Последняя строка ведёт себя именно так, потому что setter обёртки не может иметь побочных эффектов кроме сохранения значения. Для этого примера достаточно учесть, что две обёртки одного типа автоматически разделяют одно хранилище. После одного присваивания проекция показывает 1. После одного присваивания проекция показывает 2. Фрагмент не требует отдельного условия: проверка синтезированного поля `_value` надёжнее проверки публичного контракта.

Вопрос 6 из 25

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

@propertyWrapper struct ReadOnly19 {
    let wrappedValue: Int
}
struct S19 { @ReadOnly19 var value = 1 }
var s19 = S19()
s19.value = 2

Код компилируется: wrappedValue доступен только для чтения, поэтому синтезированное свойство нельзя присвоить. Причина сбоя в том, что две обёртки одного типа автоматически разделяют одно хранилище. Код не компилируется: wrappedValue доступен только для чтения, поэтому синтезированное свойство можно присвоить. Код не компилируется: wrappedValue доступен только для чтения, поэтому синтезированное свойство нельзя присвоить. Проблема возникает из-за правила: setter обёртки не может иметь побочных эффектов кроме сохранения значения.

Вопрос 7 из 25

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

@propertyWrapper struct W19 { var wrappedValue: Int }
struct M219 { @W19 var value = 1 }
let m = M219()
print(m.$value)

Причина сбоя в том, что setter обёртки не может иметь побочных эффектов кроме сохранения значения. Код не компилируется: обёртка не объявляет projectedValue, поэтому $value не синтезируется. Код компилируется: обёртка не объявляет projectedValue, поэтому $value не синтезируется. Проблема возникает из-за правила: проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Код компилируется и проходит проверку типов: обёртка не объявляет projectedValue, поэтому $value не синтезируется.

Вопрос 8 из 25

Что в этом фрагменте нужно объяснить первым, чтобы дальнейшая правка не оказалась случайной? Важно учесть: скрытая модель хранения и её последствия.

@propertyWrapper
struct Boxed19<T> {
    final class Storage {
        var value: T
        init(_ value: T) { self.value = value }
    }
    private var storage: Storage
    var wrappedValue: T {
        get { storage.value }
        set { storage.value = newValue }
    }
    init(wrappedValue: T) { storage = Storage(wrappedValue) }
}

struct Settings19 { @Boxed19 var flag = false }
var first19 = Settings19()
var second19 = first19
second19.flag = true
print(first19.flag)

Проблема возникает из-за правила: обёртка свойства создаётся заново при каждом чтении свойства. Отчёт об ошибке должен указывать, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Печатается true: скрытое ссылочное хранилище нарушает ожидаемую независимость двух копий классы. Наблюдаемый симптом объясняется тем, что две обёртки одного типа автоматически разделяют одно хранилище. Печатается true: скрытое ссылочное хранилище нарушает ожидаемую независимость двух копий структуры.

Вопрос 9 из 25

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

@propertyWrapper
struct NonEmpty19 {
    private var value: String
    var wrappedValue: String {
        get { value }
        set {
            precondition(!newValue.isEmpty)
            value = newValue
        }
    }
    init(wrappedValue: String) {
        precondition(!wrappedValue.isEmpty)
        value = wrappedValue
    }
}

struct User19 { @NonEmpty19 var name = "" }
_ = User19()

Создание User19 аварийно завершится из-за пустого начального значения: обёртка не превращает неверный ввод в обрабатываемую ошибку. Отчёт об ошибке должен указывать, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Создание User19 аварийно завершится из-за пустого начального значения: обёртка превращает неверный ввод в обрабатываемую ошибку. Проблема возникает из-за правила: обёртка свойства создаётся заново при каждом чтении свойства. Наблюдаемый симптом объясняется тем, что две обёртки одного типа автоматически разделяют одно хранилище.

Вопрос 10 из 25

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

@propertyWrapper
struct CountWrites19<T> {
    var wrappedValue: T { didSet { writes += 1 } }
    private(set) var writes = 0
    var projectedValue: Int { writes }
}

struct Model19 { @CountWrites19 var value = 0 }

func testWrapper19() {
    let model = Model19()
    _ = model.value
    assert(model.$value == 1)
}

Чтение не является записью, поэтому ожидание 1 неверно; тест должен различать get и set. Чтение не является записью, поэтому ожидание 2 неверно; тест должен различать get и set. Проблема возникает из-за правила: проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Причина сбоя в том, что setter обёртки не может иметь побочных эффектов кроме сохранения значения. Чтение является записью, поэтому ожидание 1 неверно; тест должен различать get и set.

Вопрос 11 из 25

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

@propertyWrapper struct ReadOnly19 {
    let wrappedValue: Int
}
struct S19 { @ReadOnly19 var value = 1 }
var s19 = S19()
s19.value = 2

Добавить setter с ясной семантикой либо объявить внешнее свойство let, если изменение не предусмотрено. Достаточно изменить работу с `ReadOnly19`, исходя из того, что обёртка свойства создаётся заново при каждом чтении свойства. Сигнатуру можно не менять, если считать, что setter обёртки не может иметь побочных эффектов кроме сохранения значения. Правка сводится к локальному обходу: проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Нужно адаптировать только вызов `ReadOnly19`, поскольку две обёртки одного типа автоматически разделяют одно хранилище.

Вопрос 12 из 25

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

@propertyWrapper struct W19 { var wrappedValue: Int }
struct M219 { @W19 var value = 1 }
let m = M219()
print(m.$value)

Добавить projectedValue только если у обёртки есть полезный второй интерфейс; не создавать его ради формального удобства. Добавить projectedValue только если у обёртки есть полезный второй интерфейс; создавать его ради формального удобства. Достаточно изменить работу с `W19`, исходя из того, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Правка сводится к локальному обходу: обёртка свойства создаётся заново при каждом чтении свойства. Сигнатуру можно не менять, если считать, что проверка синтезированного поля `_value` надёжнее проверки публичного контракта.

Вопрос 13 из 25

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

@propertyWrapper
struct Boxed19<T> {
    final class Storage {
        var value: T
        init(_ value: T) { self.value = value }
    }
    private var storage: Storage
    var wrappedValue: T {
        get { storage.value }
        set { storage.value = newValue }
    }
    init(wrappedValue: T) { storage = Storage(wrappedValue) }
}

struct Settings19 { @Boxed19 var flag = false }
var first19 = Settings19()
var second19 = first19
second19.flag = true
print(first19.flag)

Достаточно изменить работу с `Boxed19`, исходя из того, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Исправление — оставить контракт прежним и учитывать, что две обёртки одного типа автоматически разделяют одно хранилище. Нужно адаптировать только вызов `Boxed19`, поскольку setter обёртки не может иметь побочных эффектов кроме сохранения значения. Либо реализовать копирование при записи, либо ясно сделать владельца ссылочным типом и притворяться семантика значений. Либо реализовать копирование при записи, либо явно сделать владельца ссылочным типом и не выдавать его за значение с независимым копированием.

Вопрос 14 из 25

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

@propertyWrapper
struct NonEmpty19 {
    private var value: String
    var wrappedValue: String {
        get { value }
        set {
            precondition(!newValue.isEmpty)
            value = newValue
        }
    }
    init(wrappedValue: String) {
        precondition(!wrappedValue.isEmpty)
        value = wrappedValue
    }
}

struct User19 { @NonEmpty19 var name = "" }
_ = User19()

Для пользовательского ввода предпочесть failable/throwing фабрику или обычную строку значения, а обёртка оставить для внутреннего доказанного инварианта. Для пользовательского ввода предпочесть failable/throwing фабрику или отдельный тип значения, а обёртка оставить для внутреннего доказанного инварианта. Нужно адаптировать только вызов `NonEmpty19`, поскольку проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Сигнатуру можно не менять, если считать, что обёртка свойства создаётся заново при каждом чтении свойства. Исправление — оставить контракт прежним и учитывать, что setter обёртки не может иметь побочных эффектов кроме сохранения значения.

Вопрос 15 из 25

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

@propertyWrapper
struct CountWrites19<T> {
    var wrappedValue: T { didSet { writes += 1 } }
    private(set) var writes = 0
    var projectedValue: Int { writes }
}

struct Model19 { @CountWrites19 var value = 0 }

func testWrapper19() {
    let model = Model19()
    _ = model.value
    assert(model.$value == 1)
}

Достаточно изменить работу с `CountWrites19`, исходя из того, что две обёртки одного типа автоматически разделяют одно хранилище. Правка сводится к локальному обходу: `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Сигнатуру можно не менять, если считать, что обёртка свойства создаётся заново при каждом чтении свойства. Нужно адаптировать только вызов `CountWrites19`, поскольку проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Проверять начальную инициализацию, последовательные записи, копирование владельца и поведение projectedValue отдельно.

Вопрос 16 из 25

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

Контрпример появляется, когда обёртка свойства создаётся заново при каждом чтении свойства. Правило меняется только в ситуации, где две обёртки одного типа автоматически разделяют одно хранилище. Ограничение определяется предположением, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Граница применимости проходит там, где проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Обёртка преобразует объявление свойства в скрытое хранилище _value и доступ через wrappedValue.

Вопрос 17 из 25

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

Тип projectedValue не обязан совпадать с wrappedValue и может предоставлять binding, валидатор или служебное состояние. Граница применимости проходит там, где проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Пограничный случай связан с тем, что setter обёртки не может иметь побочных эффектов кроме сохранения значения. Тип projectedValue не обязан совпадать с wrappedValue и не может предоставлять binding, валидатор или служебное состояние. Правило меняется только в ситуации, где две обёртки одного типа автоматически разделяют одно хранилище.

Вопрос 18 из 25

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

Контрпример появляется, когда проверка синтезированного поля `_value` надёжнее проверки публичного контракта. Ограничение определяется предположением, что обёртка свойства создаётся заново при каждом чтении свойства. Обёртка свойства способна изменить семантику копирования и время жизни свойства, хотя объявление выглядит обычным. Правило меняется только в ситуации, где `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Граница применимости проходит там, где setter обёртки не может иметь побочных эффектов кроме сохранения значения.

Вопрос 19 из 25

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

Граница применимости проходит там, где две обёртки одного типа автоматически разделяют одно хранилище. Обёртка может сделать обычный синтезированный init throwing только потому, что валидация может не пройти. Пограничный случай связан с тем, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Правило меняется только в ситуации, где обёртка свойства создаётся заново при каждом чтении свойства. Обёртка не может сделать обычный синтезированный init throwing только потому, что валидация может не пройти.

Вопрос 20 из 25

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

Граница применимости проходит там, где обёртка свойства создаётся заново при каждом чтении свойства. Тест только внешнего значения не может пропустить ошибку в скрытом счётчике, уведомлении или политике хранения. Ограничение определяется предположением, что две обёртки одного типа автоматически разделяют одно хранилище. Тест только внешнего значения может пропустить ошибку в скрытом счётчике, уведомлении или политике хранения. Контрпример появляется, когда `projectedValue` всегда имеет тот же тип, что и `wrappedValue`.

Вопрос 21 из 25

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

Тяжёлый ввод-вывод уместно прятать в setter обёртки: обычное присваивание должно запускать всю работу незаметно для вызывающего кода. Надёжнее обращаться к синтезированному полю `_value` напрямую, чем проверять поведение свойства. Обёртка свойства подходит для повторяемой локальной политики хранения, но не должна скрывать тяжёлый ввод-вывод за обычным присваиванием. Экземпляр обёртки создаётся заново при каждом чтении, поэтому хранить в нём состояние бессмысленно. Публичный контракт обёртки обязан возвращать один и тот же тип через `wrappedValue` и `projectedValue`.

Вопрос 22 из 25

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

Проекция должна иметь понятную роль в API; загадочный $-интерфейс без документации ухудшает читаемость. Проекция не должна иметь понятную роль в API; загадочный $-интерфейс без документации ухудшает читаемость. Архитектуру стоит строить из предположения, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. При расширении системы нужно опираться на то, что две обёртки одного типа автоматически разделяют одно хранилище. Главным проектным принципом здесь является утверждение, что setter обёртки не может иметь побочных эффектов кроме сохранения значения.

Вопрос 23 из 25

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

Для устойчивого решения достаточно принять, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. В API и тестах следует исходить из правила: обёртка свойства создаётся заново при каждом чтении свойства. Архитектуру стоит строить из предположения, что две обёртки одного типа автоматически разделяют одно хранилище. При выборе state-обёртка нужно проверить владение, потоковую безопасность и момент уведомления, а только удобство синтаксиса. При выборе обёртки состояния нужно проверить владение, потоковую безопасность и момент уведомления, а не только удобство синтаксиса.

Вопрос 24 из 25

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

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

Вопрос 25 из 25

Какое замечание на проверке кода поможет предотвратить повторение такого дефекта? Проверяется наблюдаемое поведение скрытого хранилища.

Архитектуру стоит строить из предположения, что проверка синтезированного поля `_value` надёжнее проверки публичного контракта. При расширении системы нужно опираться на то, что обёртка свойства создаётся заново при каждом чтении свойства. Главным проектным принципом здесь является утверждение, что `projectedValue` всегда имеет тот же тип, что и `wrappedValue`. Для устойчивого решения достаточно принять, что setter обёртки не может иметь побочных эффектов кроме сохранения значения. Для сложного обёртка полезны прямые тесты самой обёртки и интеграционные тесты синтезированного свойства.