💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом задании верен только один вариант. Фрагменты относятся к Scala 3; внешняя библиотека названа прямо в коде или условии.
Вопрос 1 из 20
В теме «Конструкторы» проследите типы и порядок вычисления. Какой вывод выдерживает такую проверку?
Scala Конструкторы: чтение фрагмента Копировать
class User(name: String, val id: Long):
val label = s"$name#$id"
val u = User("Ada", 7)
println(u.label)
Companion object имеет то же имя, что класс, и получает доступ к его закрытым членам; его часто используют для фабрик и `apply`.
Члены класса принадлежат экземпляру, а члены companion object вызываются без экземпляра; одинаковое имя не делает их виртуальным общим пространством состояния.
Параметр первичного конструктора становится полем только с `val` или `var`; обычный параметр доступен при инициализации, но не как публичный член.
Компилятор откладывает выбор типа до первого использования значения, поэтому объявленная форма выражения здесь ничего не ограничивает.
Любая конструкция, записанная через `val`, делает связанный объект неизменяемым, а все его методы — безопасными для параллельного вызова.
Вопрос 2 из 20
Какой дефект наиболее характерен для неверного применения «Конструкторы»?
Scala Конструкторы: изменившийся контекст Копировать
// Дополнительный контекст: После рефакторинга код по-прежнему компилируется, однако его статический тип стал шире.
class User(name: String, val id: Long):
val label = s"$name#$id"
val u = User("Ada", 7)
println(u.label)
Проверка границы должна учитывать, что глобальное изменяемое состояние внутри `object` превращает удобный доступ в скрытую зависимость и гонки между тестами.
Проверка границы должна учитывать, что добавление широкого типа или общего `case _` усиливает контроль, потому что компилятору становится известно больше допустимых вариантов.
Проверка границы должна учитывать, что фабрика в companion не отменяет возможности вызвать публичный конструктор и обойти проверку, если конструктор оставлен открытым.
Проверка границы должна учитывать, что разработчик может рассчитывать прочитать параметр позже и обнаружить отсутствие члена или ненужное раскрытие внутреннего состояния.
Проверка границы должна учитывать, что пограничное значение будет автоматически отклонено до выполнения, даже если код явно делает сужающее преобразование или приведение.
Вопрос 14 из 20
В контракте темы «Объекты-компаньоны» публичную сигнатуру слегка изменили, но большая часть вызывающего кода осталась прежней. Какой анализ пригоден для публичного API?
`Object` задаёт один модульный экземпляр на загрузчик классов и инициализируется при первом обращении; это удобно для функций и данных без изменяемого глобального состояния. Отдельная граница — разработчик может рассчитывать прочитать параметр позже и обнаружить отсутствие члена или ненужное раскрытие внутреннего состояния.
Companion object имеет то же имя, что класс, и получает доступ к его закрытым членам; его часто используют для фабрик и `apply`. Отдельная граница — фабрика в companion не отменяет возможности вызвать публичный конструктор и обойти проверку, если конструктор оставлен открытым.
Companion object имеет то же имя, что класс, и получает доступ к его закрытым членам; его часто используют для фабрик и `apply`. Отдельная граница — перенос изменяемого поля в companion случайно делает его общим для всех экземпляров.
Члены класса принадлежат экземпляру, а члены companion object вызываются без экземпляра; одинаковое имя не делает их виртуальным общим пространством состояния. Отдельная граница — фабрика в companion не отменяет возможности вызвать публичный конструктор и обойти проверку, если конструктор оставлен открытым.
Companion object имеет то же имя, что класс, и получает доступ к его закрытым членам; его часто используют для фабрик и `apply`. Отдельная граница — если код компилируется, дополнительные проверки вывода типов и поиска `given` не нужны.
Вопрос 15 из 20
Какой критерий готовности по теме «Объекты-компаньоны» действительно поймает повтор прежнего дефекта?
Companion object имеет то же имя, что класс, и получает доступ к его закрытым членам; его часто используют для фабрик и `apply`. Запустить пример один раз и не проверять порядок событий.
Закрывайте конструктор, когда инвариант должен обеспечиваться фабрикой, и возвращайте ошибку как данные, если вход внешней системы ненадёжен. В проверке воспроизвести ситуацию: фабрика в companion не отменяет возможности вызвать публичный конструктор и обойти проверку, если конструктор оставлен открытым.
Закрывайте конструктор, когда инвариант должен обеспечиваться фабрикой, и возвращайте ошибку как данные, если вход внешней системы ненадёжен. В проверке воспроизвести ситуацию: перенос изменяемого поля в companion случайно делает его общим для всех экземпляров.
Проверяйте владельца каждого состояния: данные конкретного объекта должны оставаться в экземпляре, общая неизменяемая конфигурация может жить в companion. В проверке воспроизвести ситуацию: фабрика в companion не отменяет возможности вызвать публичный конструктор и обойти проверку, если конструктор оставлен открытым.
В теме «Объекты-компаньоны» исправить один показанный вызов по рекомендации «Держите объект без состояния либо ограничивайте владение ресурсом; зависимости передавайте явно в код, который нужно тестировать». Общий контракт и прежнюю границу отдельно не воспроизводить.
Вопрос 18 из 20
При исправлении темы «Члены класса» какой вариант не переносит проблему в вызывающий код?
Scala Члены класса: решение на ревью Копировать
class Counter:
private var n = 0
def inc() = { n += 1; n }
val a, b = Counter()
println(a.inc() -> b.inc())
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Проверяйте владельца каждого состояния: данные конкретного объекта должны оставаться в экземпляре, общая неизменяемая конфигурация может жить в companion.
Перенести локальное состояние в общий `object`, чтобы все экземпляры наблюдали одно и то же значение без передачи зависимости.
Публикуйте только те параметры, которые являются частью состояния объекта; остальные оставляйте деталями построения.
Расширить спорный тип до `Any`, а точные проверки перенести во все места использования, чтобы не менять текущую реализацию.
Закрывайте конструктор, когда инвариант должен обеспечиваться фабрикой, и возвращайте ошибку как данные, если вход внешней системы ненадёжен.