我应该使用哪种设计模式？ （支付系统API）

Question

我必须实现与支付系统一起使用的类（我们称之为PaymentSystem）API，允许下面列出的操作：

• 向用户发出发票
• 检查发票
• 获取用户余额
• 检查收款人存在

我现在得到的是：

抽象类PaymentSystemBase，其中保留所有设置（安全令牌，密码，RESTful API URL等）

每个API条目的类：

• PaymentSystemIssueInvoice
• PaymentSystemCheckInvoice
• PaymentSystemGetBalance
• PaymentSystemCheckUser

这些类中的每一个都是使用方法从PaymentSystemAPI继承而来的（当然是从PaymentSystemBase继承而来）：

• request - 通过HTTP执行请求
• parseResponse解析来自API的响应（基本上告诉请求是否成功或我们是否有错误）

所以我的问题是：为API使用一些创作设计模式是否方便（IssueInvoice，CheckInvoice，GetBalance，CheckUser）？

如果您有关于我应该如何以其他方式实施API的建议，请随时回答/评论该问题。

谢谢。

Answer 1

这可能类似于command（Irfy指出）。

如果您有复杂的逻辑来确定要使用的基类的哪个子类（即，对于一些构造函数参数更合理），那么您可以使用factory模式。

我也会把strategy扔出去，但我们可能会偏离正轨。

作为设计模式的一般说明，您应该有目的地使用它们。通常，模式用于：

1. 提高代码可读性
2. 提高代码可重用性。
3. 将可能发生变化的内容与不会发生变化分开。

特别是，如果您选择的子类将来可能会发生变化，那么抽象决定使用哪一个的代码是很好的。工厂模式通过将此逻辑封装在单个类中来实现此目的。

我觉得奇怪的是你使用了一些类来表示看起来像方法的东西。但是，听起来你正在使用其他API，所以我需要更多信息来进一步提供建议。