нет, дело не в этом, а в том что вот 30 из этих 100 применимы к RAM 2021 и 20 штук к рам 2020. У меня будет одна теперь спецификадля для 50 рамов и две для разных модельных годов

я понятия не имею, кто такие рамы

машина такая

ты наверное думаешь что стало понятнее

сепулька -- см. сепулькарий

в сепулькарии производится сепуление, чо непонятного

А откуда берётся cpm?
Вот с cpanm всё понятно:
pkg install p5-App-cpanminus
Ну можно и несистемным установщиком, а перловым. Просто системным лучше.
А вот откуда добрые люди берут cpm? И что это?

есть такая страшная модная у хипстеров вещь: curl http://url | sudo bash -

Да вроде lsof. Может быть даже tcpstat (если только tcp сокеты нужны)

Это, на мой взгляд, куда более удобный менеджер

И он лежит на github.

Хотя лично я это вот всё ставлю через cpan обычно

Обычный модуль, на спане лежит. Там же и инструкции по установке имеются - https://metacpan.org/pod/App::cpm::Tutorial

Непонятно, _зачем_ много таких маленьких объектов. К слову, запихивать в класс кучу слабо связанного кода - антипаттерн (SOLID).

Глянув в пример данного паттерна на Википедии, похоже, что он предназначался для старых языков без поддержки передачи функций как аргументов (функционального программирования) - с целью абстракции от типа аргумента функции. Такая возможность есть практически у любого современного ЯП. И соответственно его можно заменить на использование функций "из типа T в Boolean".
В Perl вообще нет пользовательских типов, поэтому придётся работать с произвольными скалярами на входе.

Т.е. просто описываете функции-предикаты, затем комбинируете их используя всё, что есть в ЯП, например:

sub need_send_to_collection {
  my $object = shift;
  return object_overdue( $object ) && notice_sent( $object ) && ! $collection->object_present( $object );
}

foreach my $invoice( @invoices ) {
  send_to_collection( $invoice ) if is_correct_moon_phase( $invoice, $some_other_context_object ) && need_send_to_collection( $invoice);
}

А если это вам надо настраивать через админку, то имеет смысл продумать, как это будет в БД храниться, а алгоритмы обработки этих настроек сразу из представления последуют. Использовать Moo и т.п. для этого не оправдает вложенных усилий..

sub need_send_to_collection {
  my $object = shift;
  return object_overdue( $object ) && notice_sent( $object ) && ! $collection->object_present( $object );
}

foreach my $invoice( @invoices ) {
  send_to_collection( $invoice ) if is_correct_moon_phase( $invoice, $some_other_context_object ) && need_send_to_collection( $invoice);
}

Ну Moo-то не затратно по усилиям.
Я тред не читал, но да, сначала надо подумать, стоит ли вообще делать 50(или сколько там) модулей

Я про усилия для программирования. А по ресурсам системы Mouse гораздо легковеснее, даже без XS. Но в любом случаи без совместимых ролей все M* довольно бессмысленны. Особенно когда нужно кучу таких тривиальных классов понаписать.

Можно и так как вы описали, конечно. Но суть в том что каждый этот объект имеет свой индивидуальный набор из таких правил + еще иногда специфические только для него. То есть в любом случае это где то хранить надо. Можно было, наверное составить список предикатов и хранить их где нибудь в конфиге. Но именно модули я выбрал потому что там еще есть у некоторых объектов логика после того как их применили.

Я догадался "что есть ещё логика", поэтому и упомянул SOLID.

Вообще, надо учитывать, что большинство паттернов GoF изобрели для того, что бы преодолеть ограничения древних версий Java (я их называю "низкоуровневые паттерны"). Сейчас большинство из этой части неактуальны (только для археологии или поддержки легаси). Так что какая нибудь Стратегия (возможно использующая внутри Шаблонный метод) - это нормальный способ реализации похожей функциональности. Но, во-первых, при этом надо максимум одну стратегию на класс (модуль). А, во-вторых, "низкоуровневые" паттерны, типа того о котором мы говорим, точно сюда припихивать не нужно. В обоих случаях вы рискуете замучиться с иерархией наследования и столкнуться с проблемой хрупкого базового класса, а как следствие - потерять поддерживаемость разрабатываемой системы.

Может без наследования? выделить интерфейсы используя роли. кучи if заменить посетителями (visitor) и стратегиями

Роли - это то же наследование (они только помогают декомпозировать логику, которую раньше пихали в базовые классы).