Прежде всего, роли составлены в класс, они не имеют ничего общего с подклассами. Подкласс - это полный класс, который расширяет родительский класс (или более одного, но по моему опыту следует избегать множественного наследования, если это возможно). Роль - это часть поведения или частичный интерфейс, который можно применить к классу. Затем роль напрямую изменяет класс. В общем, новый класс не создан.
Итак, наследование и ролевая композиция - это действительно две разные вещи и два разных вида дизайна. Таким образом, вы не можете просто обменять одно на другое. Оба имеют разные дизайнерские последствия.
Моя стратегия с HTML::FormHandler состояла в том, чтобы создать реальный подкласс для каждой формы, в которой я нуждаюсь, и поместить различные формы поведения, которые я хотел повторно использовать, в роли.
Я думаю, что на этот вопрос (как реализовать расширения, которые вам нужны, чистым и разумным способом) невозможно ответить без знания фактического дизайна, к которому вы стремитесь.
Обновление: Я понимаю, что вы имеете в виду, и это сложный случай. HTML::FormHandler в первую очередь предназначен для расширения наследованием. Поэтому я думаю, что лучшей стратегией действительно было бы иметь два подкласса, один для HTML::FormHandler и один для HTML::FormHandler::Model::DBIC. Поначалу это кажется утомительным, но в любом случае вы, возможно, захотите иметь разные настройки для них. Чтобы не повторять фактическую конфигурацию (значения по умолчанию), я бы попробовал следующее (этот пример - простой HFH, без DBIC):
package MyApp::Form;
use Moose;
use namespace::autoclean;
extends 'HTML::FormHandler';
with 'MyApp::Form::DefaultSettings';
# only using two fields as example
for my $field (qw( html_prefix field_traits )) {
has "+$field", default => sub {
my $self = shift;
my $init = "_get_default_$field";
my $method = $self->can($init)
or die sprintf q{Class %s does not implement %s method}, ref($self), $init;
return $self->$method;
};
}
1;
Обратите внимание, что вам нужно сделать атрибут ленивым, если для его вычисления требуются значения другого атрибута. Вышеупомянутый базовый класс будет искать хуки для поиска инициализированных значений. Вы должны сделать это в обоих классах, но вы можете поместить подпрограмму по умолчанию в функцию, которую вы импортируете из библиотеки. Поскольку вышеописанное больше не требует прямого манипулирования атрибутом для изменения значений по умолчанию, вы можете поместить этот материал в роль, которую я назвал MyApp::Form::DefaultSettings выше:
package MyApp::Form::DefaultSettings;
use Moose::Role;
use namespace::autoclean;
sub _build_html_prefix { 1 }
sub _build_field_traits { ['MyApp::Form::Trait::Field'] }
1;
Этот метод позволит вашим ролям влиять на построение значений по умолчанию. Например, у вас может быть роль, основанная на роли выше, которая изменяет значение с помощью around.
Существует также очень простой, но, на мой взгляд, довольно уродливый способ: у вас может быть роль, обеспечивающая метод BUILD, который изменяет значения. Поначалу это кажется довольно простым и легким, но это простота и простота торговли. Это работает просто, но также работает только для очень простых случаев. Поскольку количество форм в веб-приложениях обычно довольно велико, а потребности могут быть самыми разными, я бы рекомендовал использовать более гибкое решение.