Perl OO фреймворки и дизайн программы - объекты Moose и Conway наизнанку (Class :: Std)

Question

Это вопрос типа варианта использования ... но также достаточно общий, чтобы его можно было применять более широко:

Короче говоря, я работаю над модулем, более или менее команднымобёртка строки;Оо естественно.Не вдаваясь в подробности (если кто-то их не хочет), в системе нет сумасшедшей сложности, но было вполне естественно иметь три или четыре объекта в этой среде.И, наконец, я предложу это с открытым исходным кодом, а не модуль, над которым работают несколько разработчиков из той же фирмы.

Сначала я реализовал ОО, используя Class :: Std, потому что Perl Best Practices (Conway, 2005) привел хороший аргумент в пользу того, почему использовать объекты наизнанку.Полный контроль над тем, какие атрибуты доступны и так далее, правильная инкапсуляция и т. Д. Кроме того, его дизайн удивительно прост и умен.

Мне понравилось, но потом заметил, что никто действительно не использует это;на самом деле кажется, что сам Конвей больше не рекомендует это?

Итак, я перешел к любимому человеку, Мус.Это простой в использовании, хотя способ излишне функциональный для того, что я хочу сделать.Большой, главный недостаток: у него есть множество зависимостей от модулей, которые вынуждают пользователей моего модуля загружать их все.Небольшой недостаток - у него гораздо больше функциональности, чем мне действительно нужно.

Какие рекомендации?Неудобные коллеги-разработчики, вынуждая их использовать возможно устаревший модуль или заставлять каждого пользователя модуля загружать Moose и все его зависимости?

Существует ли третий вариант для надлежащей платформы Perl OO, которая популярна, но неиз этих двух?

Answer 1

Чтобы быть совершенно справедливым, видя, что практически все интересное в наши дни в мире Perl, Moose где-то является зависимостью, я не вижу большого долга перед другими "коллегами-разработчиками Perl".

Скорее всего, они уже установлены, как мы говорим!

Редактировать: Немного статистики:

Moose в настоящее время оценивается на 65-м месте в списке модулей «Наиболее зависимые от», Псевдонимы топ 100 , с более чем 1637 пакетами в зависимости от него. Это почти столько же, сколько Time::HiRes и более DBI, и я не думаю, что вы будете задавать вопросы в зависимости от этих вопросов, не так ли?

Answer 2

В настоящее время принята "современная структура Perl OO" - Moose. Я бы сказал, чтобы ваши пользователи загружали его, или вы можете связать его с вашими модулями при установке, используя PAR :: Packer .

Цитата из " Но я не могу использовать CPAN " (... потому что мои пользователи не захотят устанавливать вещи):

Предполагая, что вы просто обрабатываете своих пользователей tarball, тогда Module :: Install предлагает решение - если вы поместите свой скрипт в скрипт /, а затем выполните

install_script(glob 'script/*');
auto_install;

в вашем файле Makefile.PL не только «make install» поместит ваш сценарий куда-нибудь полезное для вас, но и «make installdeps» вызовет cpan (или, если присутствует, cpanplus), чтобы установить все недостающие зависимости для вас.

Answer 3

Чтобы добавить к существующим точным ответам ...

Некоторые из рекомендованных в PBP советов не плохие, но Perl идет дальше.Когда это было написано, объекты наизнанку были новой жаркостью.Теперь Лось поглотил все.Существует MooseX :: InsideOut , который дает вам мощь Moose с полной инкапсуляцией Class :: Std, но если вы не работаете с недисциплинированными программистами, это действительно не нужно.

Эти функцииЛоси вам сейчас не нужны, они вам понадобятся в конце концов.Даже если вам не нужны все из них, с Moose вам не придется использовать и изучать еще одну OO-систему каждый раз, когда вам нужна интересная функция.И не дай бог, вам нужны ДВЕ функции в то же время!

Answer 4

Ну, есть Мышь , которая похожа на Moose , но без всех зависимостей (и некоторых функций).Это также запускается немного быстрее.Я сам не пробовал, но обычно хорошо продумано .

Answer 5

Существует также объектный модуль Perl :: InsideOut, активно поддерживаемый по состоянию на 2010 год.

Вид предшественника Moose, или, чтобы быть ясным: разработка началась независимо одновременно с началом Moose,

Я знаю, что оно существует, но я им не пользовался.