Шаблон проектирования для нескольких провайдеров платежей и уведомление различных пользователей на основе реализации
Я пытаюсь найти общий способ добавить несколько реализаций поставщиков платежей в систему, которая пока использует только одну.
Я хотел бы иметь Company объект, связанный с Subscription, Subscription имеет несколько Invoice объекты, связанные с ним. Subscription может иметь только один PaymentProviderInterface связан с ним, но мы должны иметь возможность заменить поставщика платежей для подписки. PaymentProviderInterface ссылка на подписку создается Фабрикой.
Проблема в том, что для разных PaymentProviderInterface В реализациях логика уведомления пользователя может отличаться. Для особого PaymentProviderInterface электронное письмо я должен отправить в нашу систему вместо фактического конечного пользователя. Для Stripe электронное письмо должно быть отправлено пользователю, подключенному к учетной записи Stripe. Для другого сервиса пользователь хранится в объекте Company.
Есть ли способ реализовать это без PaymentProvider объект должен на самом деле знать о Subscription это связано с?
То же самое для BillingAddress, То, как мы получаем адрес выставления счета для выставления на объект Invoice, зависит от поставщика платежа. Если это Stripe, это адрес для выставления счетов, сохраненный в Stripe. Если это еще один, то BillingAddress хранится в нашей базе данных.
Решение
Вы должны иметь возможность определять настраиваемые аргументы, передаваемые поставщику платежей в качестве параметров запроса и возвращать на сервер «как есть» после попытки платежа (если это успешная или неудачная попытка, это не влияет на наличие этих настраиваемых аргументов). ). Когда ваш Factory выбрать право PaymentProviderInterface для Subscriptionзатем он может выбрать пользователя, используя желаемую логику, и передать его в качестве параметра PaymentProvider (в виде строки), тогда сервер может знать, кого уведомлять, на основе того, что возвращается PaymentProvider анализируя содержимое этого поля пользовательских аргументов. Пользовательские аргументы в PaymentProviders обычно используются для такого рода целей.
Имеет ли это смысл?
Другие решения
Я думаю, что концепция Шаблон дизайна наблюдателя это одно из возможных решений, которые вы ищете. Поскольку его основная цель — обеспечить способ уведомления об изменении количества классов. Он определяет зависимость между объектами, поэтому, когда один объект изменяет состояние, все его зависимые элементы уведомляются и обновляются автоматически.
Вы можете рассмотреть следующую реализацию:
-
Тема (подписка)
знает своих наблюдателей. Любое количество объектов Observer может наблюдать за объектом
предоставляет интерфейс для присоединения и отсоединения объектов Observer. -
ConcreteSubject (ConcreteSubscription)
хранит состояние интереса к ConcreteObserver
отправляет уведомление своим наблюдателям, когда его состояние изменяется -
Обозреватель (IPaymentProvider)
определяет интерфейс обновления для объектов, которые должны быть уведомлены об изменениях в теме. -
ConcreteObserver (PaymentProvider)
поддерживает ссылку на объект ConcreteSubject
магазины заявляют, что должны соответствовать предмету
реализует интерфейс обновления Observer, чтобы поддерживать его состояние в соответствии с