Объектное программирование Perl — бесплатный тест онлайн

Вопрос 1 из 25

Как точнее всего описать действие фрагмента с `$class`, `%arg` и `@_`?

sub new { my ($class,%arg)=@_; return bless { %arg }, $class }

Bless связывает ссылку с именем класса; конструктор остаётся обычной подпрограммой и должен сам проверить данные. Показанная версия изначально работает как исправленная: Используется фактический класс вызова, поэтому подкласс сохраняется. Bless связывает копию с именем класса; конструктор остаётся обычной подпрограммой и должен сам проверить данные. В этой версии кода возникает другой результат: Жёстко заданный Base ломает наследование: вызов Child->new вернёт объект Base. Bless связывает ссылку с именем класса; конструктор остаётся обычной подпрограммой и не должен сам проверить данные.

Вопрос 2 из 25

Как завершится этот код по правилам Perl 5.40?

sub name { my ($self)=@_; return $self->{name} }
say $obj->name;

Фрагмент «Методы» завершится ошибкой до получения описанного результата; показанные операции в этом контексте недопустимы. Стрелочный вызов передаёт объект первым аргументом метода. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Динамический вызов ограничен явным набором допустимых операций. Поведение кода сводится к одной границе механизма: can проверяет наличие метода и возвращает ссылку на код, но не подтверждает его прикладной контракт. Показанный участок сработает иначе: Непроверенное имя метода позволяет вызвать любой доступный метод объекта и расширяет поверхность атаки.

Вопрос 3 из 25

Какой вывод следует непосредственно из операций примера «Наследование»?

package Child; our @ISA=('Parent');
sub run { my $self=shift; $self->SUPER::run(@_) }

SUPER::run начинает поиск в родителях текущего пакета, а объект остаётся тем же. В показанном коде «Наследование» проявляется другой эффект: прямой вызов конкретного родителя обходит переопределения и затрудняет множественное наследование. Для результата здесь достаточно учесть лишь такое условие: mro 'c3' меняет порядок поиска при ромбовидном наследовании и должен быть общим решением иерархии, а не локальной заплатой. При выполнении первым проявится другое последствие: Прямой вызов конкретного родителя обходит переопределения и затрудняет множественное наследование. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: use parent загружает родителя и настраивает наследование понятнее ручного @ISA.

Вопрос 4 из 25

Как ведёт себя участок «Инкапсуляция» при выполнении?

sub balance { $_[0]{balance} }
sub deposit { $_[0]{balance}+=$_[1] }

Итог этого фрагмента полностью задаёт следующая оговорка: Возврат ссылки на внутренний массив позволяет вызывающему коду менять объект в обход методов; лучше вернуть копию или итератор. В этой версии кода возникает другой результат: Внешний код обходит проверку метода и нарушает инвариант объекта. Показанная версия изначально работает как исправленная: Изменение проходит через метод, который проверяет инвариант и возвращает понятный результат. Хеш внутри объекта доступен напрямую, поэтому инкапсуляция держится на соглашении и интерфейсе, а не на приватности языка. В показанном коде «Инкапсуляция» проявляется другой эффект: внешний код обходит проверку метода и нарушает инвариант объекта.

Вопрос 5 из 25

Какое утверждение точно описывает поведение фрагмента «Диагностика результата» с `$obj`, `ref` и `isa`?

my $obj = bless {x=>1}, 'Thing';
say ref($obj);
say $obj->isa('Thing');

Ref сообщает фактический пакет bless, а isa учитывает наследование и лучше отвечает на вопрос о совместимости классов. Фрагмент «Диагностика результата» завершится ошибкой до получения описанного результата; показанные операции в этом контексте недопустимы. Единственное существенное правило этого запуска — следующая оговорка: blessed из Scalar::Util безопасно проверяет, является ли ссылка благословлённой, не вызывая метод у случайного значения. Показанный участок сработает иначе: Точная проверка ref отвергнет объект законного подкласса Parent. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Проверка требуемого метода часто полезнее привязки к конкретному классу.

Вопрос 6 из 25

Что в этом коде нарушает ожидаемое поведение?

sub new { my ($class)=@_; bless [], 'Base' }

Жёстко заданный Base ломает наследование: вызов Child->new вернёт объект Base. Показанный код уже соблюдает правило «bless не скрывает структуру объекта и не вызывает автоматически валидацию; инварианты создаёт код конструктора», поэтому отдельного дефекта нет. Риск возникает уже в обычном результате: bless связывает ссылку с именем класса; конструктор остаётся обычной подпрограммой и должен сам проверить данные. Существенная проблема здесь связана с иной границей: Повторный bless может сменить класс ссылки, но это редкий и рискованный приём, а не обычное преобразование типа. Источником дефекта становится само изменение: Используется фактический класс вызова, поэтому подкласс сохраняется.

