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

Протоколы и расширения

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

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

⏱ --:--

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

Вопрос 1 из 20

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

protocol Named { var name: String { get } }
struct User: Named { let name: String }
func printName(_ value: any Named) { print(value.name) }
printName(User(name: "Ada"))

Операция с `name` корректна, поскольку метод только из extension участвует в динамической диспетчеризации через existential. Для этого примера достаточно учесть, что требование протокола можно выполнить методом с более узким уровнем доступа. Структура удовлетворяет требованию get-свойства, и функция печатает «Ada». Структура удовлетворяет требованию get-свойства, и функция печатает «nil». Наблюдаемый результат определяется тем, что реализация по умолчанию всегда побеждает одноимённый метод конкретного типа.

Вопрос 2 из 20

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

extension Int {
    var squared: Int { self * self }
}
print(4.squared)

Расширение добавляет вычисляемое свойство, и код печатает 17. Фрагмент не требует отдельного условия: реализация по умолчанию всегда побеждает одноимённый метод конкретного типа. Последняя строка ведёт себя именно так, потому что композиция протоколов создаёт новый номинальный тип. Расширение добавляет вычисляемое свойство, и код печатает 16. Для этого примера достаточно учесть, что расширение может добавлять хранимые свойства существующему типу.

Вопрос 3 из 20

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

protocol Greeter { func greet() -> String }
extension Greeter { func greet() -> String { "default" } }
struct Person: Greeter {}
print(Person().greet())

Тип использует реализацию из расширения протокола и печатает «false». Тип не использует реализацию из расширения протокола и печатает «default». Для этого примера достаточно учесть, что расширение может добавлять хранимые свойства существующему типу. Операция с `greet` корректна, поскольку требование протокола можно выполнить методом с более узким уровнем доступа. Тип использует реализацию из расширения протокола и печатает «default».

Вопрос 4 из 20

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

protocol Readable { func read() -> String }
protocol Writable { func write(_ text: String) }
func sync(_ value: any Readable & Writable) { value.write(value.read()) }

Фрагмент не требует отдельного условия: требование протокола можно выполнить методом с более узким уровнем доступа. Для этого примера достаточно учесть, что реализация по умолчанию всегда побеждает одноимённый метод конкретного типа. Последняя строка ведёт себя именно так, потому что метод только из extension участвует в динамической диспетчеризации через existential. Параметр обязан одновременно соответствовать обоим протоколам; композиция не создаёт новый номинальный тип. Параметр обязан одновременно соответствовать обоим протоколам; композиция создаёт новый номинальный тип.

Вопрос 5 из 20

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

protocol Resettable { mutating func reset() }
struct Counter: Resettable {
    var value = 0
    func reset() { value = 0 }
}

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

Вопрос 6 из 20

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

extension String {
    var cachedLength = 0
}

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

Вопрос 7 из 20

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

protocol P {}
extension P { func value() -> String { "extension" } }
struct S: P { func value() -> String { "struct" } }
let x: any P = S()
print(x.value())

Отчёт об ошибке должен указывать, что расширение может добавлять хранимые свойства существующему типу. Наблюдаемый симптом объясняется тем, что композиция протоколов создаёт новый номинальный тип. Печатается «extension»: value является требованием протокола, поэтому вызов через existential статически выбирает расширение. Печатается «extension»: value не является требованием протокола, поэтому вызов через existential статически выбирает расширение. Проблема возникает из-за правила: требование протокола можно выполнить методом с более узким уровнем доступа.

Вопрос 8 из 20

Ожидаемое поведение не совпало с фактическим. В чём первая нарушенная гарантия? Не упускайте из виду следующее: объединение требований и классовое ограничение.

protocol A: AnyObject {}
struct Value: A {}

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

Вопрос 9 из 20

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

protocol Resettable { mutating func reset() }
struct Counter: Resettable {
    var value = 0
    func reset() { value = 0 }
}

