Perl платформы OO и проектирование программы - Moose и вывернутые наизнанку объекты Conway (Класс:: Станд.)
Это - больше типа примера использования вопроса..., но также и достаточно универсальный, чтобы быть более широко применимым:
Короче говоря, я работаю над модулем, это - более или менее обертка командной строки; OO естественно. Не вдаваясь в слишком много подробностей (если кто-то не хочет их), нет сумасшедшей суммы сложности к системе, но действительно чувствовало себя естественным иметь три или четыре объекта в этой платформе. Наконец, это - вещь с открытым исходным кодом, которую я помещу там, а не модуль с несколькими разработчиками в той же фирме, работающей над ним.
Сначала я реализовал OO с помощью Класса:: Станд., потому что Лучшие практики Perl (Conway, 2005) привели хороший аргумент в пользу того, почему использовать вывернутые наизнанку объекты. Полный контроль над тем, к каким атрибутам получают доступ и так далее, надлежащая инкапсуляция, и т.д. Также его дизайн удивительно прост и умен.
Я любил его, но затем заметил, что никто действительно не использует это; на самом деле кажется, что сам Conway действительно больше не рекомендует это?
Таким образом, я переместился к общему фавориту, Американскому лосю. Это просто в использовании, хотя путь путем излишество, мудрое функцией для того, что я хочу сделать. Большая, главная оборотная сторона: это имеет убивание зависимостей от модуля, которые вынуждают пользователей моего модуля загрузить их всех. Незначительная оборотная сторона, она имеет путь больше функциональности, чем мне действительно нужно.
Что такое рекомендации? Поддерживающие разработчики неудобства, вынуждая их использовать возможно устаревший модуль или вынудить каждого пользователя модуля загрузить Американского лося и все его зависимости?
Существует ли третья опция для надлежащего Perl платформа OO, это популярно, но ни один из этих двух?
4 ответа
В настоящее время принятый «современный объектно-ориентированный фреймворк Perl» - это Moose. Я бы сказал, чтобы ваши пользователи загрузили его, или вы можете связать его со своими модулями при установке, используя PAR :: Packer .
Цитата из « Но я не могу использовать CPAN » (... потому что мои пользователи не хотят ничего устанавливать):
Предполагая, что вы просто обрабатываете своим пользователям tarball, тогда Module :: Install предлагает решение - если вы поместите свой скрипт в скрипт /, а затем выполните
install_script (glob 'script / *'); auto_install;в вашем Makefile.PL, то make install не только поместит ваш скрипт в полезное для вас место, но и «make installdeps» вызовет cpan (или, если есть, cpanplus) для установки всех недостающих зависимостей для вас.
Ну, есть Mouse , который похож на Moose , но без всех зависимостей (и некоторых функций). Также запускается немного быстрее. Сам я не пробовал, но обычно хорошо продуман .
Чтобы добавить к существующим прекрасным ответам...
Кое-что из того, что было рекомендовано в PBP, не является плохим советом, но Perl идет вперед. Когда он был написан, внутренние объекты были новым трендом. Теперь Moose поглотил все. Существует MooseX::InsideOut, который дает вам мощь Moose с полной инкапсуляцией Class::Std, но если вы не работаете с недисциплинированными программистами, в нем нет необходимости.
Те возможности Moose, которые вам не нужны сейчас, вам понадобятся со временем. Даже если вам не понадобятся все из них, с Moose вам не придется использовать и изучать Yet Another OO System каждый раз, когда вам понадобится интересная функция. И не дай бог вам понадобится ДВЕ функции в одно и то же время!
Честно говоря, видя практически все интересное в наши дни в мире Perl, Moose где-то в качестве зависимости, я не вижу, чтобы это был большой долг для других «коллег-разработчиков Perl».
Скорее всего, у них уже установлен он, как мы говорим!
Правка: Некоторая статистика:
Moose в настоящее время занимает 65-е место в списке модулей «Наиболее зависимые от», Псевдонимы топ-100, с более чем 1637 пакетами в зависимости от него. Это почти столько же, сколько такие вещи, как Time::HiRes, и больше, чем DBI, и я не думаю, что вы с такой вероятностью будете сомневаться в зависимости от них?