Вопрос 7 из 25

Какую границу автор фрагмента «Методы» не учёл?

my $method = $input;
$obj->$method(@args);

Риск появляется после применения рекомендуемой правки: Динамический вызов ограничен явным набором допустимых операций. Непроверенное имя метода позволяет вызвать любой доступный метод объекта и расширяет поверхность атаки. Показанный код уже соблюдает правило «Метод — обычная подпрограмма, найденная по классу объекта; сигнатуру и допустимые данные всё равно проверяет код», поэтому отдельного дефекта нет. Риск возникает уже в обычном результате: Стрелочный вызов передаёт объект первым аргументом метода. Причину отказа точнее описывает соседняя граница темы: can проверяет наличие метода и возвращает ссылку на код, но не подтверждает его прикладной контракт.

Вопрос 8 из 25

Какое скрытое допущение ломает контракт примера «Наследование»?

sub run { my $self=shift; Parent::run($self,@_) }

Прямой вызов конкретного родителя обходит переопределения и затрудняет множественное наследование. Основная проблема здесь — сам результат штатного случая: SUPER::run начинает поиск в родителях текущего пакета, а объект остаётся тем же. Риск появляется после применения рекомендуемой правки: use parent загружает родителя и настраивает наследование понятнее ручного @ISA. Дефект следует искать в другой оговорке: mro 'c3' меняет порядок поиска при ромбовидном наследовании и должен быть общим решением иерархии, а не локальной заплатой. Прямой вызов конкретного дочернего процесса обходит переопределения и затрудняет множественное наследование.

Вопрос 9 из 25

Какой диагноз точнее всего относится к участку с `$account`?

$account->{balance} = -1000;

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

Вопрос 10 из 25

Какой риск связан именно с операциями `$object`, `ref` и `accept_parent`?

if (ref($object) eq 'Parent') {
    accept_parent($object);
}

Причину отказа точнее описывает соседняя граница темы: blessed из Scalar::Util безопасно проверяет, является ли ссылка благословлённой, не вызывая метод у случайного значения. Точная проверка ref отвергнет объект законного подкласса Parent. Проблема возникает в исправленном варианте: Проверка требуемого метода часто полезнее привязки к конкретному классу. Причина сбоя совпадает с обычным результатом примера: ref сообщает фактический пакет bless, а isa учитывает наследование и лучше отвечает на вопрос о совместимости классов. Показанный код уже соблюдает правило «Диагностика объекта должна различать его класс, поддерживаемые методы и корректность внутреннего состояния», поэтому отдельного дефекта нет.

Вопрос 11 из 25

Почему пограничный случай больше не теряется в участке с `$class`, `%arg` и `@_`?

sub new { my ($class,%arg)=@_; my $self={%arg}; return bless $self, ref($class)||$class }

После изменения сохраняется прежний дефект: Жёстко заданный Base ломает наследование: вызов Child->new вернёт объект Base. Изменение формы записи само по себе обеспечивает правило «bless не скрывает структуру объекта и не вызывает автоматически валидацию; инварианты создаёт код конструктора». Правка решает задачу тем, что устраняет следующую границу: Повторный bless может сменить класс ссылки, но это редкий и рискованный приём, а не обычное преобразование типа. Правка лишь воспроизводит исходное поведение: bless связывает ссылку с именем класса; конструктор остаётся обычной подпрограммой и должен сам проверить данные. Используется фактический класс вызова, поэтому подкласс сохраняется.

Вопрос 12 из 25

Какой вывод точнее всего объясняет пользу правки «Методы»?

my %dispatch = (show => 'show', hide => 'hide');
my $m = $dispatch{$input} // die 'bad';
$obj->$m();

После изменения сохраняется прежний дефект: Непроверенное имя метода позволяет вызвать любой доступный метод объекта и расширяет поверхность атаки. Изменение формы записи само по себе обеспечивает правило «Метод — обычная подпрограмма, найденная по классу объекта; сигнатуру и допустимые данные всё равно проверяет код». Динамический вызов ограничен явным набором допустимых операций. Правка лишь воспроизводит исходное поведение: Стрелочный вызов передаёт объект первым аргументом метода. Правка решает задачу тем, что устраняет следующую границу: can проверяет наличие метода и возвращает ссылку на код, но не подтверждает его прикладной контракт.

Вопрос 13 из 25

Что отличает это исправление от маскировки симптома?

