💡 Инструкция: Выберите один ответ из пяти. Время — 55 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 4 тематических результатов и разбор всех ответов.
Вопрос 1 из 20
Как следует прочитать результат показанного примера «Цепочка предков»? Правильным считается только полностью согласованное утверждение.
Ruby Ruby — Цепочка предков Копировать
# Проследите выполнение и выберите точный результат.
module Taggable
def tag = :tag
end
class Base; end
class Document < Base
include Taggable
end
p Document.ancestors
p Document.new.method(:tag).owner
Метод находится в модуле Taggable, подключённом к Document, и возвращает `tag`. Это объясняется тем, что `method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super.
Метод находится в модуле Taggable, подключённом к Document, и возвращает `tag`. Это объясняется тем, что `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Метод находится в модуле Taggable, подключённом к Document, и возвращает `tag`. Это объясняется тем, что Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`. Это объясняется тем, что Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта. Это объясняется тем, что Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Вопрос 2 из 20
Как изменится состояние программы после выполнения кода по теме «Вызов родительской реализации через super»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Вызов родительской реализации через super Копировать
# Проследите выполнение и выберите точный результат.
class Parent
def greet(name) = "Hi, #{name}"
end
class Child < Parent
def greet(name)
super + '!'
end
end
p Child.new.greet('Ada')
Child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`. Причина такого результата: `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Вызов `find_by_name` превращается в пару `[:find, "name"]`, а `respond_to?` подтверждает тот же динамический контракт. Причина такого результата: `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`. Причина такого результата: Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта. Причина такого результата: `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`. Причина такого результата: переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки.
Вопрос 3 из 20
Проследите выполнение фрагмента. Какой результат верен для темы «Переопределение»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Переопределение Копировать
# Проследите выполнение и выберите точный результат.
class Base
def size(limit: nil) = 1
end
class Special < Base
def size(limit: nil) = 2
end
p [Base.new.size, Special.new.size]
Base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта. Такой итог следует из правила: переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки.
Child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`. Такой итог следует из правила: переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки.
Метод находится в модуле Taggable, подключённом к Document, и возвращает `tag`. Такой итог следует из правила: переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки.
Base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта. Такой итог следует из правила: `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта. Такой итог следует из правила: Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Вопрос 4 из 20
Как следует прочитать результат показанного примера «Динамический перехват method_missing»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Динамический перехват method_missing Копировать
# Проследите выполнение и выберите точный результат.
class Finder
def method_missing(name, *)
return [:find, name.to_s.delete_prefix('find_by_')] if name.start_with?('find_by_')
super
end
def respond_to_missing?(name, *)
name.start_with?('find_by_') || super
end
end
p Finder.new.find_by_name
p Finder.new.respond_to?(:find_by_name)
Base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта. Механизм результата таков: `method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super.
Вызов `find_by_name` превращается в пару `[:find, "name"]`, а `respond_to?` подтверждает тот же динамический контракт. Механизм результата таков: Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Вызов `find_by_name` превращается в пару `[:find, "name"]`, а `respond_to?` подтверждает тот же динамический контракт. Механизм результата таков: `method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super.
Вызов `find_by_name` превращается в пару `[:find, "name"]`, а `respond_to?` подтверждает тот же динамический контракт. Механизм результата таков: `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`. Механизм результата таков: `method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super.
Вопрос 5 из 20
Какое скрытое условие делает фрагмент «Цепочка предков» хрупким? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Цепочка предков Копировать
# Обычный запуск проходит. Найдите скрытый риск.
module Taggable
def tag = :tag
end
class Base; end
class Document < Base
include Taggable
end
p Document.ancestors
p Document.new.method(:tag).owner
Предположение «метод точно объявлен в классе» ведёт к исправлению не того слоя, если реализация пришла из mixin или prepend. Причина — Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Предположение «метод точно объявлен в классе» ведёт к исправлению не того слоя, если реализация пришла из mixin или prepend. Причина — `method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super.
Замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника. Причина — Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Предположение «метод точно объявлен в классе» ведёт к исправлению не того слоя, если реализация пришла из mixin или prepend. Причина — `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт. Причина — Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Вопрос 6 из 20
Что может сломаться при переносе этого решения «Вызов родительской реализации через super» в рабочую систему? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Вызов родительской реализации через super Копировать
# Обычный запуск проходит. Найдите скрытый риск.
class Parent
def greet(name) = "Hi, #{name}"
end
class Child < Parent
def greet(name)
super + '!'
end
end
p Child.new.greet('Ada')
Замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника. Этот риск связан с тем, что переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки.
Замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника. Этот риск связан с тем, что Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника. Этот риск связан с тем, что `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт. Этот риск связан с тем, что `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Предположение «метод точно объявлен в классе» ведёт к исправлению не того слоя, если реализация пришла из mixin или prepend. Этот риск связан с тем, что `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Вопрос 7 из 20
Какой рабочий сбой вероятнее всего связан именно с механизмом «Переопределение»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Переопределение Копировать
# Обычный запуск проходит. Найдите скрытый риск.
class Base
def size(limit: nil) = 1
end
class Special < Base
def size(limit: nil) = 2
end
p [Base.new.size, Special.new.size]
Широкий method_missing скрывает опечатки, ухудшает трассировки и делает объект будто бы отвечающим на методы, которых он не умеет выполнять. Уязвимое место возникает потому, что переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки.
Замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника. Уязвимое место возникает потому, что переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки.
Подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт. Уязвимое место возникает потому, что переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки.
Подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт. Уязвимое место возникает потому, что Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт. Уязвимое место возникает потому, что `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Вопрос 8 из 20
Базовый пример выглядит корректно. Что всё же нарушает контракт в блоке «Динамический перехват method_missing»? Правильным считается только полностью согласованное утверждение.
Ruby Ruby — Динамический перехват method_missing Копировать
# Обычный запуск проходит. Найдите скрытый риск.
class Finder
def method_missing(name, *)
return [:find, name.to_s.delete_prefix('find_by_')] if name.start_with?('find_by_')
super
end
def respond_to_missing?(name, *)
name.start_with?('find_by_') || super
end
end
p Finder.new.find_by_name
p Finder.new.respond_to?(:find_by_name)
Замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника. К такому сбою приводит правило: `method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super.
Подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт. К такому сбою приводит правило: `method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super.
Широкий method_missing скрывает опечатки, ухудшает трассировки и делает объект будто бы отвечающим на методы, которых он не умеет выполнять. К такому сбою приводит правило: `method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super.
Широкий method_missing скрывает опечатки, ухудшает трассировки и делает объект будто бы отвечающим на методы, которых он не умеет выполнять. К такому сбою приводит правило: `super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов.
Широкий method_missing скрывает опечатки, ухудшает трассировки и делает объект будто бы отвечающим на методы, которых он не умеет выполнять. К такому сбою приводит правило: Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки.
Вопрос 9 из 20
Какое правило Ruby или Rails объясняет поведение в теме «Цепочка предков»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки. Поэтому child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`.
`super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов. Поэтому метод находится в модуле Taggable, подключённом к Document, и возвращает `tag`.
Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки. Поэтому метод находится в модуле Taggable, подключённом к Document, и возвращает `tag`.
`method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super. Поэтому метод находится в модуле Taggable, подключённом к Document, и возвращает `tag`.
Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки. Поэтому base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта.
Вопрос 10 из 20
Какое правило остаётся верным, даже если вход и порядок вызовов изменятся, в теме «Вызов родительской реализации через super»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки. Из этого следует, что child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`.
`super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов. Из этого следует, что child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`.
`super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов. Из этого следует, что вызов `find_by_name` превращается в пару `[:find, "name"]`, а `respond_to?` подтверждает тот же динамический контракт.
Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки. Из этого следует, что child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`.
`super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов. Из этого следует, что base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта.
Вопрос 11 из 20
Какое общее правило связывает результат и риск в разделе «Переопределение»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки. Наблюдаемое следствие: base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта.
`super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов. Наблюдаемое следствие: base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта.
Переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки. Наблюдаемое следствие: child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`.
Переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки. Наблюдаемое следствие: метод находится в модуле Taggable, подключённом к Document, и возвращает `tag`.
Переопределение заменяет найденную реализацию для экземпляров подкласса; совместимая сигнатура сохраняет принцип подстановки. Наблюдаемое следствие: base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта.
Вопрос 12 из 20
Как сформулировать правило блока «Динамический перехват method_missing» без лишних обещаний? Верный вариант не содержит частично правильной подмены причины или следствия.
`method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super. Именно поэтому base#size возвращает 1, а Special#size — 2; вызов выбирается по фактическому классу объекта.
Ruby ищет метод по цепочке singleton-класс объекта, prepended-модули, класс, included-модули и предки; `ancestors` показывает основную часть этой цепочки. Именно поэтому вызов `find_by_name` превращается в пару `[:find, "name"]`, а `respond_to?` подтверждает тот же динамический контракт.
`method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super. Именно поэтому вызов `find_by_name` превращается в пару `[:find, "name"]`, а `respond_to?` подтверждает тот же динамический контракт.
`super` вызывает следующую реализацию того же метода; без скобок он передаёт исходные аргументы и блок, а `super()` не передаёт аргументов. Именно поэтому вызов `find_by_name` превращается в пару `[:find, "name"]`, а `respond_to?` подтверждает тот же динамический контракт.
`method_missing` вызывается после неудачного поиска метода; корректная реализация должна согласовываться с `respond_to_missing?` и делегировать неизвестные случаи через super. Именно поэтому child#greet добавляет восклицательный знак к результату Parent#greet с тем же аргументом и возвращает `Hi, Ada!`.
Вопрос 13 из 20
Какое изменение устраняет причину проблемы в теме «Цепочка предков», а не маскирует симптом? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Цепочка предков Копировать
# Выберите изменение, которое исправляет причину.
module Taggable
def tag = :tag
end
class Base; end
class Document < Base
include Taggable
end
p Document.ancestors
p Document.new.method(:tag).owner
Перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца. Так закрывается риск: предположение «метод точно объявлен в классе» ведёт к исправлению не того слоя, если реализация пришла из mixin или prepend.
Перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца. Так закрывается риск: замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника.
В обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт. Так закрывается риск: предположение «метод точно объявлен в классе» ведёт к исправлению не того слоя, если реализация пришла из mixin или prepend.
Перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца. Так закрывается риск: подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт.
Тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами. Так закрывается риск: предположение «метод точно объявлен в классе» ведёт к исправлению не того слоя, если реализация пришла из mixin или prepend.
Вопрос 14 из 20
Какое исправление уменьшает риск, не скрывая исходное поведение «Вызов родительской реализации через super»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Вызов родительской реализации через super Копировать
# Выберите изменение, которое исправляет причину.
class Parent
def greet(name) = "Hi, #{name}"
end
class Child < Parent
def greet(name)
super + '!'
end
end
p Child.new.greet('Ada')
Тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами. Это изменение устраняет проблему: замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника.
Перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца. Это изменение устраняет проблему: замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника.
В обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт. Это изменение устраняет проблему: подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт.
В обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт. Это изменение устраняет проблему: замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника.
В обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт. Это изменение устраняет проблему: предположение «метод точно объявлен в классе» ведёт к исправлению не того слоя, если реализация пришла из mixin или prepend.
Вопрос 15 из 20
Какое исправление уменьшает риск, не скрывая исходное поведение «Переопределение»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца. Такая правка нужна из-за риска: подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт.
Тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами. Такая правка нужна из-за риска: подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт.
В обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт. Такая правка нужна из-за риска: подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт.
Тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами. Такая правка нужна из-за риска: замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника.
Тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами. Такая правка нужна из-за риска: широкий method_missing скрывает опечатки, ухудшает трассировки и делает объект будто бы отвечающим на методы, которых он не умеет выполнять.
Вопрос 16 из 20
Какое инженерное решение лучше всего соответствует механизму «Динамический перехват method_missing»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Когда набор динамических методов конечен, сгенерировать их через define_method и оставить method_missing только для действительно открытого протокола. Решение адресует следующий дефект: широкий method_missing скрывает опечатки, ухудшает трассировки и делает объект будто бы отвечающим на методы, которых он не умеет выполнять.
Когда набор динамических методов конечен, сгенерировать их через define_method и оставить method_missing только для действительно открытого протокола. Решение адресует следующий дефект: замена `super` на `super()` при рефакторинге меняет передачу аргументов и поднимает ArgumentError только на ветке наследника.
Перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца. Решение адресует следующий дефект: широкий method_missing скрывает опечатки, ухудшает трассировки и делает объект будто бы отвечающим на методы, которых он не умеет выполнять.
Когда набор динамических методов конечен, сгенерировать их через define_method и оставить method_missing только для действительно открытого протокола. Решение адресует следующий дефект: подкласс, который сужает допустимые аргументы или меняет тип результата, может сломать вызывающий код, рассчитанный на базовый контракт.
В обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт. Решение адресует следующий дефект: широкий method_missing скрывает опечатки, ухудшает трассировки и делает объект будто бы отвечающим на методы, которых он не умеет выполнять.
Вопрос 17 из 20
Какой контрпример проверит реальную границу механизма «Цепочка предков»? Правильным считается только полностью согласованное утверждение.
Проверить singleton-метод конкретного экземпляра: он будет найден раньше всех методов класса. Этот сценарий проверяет исправление: тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами.
Проверить отсутствие следующей реализации: `super` тогда поднимает NoMethodError. Этот сценарий проверяет исправление: перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца.
Передать неожиданный, но допустимый для базового класса аргумент и убедиться, что подкласс не отвергает его без причины. Этот сценарий проверяет исправление: перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца.
Проверить singleton-метод конкретного экземпляра: он будет найден раньше всех методов класса. Этот сценарий проверяет исправление: перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца.
Проверить singleton-метод конкретного экземпляра: он будет найден раньше всех методов класса. Этот сценарий проверяет исправление: в обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт.
Вопрос 19 из 20
Какую границу контракта «Переопределение» нужно закрепить отдельным тестом? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Проверить singleton-метод конкретного экземпляра: он будет найден раньше всех методов класса. Проверка относится к изменению: тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами.
Передать неожиданный, но допустимый для базового класса аргумент и убедиться, что подкласс не отвергает его без причины. Проверка относится к изменению: тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами.
Проверить близкую опечатку и неизвестное имя: они должны дойти до обычного NoMethodError, а не вернуть правдоподобный мусор. Проверка относится к изменению: тестировать общий контракт на наборе реализаций, а различия подкласса описывать отдельными примерами.
Передать неожиданный, но допустимый для базового класса аргумент и убедиться, что подкласс не отвергает его без причины. Проверка относится к изменению: в обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт.
Передать неожиданный, но допустимый для базового класса аргумент и убедиться, что подкласс не отвергает его без причины. Проверка относится к изменению: перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца.
Вопрос 20 из 20
Какой случай покажет, что исправление «Динамический перехват method_missing» не держится на удачном входе? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Проверить singleton-метод конкретного экземпляра: он будет найден раньше всех методов класса. Сценарий подтверждает надёжность решения: когда набор динамических методов конечен, сгенерировать их через define_method и оставить method_missing только для действительно открытого протокола.
Проверить близкую опечатку и неизвестное имя: они должны дойти до обычного NoMethodError, а не вернуть правдоподобный мусор. Сценарий подтверждает надёжность решения: когда набор динамических методов конечен, сгенерировать их через define_method и оставить method_missing только для действительно открытого протокола.
Передать неожиданный, но допустимый для базового класса аргумент и убедиться, что подкласс не отвергает его без причины. Сценарий подтверждает надёжность решения: когда набор динамических методов конечен, сгенерировать их через define_method и оставить method_missing только для действительно открытого протокола.
Проверить близкую опечатку и неизвестное имя: они должны дойти до обычного NoMethodError, а не вернуть правдоподобный мусор. Сценарий подтверждает надёжность решения: в обёртке явно выбрать форму super и добавить тест с ключевыми аргументами и блоком, если они входят в контракт.
Проверить близкую опечатку и неизвестное имя: они должны дойти до обычного NoMethodError, а не вернуть правдоподобный мусор. Сценарий подтверждает надёжность решения: перед изменением метода смотреть `method(:name).owner`, `source_location` и ancestors, чтобы найти реального владельца.