Я пишу приложение на Python, которое будет установлено на нескольких сайтах.На каждом из этих сайтов ему необходимо взаимодействовать с другим программным обеспечением с разными API на каждом сайте, но все они логически делают одно и то же.
Мое решение состоит в создании базового класса, который инкапсулирует общую логику и предоставляет единыйвозвратите интерфейс к основному приложению, а затем выделите подклассы для каждого отдельного API для конкретного сайтаБазовый класс и подклассы будут определены в пакете «интерфейсы», развернутом на каждом сайте вместе с основным приложением.Для обеспечения общей кодовой базы (для простоты развертывания и обслуживания) все сайты должны иметь одинаковый код, как основного пакета приложения, так и пакета интерфейсов.
Мой вопрос заключается в том, как лучше всего обеспечить, чтобы основное приложение использовалоправильный подкласс из пакета интерфейсов?
В настоящее время я думаю, чтобы основное приложение вызывало функцию get_interface в пакете интерфейсов, которая считывает ini-файл, чтобы определить, какой подкласс интерфейса используется на этом сайте, и возвращаетэтот подкласс для основного приложения.Очевидно, что для этого требуется, чтобы ini-файл был специфичным для сайта, но это единственное, что могло бы быть.
Это лучший подход?
Чтобы добавить более конкретную информацию по запросу:
Приложение связано с астрономией.Он нацелен на автоматизацию конвейера от идентификации цели, посредством планирования сеансов визуализации телескопа, до обработки результирующих изображений.Он широко использует Astropy и дочерние пакеты.
Есть несколько областей, в которых необходимо взаимодействовать с другим программным обеспечением.Например:
Идентификация цели, где она получает информацию о цели из различных астрономических баз данных через веб-сервисы.
Решение "Platesolving", когда оно загружает данные изображений в локальные (на базе Windows или Linux) приложения или в удаленные веб-службы, такие как astrometry.net.
Отображение, когда ему необходимо взаимодействовать с коммерческими пакетами управления телескопом / обсерваторией (например, ACP или ASA Sequence) для фактического выполнения сеансов обработки изображений.
Логические интерфейсы все в значительной степени идентичны в каждой из этих областей, поэтому в вышеупомянутых случаях я предусматриваю 3 класса для предоставления абстракций, которые будут реализованы через подклассы, специфичные дляцелевая система, с которой я взаимодействую.
Я на самом деле просто изучаю лучший шаблон проектирования для того, как реализовать его таким образом, чтобы полностью изолировать ядро приложения от реализации интерфейсов с другими системами (поскольку они меняются довольно часто),
В некотором смысле это похоже на использование драйверов устройств.Основное приложение должно вызывать выполнение службы (не заботясь о том, как это достигается), когда этот вызов направляется «драйверу» (моему подходящему подклассу интерфейса), который потенциально может отличаться для каждой реализации сайта.