Каков наилучший способ настроить части существующей программы Perl для нескольких клиентов?

Question

У меня есть существующее приложение Perl, которое развернуто на нескольких сайтах клиентов. К сожалению, код был клонирован несколько раз, чтобы настроить его для индивидуальных клиентов. Итак, теперь есть несколько полных копий кода, которые имеют небольшие (или существенные) отличия.

Моя задача - исправить эту путаницу, создав единую базовую кодовую базу с настройками для разных клиентов, которые изолированы в своих собственных библиотеках.

Приложение уже имеет иерархию классов (около 120 классов) по направлениям:

Control.pm
  \__ BaseJob.pm
           \___Job1.pm
           |
           |__ Job2.pm
           |
           |__ Job3.pm

Моя цель - иметь возможность настраивать определенный класс или метод, изменяя только библиотеку для конкретного клиента.

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

Например, если необходимо настроить один метод в Job2.pm, я мог бы создать подкласс CustomJob2, который наследуется от Job2 и содержит только метод, который нужно настроить.

Тогда в основной программе это:

Job2->some_method();

становится:

CustomJob2->some_method();

Проблема в том, что это нарушит код для всех остальных клиентов, потому что у них нет класса CustomJob2 в их библиотеках. Похоже, мне нужно было бы добавить пустой класс CustomJob2 в библиотеку для каждого клиента.

Есть ли лучший способ?

Другая возможность, которую я рассмотрел, - это использовать переопределения вместо подклассов. Основной программе просто потребуется use lib для включения библиотеки клиента, а любые настраиваемые методы будут просто переопределены в библиотеке. Однако это, вероятно, опасно и не считается лучшей практикой.

Я ищу мудрость гуру StackOverflow в поиске наилучшего подхода к этой проблеме.

Answer 1

Я настоятельно рекомендую вам вносить как можно больше настроек в конфигурацию, а не в код.

Код, который ищет значение в объекте конфигурации, намного проще, чем создание экземпляра подкласса.

Вы также можете смешивать их, помещая имена классов в файл конфигурации и создавая экземпляры классов на основе этих имен. Это также упрощает обмен настройками между двумя и более клиентами.

Answer 2

Большинство ваших мыслей о том, как выбрать направление, твердые; проблема возникает, когда вы вызываете Job2-> some_method () , а не $ job-> some_method () . То есть вызовы методов класса являются проблемой только потому, что они плохая идея, которую вы видите, потому что они мешают вам использовать ООП.

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

my $job2_class = $project->conf->{job2_class} || 'Job2';
my $job2 = new $job2_class;
$job2->some_method();