use parent 'Parent';
sub run { my $self=shift; return $self->SUPER::run(@_) }

Use parent загружает родителя и настраивает наследование понятнее ручного @ISA. Use parent загружает дочернего процесса и настраивает наследование понятнее ручного @ISA. Правка лишь воспроизводит исходное поведение: SUPER::run начинает поиск в родителях текущего пакета, а объект остаётся тем же. После изменения сохраняется прежний дефект: Прямой вызов конкретного родителя обходит переопределения и затрудняет множественное наследование. Use parent не загружает родителя и настраивает наследование понятнее ручного @ISA.

Вопрос 14 из 25

Почему этот вариант пригоднее для рабочего кода?

sub deposit { my ($self,$n)=@_; die 'amount' unless $n>0; $self->{balance}+=$n; return $self }

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

Вопрос 15 из 25

Что меняется по существу после правки в блоке «Диагностика результата»?

die 'contract' unless $obj->can('run');

Проверка требуемого метода часто полезнее привязки к конкретному классу. Гарантию исправления даёт исчезновение ограничения: blessed из Scalar::Util безопасно проверяет, является ли ссылка благословлённой, не вызывая метод у случайного значения. Изменение формы записи само по себе обеспечивает правило «Диагностика объекта должна различать его класс, поддерживаемые методы и корректность внутреннего состояния». После изменения сохраняется прежний дефект: Точная проверка ref отвергнет объект законного подкласса Parent. Правка лишь воспроизводит исходное поведение: ref сообщает фактический пакет bless, а isa учитывает наследование и лучше отвечает на вопрос о совместимости классов.

Вопрос 16 из 25

Какое положение темы «Создание объектов через bless» помогает выбрать надёжную реализацию?

Для всех случаев темы подходит одно изменение: Используется фактический класс вызова, поэтому подкласс сохраняется. Bless не скрывает структуру объекта и не вызывает автоматически валидацию; инварианты создаёт код конструктора. Для ревью достаточно исключить частный дефект: Жёстко заданный Base ломает наследование: вызов Child->new вернёт объект Base. Bless не скрывает структуру объекта и не вызывает автоматически валидацию; инварианты не создаёт код конструктора. Общее правило темы «Создание объектов через bless» сводится к частному результату: bless связывает ссылку с именем класса; конструктор остаётся обычной подпрограммой и должен сам проверить данные.

Вопрос 17 из 25

Какой общий принцип темы «Методы» переносится на другие программы?

Главный ориентир — не допустить следующую ситуацию: Непроверенное имя метода позволяет вызвать любой доступный метод объекта и расширяет поверхность атаки. Для всех случаев темы подходит одно изменение: Динамический вызов ограничен явным набором допустимых операций. Общее правило темы «Методы» сводится к частному результату: Стрелочный вызов передаёт объект первым аргументом метода. Метод — обычная подпрограмма, найденная по классу объекта; сигнатуру и допустимые данные всё равно не проверяет код. Метод — обычная подпрограмма, найденная по классу объекта; сигнатуру и допустимые данные всё равно проверяет код.

Вопрос 18 из 25

Какое положение темы «Наследование» помогает выбрать надёжную реализацию?

Наследование в Perl основано на поиске методов по @ISA; композиция часто проще, когда отношение «является» неочевидно. Общее правило темы «Наследование» сводится к частному результату: SUPER::run начинает поиск в родителях текущего пакета, а объект остаётся тем же. Весь контракт блока обеспечивает такая правка: use parent загружает родителя и настраивает наследование понятнее ручного @ISA. Наследование в Perl основано на поиске методов по @ISA; композиция часто проще, когда отношение «не является» неочевидно. Главный ориентир — не допустить следующую ситуацию: Прямой вызов конкретного родителя обходит переопределения и затрудняет множественное наследование.

Вопрос 19 из 25

На что следует опираться при ревью кода по теме «Инкапсуляция»?

Скрывать внутреннюю форму стоит организационно: не документировать её, не выдавать изменяемые ссылки и проверять состояние в методах. Общее правило темы «Инкапсуляция» сводится к частному результату: Хеш внутри объекта доступен напрямую, поэтому инкапсуляция держится на соглашении и интерфейсе, а не на приватности языка. Правило «Скрывать внутреннюю форму стоит организационно: не документировать её, не выдавать изменяемые ссылки и проверять состояние в методах» гарантирует, что ограничение «Возврат ссылки на внутренний массив позволяет вызывающему коду менять объект в обход методов; лучше вернуть копию или итератор» больше не проявится. Весь контракт блока обеспечивает такая правка: Изменение проходит через метод, который проверяет инвариант и возвращает понятный результат. Главный ориентир — не допустить следующую ситуацию: Внешний код обходит проверку метода и нарушает инвариант объекта.

