Traits и композиция поведения — бесплатный тест онлайн

Вопрос 1 из 20

Во фрагменте проверяется тема «Примеси `trait`». Какое правило точнее всего объясняет поведение кода?

trait Named:
  def name: String
  def greeting = s"Hello, $name"
class User(val name: String) extends Named
println(User("Ada").greeting)

Порядок ветвей и шаблонов несущественен: перед выполнением Scala автоматически переставляет их от частных к общим. Trait задаёт контракт и может содержать реализацию; класс получает его члены через `extends` и `with`. Самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости. Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения. Любая конструкция, записанная через `val`, делает связанный объект неизменяемым, а все его методы — безопасными для параллельного вызова.

Вопрос 2 из 20

Для темы «Примеси `trait`» на какой границе это решение перестаёт быть достаточным?

// Дополнительный контекст: Публичную сигнатуру слегка изменили, но большая часть вызывающего кода осталась прежней.
trait Named:
  def name: String
  def greeting = s"Hello, $name"
class User(val name: String) extends Named
println(User("Ada").greeting)

Одного обычного запуска недостаточно, поскольку пограничное значение будет автоматически отклонено до выполнения, даже если код явно делает сужающее преобразование или приведение. Одного обычного запуска недостаточно, поскольку единственное последствие ошибки здесь — менее понятное сообщение компилятора; поведение собранной программы не меняется. Одного обычного запуска недостаточно, поскольку мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии. Одного обычного запуска недостаточно, поскольку самотип часто принимают за наследование или автоматическое создание зависимости, из-за чего жизненный цикл ресурса остаётся неуправляемым. Одного обычного запуска недостаточно, поскольку trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации.

Вопрос 3 из 20

При исправлении темы «Примеси `trait`» что следует изменить, чтобы следующий рефакторинг не вернул тот же риск?

trait Named:
  def name: String
  def greeting = s"Hello, $name"
class User(val name: String) extends Named
println(User("Ada").greeting)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Расширить спорный тип до `Any`, а точные проверки перенести во все места использования, чтобы не менять текущую реализацию. Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения. При конфликте переопределите метод в классе и явно вызовите нужные `super[Trait]`-реализации. Перенести зависимости примеси в singleton object, чтобы не объявлять их в контракте trait. Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность.

Вопрос 4 из 20

В контракте темы «Примеси `trait`» что следует оставить в проектном решении после этого изменения контекста?

Оставить в контракте правило «trait задаёт контракт и может содержать реализацию; класс получает его члены через `extends` и `with`»; проверяемое ограничение — «trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации». Оставить в контракте правило «mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения»; проверяемое ограничение — «мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии». Оставить в контракте правило «trait задаёт контракт и может содержать реализацию; класс получает его члены через `extends` и `with`»; проверяемое ограничение — «если основной сценарий прошёл, отрицательные и конкурентные случаи можно не проверять». Оставить в контракте правило «trait задаёт контракт и может содержать реализацию; класс получает его члены через `extends` и `with`»; проверяемое ограничение — «самотип часто принимают за наследование или автоматическое создание зависимости, из-за чего жизненный цикл ресурса остаётся неуправляемым». Оставить в контракте правило «самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости»; проверяемое ограничение — «trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации».

Вопрос 5 из 20

При проверке темы «Примеси `trait`» какой итог можно проверить автоматически или воспроизводимым примером?

Trait задаёт контракт и может содержать реализацию; класс получает его члены через `extends` и `with`. Не добавлять отрицательный сценарий: текущего успешного вызова достаточно. Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения. В проверке воспроизвести ситуацию: trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации. При конфликте переопределите метод в классе и явно вызовите нужные `super[Trait]`-реализации. В проверке воспроизвести ситуацию: trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации. В теме «Примеси `trait`» исправить один показанный вызов по рекомендации «Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность». Общий контракт и прежнюю границу отдельно не воспроизводить. Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения. В проверке воспроизвести ситуацию: самотип часто принимают за наследование или автоматическое создание зависимости, из-за чего жизненный цикл ресурса остаётся неуправляемым.

Вопрос 6 из 20

В теме «Подмешивание поведения» что в этом примере определяется семантикой Scala, а не соглашением автора?

trait A: def label = "A"
trait B: def label = "B"
class C extends A, B:
  override def label = super[A].label + super[B].label
println(C().label)

Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения. Выражение с побочным эффектом не может влиять на выведенный тип блока: компилятор всегда берёт первую содержательную строку. Неявное числовое преобразование всегда выбирает ближайший тип без потери диапазона, поэтому явная проверка границ не требуется. Линеаризация определяет порядок вызовов `super` в цепочке примесей; последняя добавленная примесь обычно оказывается первой в обработке. Самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости.

Вопрос 7 из 20

Для темы «Подмешивание поведения» после переноса кода в общий модуль проявилось скрытое допущение. Какое?

