💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В каждом вопросе верен только один вариант. После завершения откроются общий результат, оценки по 6 тематическим шкалам и подробный разбор.
Вопрос 8 из 30
Обычный случай проходит. Что в блоке «Типы» всё же сделано неверно?
Perl Типы Копировать
package Source;
use Moose;
has 'path' => (is => 'ro', isa => 'Str', required => 1);
sub open_path {
my ($self) = @_;
open my $fh, '<', $self->path or die $!;
return $fh;
}
Показанный сбой объясняется не кодом, а таким пределом механизма: Coercion удобен на границе, но не должен молча исправлять неоднозначный или опасный ввод.
Источником отказа служит нормальный итог выполнения: Проверяется целочисленность, но не диапазон сетевого порта.
Тип Str ничего не говорит о существовании, правах и доверенности пути.
Проблема возникает в исправленном варианте: Пользовательский subtype выражает предметное ограничение диапазона.
Показанный код уже соблюдает правило «Тип Moose проверяет объявленное свойство, но не заменяет внешнюю валидацию, авторизацию и проверку состояния ресурсов», поэтому отдельного дефекта нет.
Вопрос 11 из 30
Какой риск связан именно с операциями `$self`, `@_` и `$module`?
Perl Риски безопасности Копировать
package PluginLoader;
use Moose;
has 'module' => (is => 'ro', isa => 'Str', required => 1);
sub load_module {
my ($self) = @_;
my $module = $self->module;
eval "require $module; 1" or die $@;
}
Показанный сбой объясняется не кодом, а таким пределом механизма: Десериализацию в Moose-объекты нельзя считать безопасной, пока не ограничены классы, размеры и вызываемые coercion/builder.
Проблема возникает в исправленном варианте: Закрытый тип ограничивает выбор известными плагинами; загрузку всё равно выполняют без строкового eval.
Тип Str не защищает динамическое выполнение имени модуля из недоверенного ввода.
Риск возникает уже в обычном результате: Массив аргументов избегает shell-строки, но первый элемент и все параметры всё равно должны быть разрешены политикой.
Показанный код уже соблюдает правило «Декларативная модель снижает часть ошибок типов, но не предотвращает инъекции, утечки секретов и чрезмерные права», поэтому отдельного дефекта нет.
Вопрос 16 из 30
Почему этот вариант пригоднее для рабочего кода?
Perl Неизменяемые объекты Копировать
package Basket;
use Moose;
has 'items' => (is => 'ro', isa => 'ArrayRef[Str]', required => 1);
around BUILDARGS => sub {
my ($orig, $class, %args) = @_;
die 'items must be an array' if ref($args{items}) ne 'ARRAY';
$args{items} = [ @{ $args{items} } ];
return $class->$orig(%args);
};
После изменения сохраняется прежний дефект: Прямой доступ к реализации может обойти ro, если объект основан на обычном хеше.
Выход копируется и проверяется до построения объекта, уменьшая совместное владение изменяемыми ссылками.
Вход копируется и проверяется до построения объекта, уменьшая совместное владение изменяемыми ссылками.
Правка решает задачу тем, что устраняет следующую границу: make_immutable относится к метаобъекту класса и производительности, а не делает экземпляры неизменяемыми по данным.
Правка лишь воспроизводит исходное поведение: ro запрещает запись через аксессор, а make_immutable оптимизирует метакласс; внутренний хеш всё ещё не криптографически неизменяем.