💡 Инструкция: Выберите один ответ из пяти. Время — 70 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 5 тематических результатов и разбор всех ответов.
Вопрос 1 из 25
Как изменится состояние программы после выполнения кода по теме «Динамическое определение методов»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Динамическое определение методов Копировать
# Проследите выполнение и выберите точный результат.
class Scale
{ double: 2, triple: 3 }.each do |name, factor|
define_method(name) { |n| n * factor }
end
end
s = Scale.new
p [s.double(3), s.triple(5)]
Два динамических метода используют захваченные множители и возвращают 6 и 15. Это объясняется тем, что `public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне.
Объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле. Это объясняется тем, что `define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`.
Два динамических метода используют захваченные множители и возвращают 6 и 15. Это объясняется тем, что хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
При определении Child срабатывает `Base.inherited`, и список потомков содержит Child. Это объясняется тем, что `define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`.
Два динамических метода используют захваченные множители и возвращают 6 и 15. Это объясняется тем, что `define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`.
Вопрос 2 из 25
Какая трассировка кода по теме «Динамический вызов send» не теряет важную деталь? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Динамический вызов send Копировать
# Проследите выполнение и выберите точный результат.
class Box
def visible = :ok
private
def secret = :token
end
box = Box.new
p box.public_send(:visible)
begin
box.public_send(:secret)
rescue => e
p e.class
end
Объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле. Причина такого результата: `public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне.
Вызов `public_send(:visible)` работает, а попытка вызвать `:secret` через public_send поднимает NoMethodError. Причина такого результата: `public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне.
Класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой. Причина такого результата: `public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне.
Вызов `public_send(:visible)` работает, а попытка вызвать `:secret` через public_send поднимает NoMethodError. Причина такого результата: хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Вызов `public_send(:visible)` работает, а попытка вызвать `:secret` через public_send поднимает NoMethodError. Причина такого результата: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Вопрос 3 из 25
Не запуская пример, выберите точный итог для блока «Хуки классов». Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Хуки классов Копировать
# Проследите выполнение и выберите точный результат.
class Base
@children = []
class << self
attr_reader :children
def inherited(child)
@children << child
super
end
end
end
class Child < Base; end
p Base.children
При определении Child срабатывает `Base.inherited`, и список потомков содержит Child. Такой итог следует из правила: хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Два динамических метода используют захваченные множители и возвращают 6 и 15. Такой итог следует из правила: хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
При определении Child срабатывает `Base.inherited`, и список потомков содержит Child. Такой итог следует из правила: для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
При определении Child срабатывает `Base.inherited`, и список потомков содержит Child. Такой итог следует из правила: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле. Такой итог следует из правила: хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Вопрос 4 из 25
Какое описание результата точно соответствует показанному коду «Границы динамики»? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Границы динамики Копировать
# Проследите выполнение и выберите точный результат.
FIELDS = %i[name age].freeze
klass = Class.new do
FIELDS.each { |field| attr_accessor field }
end
obj = klass.new
obj.name = 'Ada'
p [obj.name, obj.respond_to?(:email)]
При определении Child срабатывает `Base.inherited`, и список потомков содержит Child. Механизм результата таков: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой. Механизм результата таков: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой. Механизм результата таков: хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой. Механизм результата таков: для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле. Механизм результата таков: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Вопрос 5 из 25
Что покажет выполнение этого фрагмента из раздела «Диагностика результата»? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Диагностика результата Копировать
# Проследите выполнение и выберите точный результат.
module Runner
def run(value) = value * 2
end
class Job
include Runner
end
method = Job.new.method(:run)
p [method.owner, method.arity, method.source_location&.first]
При определении Child срабатывает `Base.inherited`, и список потомков содержит Child. Наблюдение согласуется с тем, что для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле. Наблюдение согласуется с тем, что для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле. Наблюдение согласуется с тем, что динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой. Наблюдение согласуется с тем, что для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле. Наблюдение согласуется с тем, что хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Вопрос 6 из 25
Почему успешный пример ещё не доказывает надёжность решения «Динамическое определение методов»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Динамическое определение методов Копировать
# Обычный запуск проходит. Найдите скрытый риск.
class Scale
{ double: 2, triple: 3 }.each do |name, factor|
define_method(name) { |n| n * factor }
end
end
s = Scale.new
p [s.double(3), s.triple(5)]
Если переменная цикла меняется после создания блоков или все методы захватывают один изменяемый объект, реализации могут разделить нежелательное состояние. Причина — `public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне.
Если переменная цикла меняется после создания блоков или все методы захватывают один изменяемый объект, реализации могут разделить нежелательное состояние. Причина — `define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`.
Передача пользовательского имени в `send` превращает список разрешённых действий в доступ ко всему внутреннему интерфейсу объекта. Причина — `define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`.
Если переменная цикла меняется после создания блоков или все методы захватывают один изменяемый объект, реализации могут разделить нежелательное состояние. Причина — хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса. Причина — `define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`.
Вопрос 7 из 25
Какое допущение делает этот код по теме «Динамический вызов send» ненадёжным? Верный вариант не содержит частично правильной подмены причины или следствия.
Ruby Ruby — Динамический вызов send Копировать
# Обычный запуск проходит. Найдите скрытый риск.
class Box
def visible = :ok
private
def secret = :token
end
box = Box.new
p box.public_send(:visible)
begin
box.public_send(:secret)
rescue => e
p e.class
end
Передача пользовательского имени в `send` превращает список разрешённых действий в доступ ко всему внутреннему интерфейсу объекта. Этот риск связан с тем, что `public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне.
Проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения. Этот риск связан с тем, что `public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне.
Передача пользовательского имени в `send` превращает список разрешённых действий в доступ ко всему внутреннему интерфейсу объекта. Этот риск связан с тем, что динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Передача пользовательского имени в `send` превращает список разрешённых действий в доступ ко всему внутреннему интерфейсу объекта. Этот риск связан с тем, что хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса. Этот риск связан с тем, что `public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне.
Вопрос 8 из 25
Что в реализации по теме «Хуки классов» требует исправления прежде всего? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Хуки классов Копировать
# Обычный запуск проходит. Найдите скрытый риск.
class Base
@children = []
class << self
attr_reader :children
def inherited(child)
@children << child
super
end
end
end
class Child < Base; end
p Base.children
Хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека. Уязвимое место возникает потому, что динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения. Уязвимое место возникает потому, что хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека. Уязвимое место возникает потому, что для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса. Уязвимое место возникает потому, что хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека. Уязвимое место возникает потому, что хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Вопрос 9 из 25
Что в реализации по теме «Границы динамики» требует исправления прежде всего? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Границы динамики Копировать
# Обычный запуск проходит. Найдите скрытый риск.
FIELDS = %i[name age].freeze
klass = Class.new do
FIELDS.each { |field| attr_accessor field }
end
obj = klass.new
obj.name = 'Ada'
p [obj.name, obj.respond_to?(:email)]
Генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса. К такому сбою приводит правило: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека. К такому сбою приводит правило: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения. К такому сбою приводит правило: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса. К такому сбою приводит правило: для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса. К такому сбою приводит правило: хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Вопрос 10 из 25
Где в показанном решении «Диагностика результата» скрыт дефект, который проявится не на каждом входе? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Диагностика результата Копировать
# Обычный запуск проходит. Найдите скрытый риск.
module Runner
def run(value) = value * 2
end
class Job
include Runner
end
method = Job.new.method(:run)
p [method.owner, method.arity, method.source_location&.first]
Генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса. Источник риска: для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека. Источник риска: для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения. Источник риска: динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность.
Проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения. Источник риска: хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код.
Проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения. Источник риска: для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию.
Вопрос 11 из 25
Какой механизм объясняет и обычный, и граничный сценарий «Динамическое определение методов»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
`define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`. Поэтому объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле.
`define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`. Поэтому при определении Child срабатывает `Base.inherited`, и список потомков содержит Child.
`define_method` создаёт метод из блока и сохраняет его лексическое замыкание, в отличие от тела обычного `def`. Поэтому два динамических метода используют захваченные множители и возвращают 6 и 15.
Хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код. Поэтому два динамических метода используют захваченные множители и возвращают 6 и 15.
`public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне. Поэтому два динамических метода используют захваченные множители и возвращают 6 и 15.
Вопрос 12 из 25
Какое правило Ruby или Rails объясняет поведение в теме «Динамический вызов send»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
`public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне. Из этого следует, что класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой.
`public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне. Из этого следует, что вызов `public_send(:visible)` работает, а попытка вызвать `:secret` через public_send поднимает NoMethodError.
Динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность. Из этого следует, что вызов `public_send(:visible)` работает, а попытка вызвать `:secret` через public_send поднимает NoMethodError.
`public_send` соблюдает видимость, а `send` может вызвать private-метод; оба требуют строгого контроля имени, если оно пришло извне. Из этого следует, что объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле.
Хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код. Из этого следует, что вызов `public_send(:visible)` работает, а попытка вызвать `:secret` через public_send поднимает NoMethodError.
Вопрос 13 из 25
Какой механизм объясняет и обычный, и граничный сценарий «Хуки классов»? Верный вариант не содержит частично правильной подмены причины или следствия.
Хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код. Наблюдаемое следствие: два динамических метода используют захваченные множители и возвращают 6 и 15.
Динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность. Наблюдаемое следствие: при определении Child срабатывает `Base.inherited`, и список потомков содержит Child.
Для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию. Наблюдаемое следствие: при определении Child срабатывает `Base.inherited`, и список потомков содержит Child.
Хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код. Наблюдаемое следствие: при определении Child срабатывает `Base.inherited`, и список потомков содержит Child.
Хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код. Наблюдаемое следствие: объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле.
Вопрос 14 из 25
Какой контракт нужно помнить при ревью кода по теме «Границы динамики»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность. Именно поэтому объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле.
Динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность. Именно поэтому при определении Child срабатывает `Base.inherited`, и список потомков содержит Child.
Динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность. Именно поэтому класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой.
Для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию. Именно поэтому класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой.
Хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код. Именно поэтому класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой.
Вопрос 15 из 25
Какое общее правило связывает результат и риск в разделе «Диагностика результата»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию. Это правило даёт такой результат: объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле.
Динамика оправдана, когда сокращает повторение при сохранении конечного, наблюдаемого интерфейса; открытая генерация имён ухудшает анализ и безопасность. Это правило даёт такой результат: объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле.
Для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию. Это правило даёт такой результат: класс создаёт только методы из фиксированной схемы, а неизвестное имя остаётся обычной ошибкой.
Хуки `inherited`, `included`, `extended` и `method_added` вызываются в определённые моменты изменения классов и модулей и сами могут запустить новый код. Это правило даёт такой результат: объект сообщает, что метод `run` принадлежит модулю Runner и определён в текущем файле.
Для диагностики динамического вызова полезны `method`, `owner`, `source_location`, `respond_to?` и `ancestors`; одно наличие имени ещё не доказывает нужную реализацию. Это правило даёт такой результат: при определении Child срабатывает `Base.inherited`, и список потомков содержит Child.
Вопрос 16 из 25
Какой рефакторинг переводит правило «Динамическое определение методов» из договорённости в проверяемый контракт? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Динамическое определение методов Копировать
# Выберите изменение, которое исправляет причину.
class Scale
{ double: 2, triple: 3 }.each do |name, factor|
define_method(name) { |n| n * factor }
end
end
s = Scale.new
p [s.double(3), s.triple(5)]
В отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы. Так закрывается риск: если переменная цикла меняется после создания блоков или все методы захватывают один изменяемый объект, реализации могут разделить нежелательное состояние.
Генерировать конечный перечень методов при загрузке класса и тестировать каждое имя как обычный публичный контракт. Так закрывается риск: если переменная цикла меняется после создания блоков или все методы захватывают один изменяемый объект, реализации могут разделить нежелательное состояние.
Генерировать конечный перечень методов при загрузке класса и тестировать каждое имя как обычный публичный контракт. Так закрывается риск: передача пользовательского имени в `send` превращает список разрешённых действий в доступ ко всему внутреннему интерфейсу объекта.
Сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую. Так закрывается риск: если переменная цикла меняется после создания блоков или все методы захватывают один изменяемый объект, реализации могут разделить нежелательное состояние.
Генерировать конечный перечень методов при загрузке класса и тестировать каждое имя как обычный публичный контракт. Так закрывается риск: генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса.
Вопрос 18 из 25
Какой подход сохраняет намерение кода и устраняет дефект в теме «Хуки классов»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Хуки классов Копировать
# Выберите изменение, которое исправляет причину.
class Base
@children = []
class << self
attr_reader :children
def inherited(child)
@children << child
super
end
end
end
class Child < Base; end
p Base.children
Держать хуки короткими, вызывать super и защищать повторный вход, если хук меняет тот же класс. Такая правка нужна из-за риска: проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения.
Сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую. Такая правка нужна из-за риска: хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека.
Генерировать конечный перечень методов при загрузке класса и тестировать каждое имя как обычный публичный контракт. Такая правка нужна из-за риска: хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека.
Держать хуки короткими, вызывать super и защищать повторный вход, если хук меняет тот же класс. Такая правка нужна из-за риска: генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса.
Держать хуки короткими, вызывать super и защищать повторный вход, если хук меняет тот же класс. Такая правка нужна из-за риска: хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека.
Вопрос 19 из 25
Что следует изменить в решении «Границы динамики», чтобы закрыть исходный риск? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Границы динамики Копировать
# Выберите изменение, которое исправляет причину.
FIELDS = %i[name age].freeze
klass = Class.new do
FIELDS.each { |field| attr_accessor field }
end
obj = klass.new
obj.name = 'Ada'
p [obj.name, obj.respond_to?(:email)]
В отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы. Решение адресует следующий дефект: генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса.
Ограничивать динамический интерфейс схемой, создавать его один раз и публиковать документацию/типы для инструментов и разработчиков. Решение адресует следующий дефект: генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса.
Ограничивать динамический интерфейс схемой, создавать его один раз и публиковать документацию/типы для инструментов и разработчиков. Решение адресует следующий дефект: передача пользовательского имени в `send` превращает список разрешённых действий в доступ ко всему внутреннему интерфейсу объекта.
Сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую. Решение адресует следующий дефект: генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса.
Ограничивать динамический интерфейс схемой, создавать его один раз и публиковать документацию/типы для инструментов и разработчиков. Решение адресует следующий дефект: проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения.
Вопрос 20 из 25
Какое изменение устраняет причину проблемы в теме «Диагностика результата», а не маскирует симптом? Правильным считается только полностью согласованное утверждение.
В отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы. Именно эта мера закрывает риск: хук `method_added`, который сам определяет метод без защиты, вызывает рекурсию и переполнение стека.
В отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы. Именно эта мера закрывает риск: генерация методов из содержимого базы или запроса может бесконтрольно расширять singleton-классы и память процесса.
Ограничивать динамический интерфейс схемой, создавать его один раз и публиковать документацию/типы для инструментов и разработчиков. Именно эта мера закрывает риск: проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения.
Сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую. Именно эта мера закрывает риск: проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения.
В отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы. Именно эта мера закрывает риск: проверка только `respond_to?` пропускает неподходящую арность, видимость и контракт возвращаемого значения.
Вопрос 22 из 25
Чем дополнить базовый тест, чтобы проверить ограничение темы «Динамический вызов send»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Проверить переопределение и наследование: владелец динамического метода всё равно участвует в обычной цепочке поиска. Так проверяется решение: сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую.
Проверить методы, унаследованные от Object и Kernel: белый список должен исключать их, даже если они публичны. Так проверяется решение: сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую.
Проверить метод, созданный на C-уровне: `source_location` у него будет nil, что не означает отсутствие реализации. Так проверяется решение: сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую.
Проверить методы, унаследованные от Object и Kernel: белый список должен исключать их, даже если они публичны. Так проверяется решение: в отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы.
Проверить методы, унаследованные от Object и Kernel: белый список должен исключать их, даже если они публичны. Так проверяется решение: генерировать конечный перечень методов при загрузке класса и тестировать каждое имя как обычный публичный контракт.
Вопрос 23 из 25
Какую границу контракта «Хуки классов» нужно закрепить отдельным тестом? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Проверить переопределение и наследование: владелец динамического метода всё равно участвует в обычной цепочке поиска. Проверка относится к изменению: держать хуки короткими, вызывать super и защищать повторный вход, если хук меняет тот же класс.
Проверить наследование от подкласса: состояние, хранящееся в переменной экземпляра Base, не появляется автоматически у Child. Проверка относится к изменению: сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую.
Проверить наследование от подкласса: состояние, хранящееся в переменной экземпляра Base, не появляется автоматически у Child. Проверка относится к изменению: генерировать конечный перечень методов при загрузке класса и тестировать каждое имя как обычный публичный контракт.
Проверить метод, созданный на C-уровне: `source_location` у него будет nil, что не означает отсутствие реализации. Проверка относится к изменению: держать хуки короткими, вызывать super и защищать повторный вход, если хук меняет тот же класс.
Проверить наследование от подкласса: состояние, хранящееся в переменной экземпляра Base, не появляется автоматически у Child. Проверка относится к изменению: держать хуки короткими, вызывать super и защищать повторный вход, если хук меняет тот же класс.
Вопрос 24 из 25
Какой сценарий проверит не только результат, но и побочный эффект решения «Границы динамики»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Проверить метод, созданный на C-уровне: `source_location` у него будет nil, что не означает отсутствие реализации. Сценарий подтверждает надёжность решения: ограничивать динамический интерфейс схемой, создавать его один раз и публиковать документацию/типы для инструментов и разработчиков.
Проверить методы, унаследованные от Object и Kernel: белый список должен исключать их, даже если они публичны. Сценарий подтверждает надёжность решения: ограничивать динамический интерфейс схемой, создавать его один раз и публиковать документацию/типы для инструментов и разработчиков.
Проверить конфликт с уже существующим методом вроде `class`, `send` или `object_id` до генерации. Сценарий подтверждает надёжность решения: ограничивать динамический интерфейс схемой, создавать его один раз и публиковать документацию/типы для инструментов и разработчиков.
Проверить конфликт с уже существующим методом вроде `class`, `send` или `object_id` до генерации. Сценарий подтверждает надёжность решения: в отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы.
Проверить конфликт с уже существующим методом вроде `class`, `send` или `object_id` до генерации. Сценарий подтверждает надёжность решения: сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую.
Вопрос 25 из 25
Что следует добавить в набор проверок по теме «Диагностика результата», чтобы поймать редкий отказ? Правильным считается только полностью согласованное утверждение.
Проверить метод, созданный на C-уровне: `source_location` у него будет nil, что не означает отсутствие реализации. На этой границе проверяется мера: сопоставлять внешнюю команду с заранее заданным Hash из безопасных вызываемых объектов, а не отправлять строку напрямую.
Проверить метод, созданный на C-уровне: `source_location` у него будет nil, что не означает отсутствие реализации. На этой границе проверяется мера: в отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы.
Проверить методы, унаследованные от Object и Kernel: белый список должен исключать их, даже если они публичны. На этой границе проверяется мера: в отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы.
Проверить метод, созданный на C-уровне: `source_location` у него будет nil, что не означает отсутствие реализации. На этой границе проверяется мера: ограничивать динамический интерфейс схемой, создавать его один раз и публиковать документацию/типы для инструментов и разработчиков.
Проверить переопределение и наследование: владелец динамического метода всё равно участвует в обычной цепочке поиска. На этой границе проверяется мера: в отчёте о динамической ошибке записывать имя, владельца, арность и источник метода, не сериализуя чувствительные аргументы.