// Дополнительный контекст: После рефакторинга код по-прежнему компилируется, однако его статический тип стал шире.
trait A: def label = "A"
trait B: def label = "B"
class C extends A, B:
  override def label = super[A].label + super[B].label
println(C().label)

Мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии. Единственное последствие ошибки здесь — менее понятное сообщение компилятора; поведение собранной программы не меняется. Локальное изменение сигнатуры не способно повлиять на поиск перегрузки, given или вывод типа в вызывающем коде. Случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным. Trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации.

Вопрос 8 из 20

Как следует завершить ревью темы «Подмешивание поведения»?

trait A: def label = "A"
trait B: def label = "B"
class C extends A, B:
  override def label = super[A].label + super[B].label
println(C().label)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность. Ввести неявное преобразование между типами, чтобы вызывающий код продолжил компилироваться без явной миграции. При конфликте переопределите метод в классе и явно вызовите нужные `super[Trait]`-реализации. Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения. Спрятать несовместимость за `asInstanceOf`, сохранив прежнюю сигнатуру и добавив тест только для рабочего примера.

Вопрос 9 из 20

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

Линеаризация определяет порядок вызовов `super` в цепочке примесей; последняя добавленная примесь обычно оказывается первой в обработке. При этом учитывать: trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации. Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения. При этом учитывать: совпадение результата на одном наборе данных подтверждает все обещания публичного API. Самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости. При этом учитывать: случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным. Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения. При этом учитывать: случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным. Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения. При этом учитывать: мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии.

Вопрос 10 из 20

При проверке темы «Подмешивание поведения» как сформулировать защиту от регрессии без расплывчатого «работает как раньше»?

Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения. В проверке воспроизвести ситуацию: случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным. В теме «Подмешивание поведения» исправить один показанный вызов по рекомендации «Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность». Общий контракт и прежнюю границу отдельно не воспроизводить. При конфликте переопределите метод в классе и явно вызовите нужные `super[Trait]`-реализации. В проверке воспроизвести ситуацию: случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным. Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения. Проверить только ветвь без ошибки и принять изменение. При конфликте переопределите метод в классе и явно вызовите нужные `super[Trait]`-реализации. В проверке воспроизвести ситуацию: мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии.

Вопрос 11 из 20

Какой вывод о теме «Линеаризация» можно сделать без дополнительных допущений?

trait Base: def run = List("base")
trait A extends Base: abstract override def run = "A" :: super.run
trait B extends Base: abstract override def run = "B" :: super.run
class App extends Base, A, B
println(App().run.mkString("->"))

Любая конструкция, записанная через `val`, делает связанный объект неизменяемым, а все его методы — безопасными для параллельного вызова. Порядок ветвей и шаблонов несущественен: перед выполнением Scala автоматически переставляет их от частных к общим. Самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости. Линеаризация определяет порядок вызовов `super` в цепочке примесей; последняя добавленная примесь обычно оказывается первой в обработке. Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения.

Вопрос 12 из 20

Для темы «Линеаризация» какое последствие нельзя исключить одним успешным запуском?

Локальное изменение сигнатуры не способно повлиять на поиск перегрузки, given или вывод типа в вызывающем коде. Случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным. Мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии. Trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации. Единственное последствие ошибки здесь — менее понятное сообщение компилятора; поведение собранной программы не меняется.

Вопрос 13 из 20

При исправлении темы «Линеаризация» какая правка сохраняет полезную семантику и не расширяет обещания API?

trait Base: def run = List("base")
trait A extends Base: abstract override def run = "A" :: super.run
trait B extends Base: abstract override def run = "B" :: super.run
class App extends Base, A, B
println(App().run.mkString("->"))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность. Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения. Расширить спорный тип до `Any`, а точные проверки перенести во все места использования, чтобы не менять текущую реализацию. Используйте самотип для статического ограничения композиции, а реальные ресурсы передавайте конструктором или контекстным параметром. Перенести цепочку вызовов `super` в общий object: это зафиксирует порядок линеаризации для всех классов.

Вопрос 14 из 20

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

Линеаризация определяет порядок вызовов `super` в цепочке примесей; последняя добавленная примесь обычно оказывается первой в обработке. При этом учитывать: случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным. Линеаризация определяет порядок вызовов `super` в цепочке примесей; последняя добавленная примесь обычно оказывается первой в обработке. При этом учитывать: успешный запуск без ошибок гарантирует сохранение статического типа при будущих изменениях. Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения. При этом учитывать: trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации. Самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости. При этом учитывать: мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии. Линеаризация определяет порядок вызовов `super` в цепочке примесей; последняя добавленная примесь обычно оказывается первой в обработке. При этом учитывать: мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии.

Вопрос 15 из 20

