多个支付提供商的设计模式,并根据实施通知不同的用户

时间:2014-10-10 10:11:58

标签: php design-patterns uml data-modeling

我正试图想出一种通用方法,在一个目前只使用一个支付提供商的系统中添加多个支付提供商实现。

我希望Company对象与Subscription相关联。 Subscription有多个Invoice个对象连接到它。 Subscription只能链接一个PaymentProviderInterface,但我们必须选择替换订阅的付款提供商。链接到订阅的PaymentProviderInterface由工厂构建。

问题在于,对于不同的PaymentProviderInterface实现,获取用户通知的逻辑可能不同。对于特殊的PaymentProviderInterface,我必须将电子邮件发送给我们的系统而不是实际的最终用户。对于Stripe,电子邮件应发送给连接到Stripe帐户的用户。对于其他服务,用户存储在Company对象中。

有没有办法实现这一点,PaymentProvider对象不必实际知道它链接到的Subscription

BillingAddress同样的事情。我们检索帐单地址以放置在Invoice对象上的方式因付款提供商而异。如果是Stripe,则是存储在Stripe上的帐单邮寄地址。如果是另一个,则BillingAddress存储在我们的数据库中。

2 个答案:

答案 0 :(得分:1)

您应该能够将传递给支付提供商的自定义参数定义为查询的参数并返回到您的服务器"因为它"在付款尝试之后(成功或失败的尝试不会影响这些自定义args的存在)。当FactoryPaymentProviderInterface选择正确Subscription时,它可以使用您想要的逻辑选择用户,并将其作为参数传递给PaymentProvider(作为字符串) ),然后服务器可以通过解析此自定义参数字段的内容,根据PaymentProvider返回的内容知道要通知的人。 PaymentProviders中的自定义参数通常用于此类目的。 这有道理吗?

答案 1 :(得分:1)

我认为Observer design pattern的概念是您追求的可能解决方案之一。因为它的主要目的是确保通知一些类的变更方式。它定义了对象之间的依赖关系,以便当一个对象更改状态时,将自动通知和更新其所有依赖项。

您可以考虑以下实施:

  • 主题(订阅) 知道它的观察者。任何数量的Observer对象都可能观察到一个主题 提供了一个用于附加和分离Observer对象的接口。

  • ConcreteSubject(ConcreteSubscription) 存储ConcreteObserver感兴趣的状态 在状态发生变化时向其观察者发送通知

  • 观察者(IPaymentProvider) 为对象提供更新接口,应该通知对象的变化。

  • ConcreteObserver(PaymentProvider) 维护对ConcreteSubject对象的引用 存储应与主题保持一致的状态 实现Observer更新界面,使其状态与主题

  • 保持一致