Вопрос 20 из 25

Как сформулировать основное правило блока «Диагностика результата» без лишних обещаний?

Общее правило темы «Диагностика результата» сводится к частному результату: ref сообщает фактический пакет bless, а isa учитывает наследование и лучше отвечает на вопрос о совместимости классов. Один приём полностью закрывает тему: Проверка требуемого метода часто полезнее привязки к конкретному классу. Основной принцип блока описывает только такой риск: Точная проверка ref отвергнет объект законного подкласса Parent. Диагностика объекта должна различать его класс, поддерживаемые методы и корректность внутреннего состояния. Правило «Диагностика объекта должна различать его класс, поддерживаемые методы и корректность внутреннего состояния» гарантирует, что ограничение «blessed из Scalar::Util безопасно проверяет, является ли ссылка благословлённой, не вызывая метод у случайного значения» больше не проявится.

Вопрос 21 из 25

Какой предел гарантий блока «Создание объектов через bless» остаётся в силе после успешного запуска?

Ограничение «Повторный bless может сменить класс ссылки, но это редкий и рискованный приём, а не обычное преобразование типа» исчезает, если обычный пример один раз завершился успешно. Повторный bless может сменить класс ссылки, но это редкий и рискованный приём, а не обычное преобразование типа. Базовое правило «bless не скрывает структуру объекта и не вызывает автоматически валидацию; инварианты создаёт код конструктора» автоматически снимает указанную границу. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Повторный bless не может сменить класс ссылки, но это редкий и рискованный приём, а не обычное преобразование типа.

Вопрос 22 из 25

Какое предостережение по теме «Методы» нельзя заменить включением strict и warnings?

Can проверяет наличие метода и возвращает ссылку на код, но не подтверждает его прикладной контракт. Can проверяет наличие метода и не возвращает ссылку на код, но не подтверждает его прикладной контракт. Ограничение «can проверяет наличие метода и возвращает ссылку на код, но не подтверждает его прикладной контракт» исчезает, если обычный пример один раз завершился успешно. Can проверяет наличие метода и возвращает копию на код, но не подтверждает его прикладной контракт. Can не проверяет наличие метода и возвращает ссылку на код, но не подтверждает его прикладной контракт.

Вопрос 23 из 25

Какое утверждение о теме «Наследование» не приписывает механизму лишних гарантий?

Mro 'c3' меняет порядок поиска при ромбовидном наследовании и должен быть общим решением иерархии, а не локальной заплатой. В актуальной версии Perl эта граница больше не действует. Базовое правило «Наследование в Perl основано на поиске методов по @ISA; композиция часто проще, когда отношение «является» неочевидно» автоматически снимает указанную границу. Ограничение «mro 'c3' меняет порядок поиска при ромбовидном наследовании и должен быть общим решением иерархии, а не локальной заплатой» исчезает, если обычный пример один раз завершился успешно. Mro 'c3' меняет порядок поиска при ромбовидном наследовании и не должен быть общим решением иерархии, а не локальной заплатой.

Вопрос 24 из 25

Как точнее всего обозначить границу безопасного использования приёма «Инкапсуляция»?

Базовое правило «Скрывать внутреннюю форму стоит организационно: не документировать её, не выдавать изменяемые ссылки и проверять состояние в методах» автоматически снимает указанную границу. Возврат ссылки на внутренний массив позволяет вызывающему коду менять объект в обход методов; лучше вернуть копию или итератор. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Ограничение «Возврат ссылки на внутренний массив позволяет вызывающему коду менять объект в обход методов; лучше вернуть копию или итератор» исчезает, если обычный пример один раз завершился успешно. При strict и warnings отдельная проверка этой оговорки не требуется.

Вопрос 25 из 25

Какой вывод о механизме «Диагностика результата» выдерживает проверку на пограничном входе?

Blessed из Scalar::Util безопасно проверяет, является ли копия благословлённой, не вызывая метод у случайного значения. Blessed из Scalar::Util безопасно проверяет, не является ли ссылка благословлённой, не вызывая метод у случайного значения. Blessed из Scalar::Util безопасно не проверяет, является ли ссылка благословлённой, не вызывая метод у случайного значения. Blessed из Scalar::Util безопасно проверяет, является ли ссылка благословлённой, не вызывая метод у случайного ключи. Blessed из Scalar::Util безопасно проверяет, является ли ссылка благословлённой, не вызывая метод у случайного значения.