При проверке темы «Линеаризация» какой пункт следует добавить в критерии приёмки изменения?

Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность. В проверке воспроизвести ситуацию: случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным. Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения. В проверке воспроизвести ситуацию: мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии. Линеаризация определяет порядок вызовов `super` в цепочке примесей; последняя добавленная примесь обычно оказывается первой в обработке. Сравнить вывод на одном наборе данных, не меняя условия выполнения. В теме «Линеаризация» исправить один показанный вызов по рекомендации «Используйте самотип для статического ограничения композиции, а реальные ресурсы передавайте конструктором или контекстным параметром». Общий контракт и прежнюю границу отдельно не воспроизводить. Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность. В проверке воспроизвести ситуацию: мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии.

Вопрос 16 из 20

В теме «Самотипы» код компилируется и запускается. Какое утверждение о его контракте остаётся верным?

trait Clock: def now: Long
trait Timed:
  this: Clock =>
  def stamp = now
class Service extends Timed, Clock:
  def now = 42L
println(Service().stamp)

Компилятор откладывает выбор типа до первого использования значения, поэтому объявленная форма выражения здесь ничего не ограничивает Mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения Trait задаёт контракт и может содержать реализацию; класс получает его члены через `extends` и `with` Самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости Любая конструкция, записанная через `val`, делает связанный объект неизменяемым, а все его методы — безопасными для параллельного вызова

Вопрос 17 из 20

Для темы «Самотипы» какой пограничный случай относится к контракту, а не только к стилю записи?

Самотип часто принимают за наследование или автоматическое создание зависимости, из-за чего жизненный цикл ресурса остаётся неуправляемым. Добавление широкого типа или общего `case _` усиливает контроль, потому что компилятору становится известно больше допустимых вариантов. Trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации. Мысленно читать `super` как прямой вызов родителя неверно: он следует линеаризованной цепочке, а не текстовой иерархии. Риск возникает только при `var`; `val`, `case class` и неизменяемая коллекция полностью исключают скрытое состояние и ошибочный контракт.

Вопрос 18 из 20

При исправлении темы «Самотипы» что здесь лучше исправить до объединения изменений?

trait Clock: def now: Long
trait Timed:
  this: Clock =>
  def stamp = now
class Service extends Timed, Clock:
  def now = 42L
println(Service().stamp)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения. Расширить спорный тип до `Any`, а точные проверки перенести во все места использования, чтобы не менять текущую реализацию. Перенести локальное состояние в общий `object`, чтобы все экземпляры наблюдали одно и то же значение без передачи зависимости. Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность. Используйте самотип для статического ограничения композиции, а реальные ресурсы передавайте конструктором или контекстным параметром.

Вопрос 19 из 20

В контракте темы «Самотипы» условия эксплуатации изменились, но синтаксис остался прежним. Что теперь важно удержать вместе?

В проектном решении сохранить утверждение «trait задаёт контракт и может содержать реализацию; класс получает его члены через `extends` и `with`» и риск «случайное совпадение имён может изменить поведение при добавлении новой примеси и сделать выбор реализации неочевидным». В проектном решении сохранить утверждение «mixin-композиция собирает поведение из нескольких traits; конфликт одинаковых конкретных методов требует явного переопределения» и риск «самотип часто принимают за наследование или автоматическое создание зависимости, из-за чего жизненный цикл ресурса остаётся неуправляемым». В проектном решении сохранить утверждение «самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости» и риск «trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации». В проектном решении сохранить утверждение «самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости» и риск «достаточно проверить путь без ошибки, поскольку остальные ветви следуют той же семантике». В проектном решении сохранить утверждение «самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости» и риск «самотип часто принимают за наследование или автоматическое создание зависимости, из-за чего жизненный цикл ресурса остаётся неуправляемым».

Вопрос 20 из 20

При проверке темы «Самотипы» что поможет соседнему модулю не повторить ту же ошибку?

Используйте самотип для статического ограничения композиции, а реальные ресурсы передавайте конструктором или контекстным параметром. В проверке воспроизвести ситуацию: trait с неявным изменяемым состоянием создаёт трудно видимые зависимости между примесями и усложняет порядок инициализации. В теме «Самотипы» исправить один показанный вызов по рекомендации «Держите traits небольшими, описывайте требуемые зависимости явно и предпочитайте чистые методы для переиспользуемого поведения». Общий контракт и прежнюю границу отдельно не воспроизводить. Для стекуемых модификаций делайте порядок примесей частью конструкции и покрывайте его тестом на фактическую последовательность. В проверке воспроизвести ситуацию: самотип часто принимают за наследование или автоматическое создание зависимости, из-за чего жизненный цикл ресурса остаётся неуправляемым. Самотип `this: Dependency =>` требует, чтобы trait был смешан с указанным типом, но не создаёт поле и не выполняет внедрение зависимости. Оставить единственный тест на штатный вход без проверки отмены и повтора. Используйте самотип для статического ограничения композиции, а реальные ресурсы передавайте конструктором или контекстным параметром. В проверке воспроизвести ситуацию: самотип часто принимают за наследование или автоматическое создание зависимости, из-за чего жизненный цикл ресурса остаётся неуправляемым.