Добавить mutating к реализации и требованию уже совместимого протокола либо вернуть новое значение вместо скрытой мутации. Нужно адаптировать только вызов `reset`, поскольку реализация по умолчанию всегда побеждает одноимённый метод конкретного типа. Добавить inout к реализации и требованию уже совместимого протокола либо вернуть новое значение вместо скрытой мутации. Достаточно изменить работу с `reset`, исходя из того, что расширение может добавлять хранимые свойства существующему типу. Исправление — оставить контракт прежним и учитывать, что композиция протоколов создаёт новый номинальный тип.

Вопрос 10 из 20

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

extension String {
    var cachedLength = 0
}

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

Вопрос 11 из 20

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

protocol P {}
extension P { func value() -> String { "extension" } }
struct S: P { func value() -> String { "struct" } }
let x: any P = S()
print(x.value())

Правка сводится к локальному обходу: метод только из extension участвует в динамической диспетчеризации через existential. Сигнатуру можно не менять, если считать, что реализация по умолчанию всегда побеждает одноимённый метод конкретного типа. Если нужна динамическая диспетчеризация через протокол, объявить метод требованием P и дать ему реализацию по умолчанию в extension. Нужно адаптировать только вызов `value`, поскольку композиция протоколов создаёт новый номинальный тип. Достаточно изменить работу с `value`, исходя из того, что требование протокола можно выполнить методом с более узким уровнем доступа.

Вопрос 12 из 20

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

protocol A: AnyObject {}
struct Value: A {}

Нужно адаптировать только вызов `Value`, поскольку требование протокола можно выполнить методом с более узким уровнем доступа. Использовать класс либо убрать классовое ограничение, если протокол не зависит от ссылочной идентичности. Сигнатуру можно не менять, если считать, что расширение может добавлять хранимые свойства существующему типу. Использовать класс либо убрать классовое ограничение, если протокол зависит от ссылочной идентичности. Использовать структура либо убрать классовое ограничение, если протокол не зависит от ссылочной идентичности.

Вопрос 13 из 20

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

Ограничение определяется предположением, что композиция протоколов создаёт новый номинальный тип. Требование get может удовлетворяться как let, var или computed property; требование get set уже не принимает read-only реализацию. Контрпример появляется, когда расширение может добавлять хранимые свойства существующему типу. Требование get не может удовлетворяться как let, var или computed property; требование get set уже не принимает read-only реализацию. Граница применимости проходит там, где требование протокола можно выполнить методом с более узким уровнем доступа.

Вопрос 14 из 20

Какое ограничение темы «Расширения» обязательно проверить отдельным граничным тестом? Проверяется поведение, которое можно добавить без изменения исходного объявления.

Пограничный случай связан с тем, что метод только из extension участвует в динамической диспетчеризации через existential. Граница применимости проходит там, где требование протокола можно выполнить методом с более узким уровнем доступа. Расширение не может добавлять соответствие протоколу, методы и вычисляемые свойства, но не новые designated initializers для чужого класса. Расширение может добавлять соответствие протоколу, методы и вычисляемые свойства, но не новые designated initializers для чужого класса. Правило меняется только в ситуации, где реализация по умолчанию всегда побеждает одноимённый метод конкретного типа.

Вопрос 15 из 20

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

Метод только в extension и метод-требование протокола имеют разную диспетчеризацию, хотя синтаксис вызова одинаков. Пограничный случай связан с тем, что расширение может добавлять хранимые свойства существующему типу. Правило меняется только в ситуации, где требование протокола можно выполнить методом с более узким уровнем доступа. Ограничение определяется предположением, что метод только из extension участвует в динамической диспетчеризации через existential. Граница применимости проходит там, где композиция протоколов создаёт новый номинальный тип.

Вопрос 16 из 20

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

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

Вопрос 17 из 20

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

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

Вопрос 18 из 20

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

В API и тестах следует исходить из правила: композиция протоколов создаёт новый номинальный тип. Для устойчивого решения достаточно принять, что реализация по умолчанию всегда побеждает одноимённый метод конкретного типа. Архитектуру стоит строить из предположения, что метод только из extension участвует в динамической диспетчеризации через existential. При расширении системы нужно опираться на то, что требование протокола можно выполнить методом с более узким уровнем доступа. Расширения хорошо группируют поведение по протоколам; свалка несвязанных утилит делает API труднее обнаруживать.

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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

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

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

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

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