我正在设计一个API，我希望它易于使用。所以，如果我有客户，报表和付款。拥有以下对象是否有意义：Customer，CustomerHandler，Statement，StatementHandler，Payment，PaymentHandler？这样，当开发人员想要与他/她知道创建CustomerHandler的客户做某事时，然后想要与客户一起执行的所有可能功能都在处理程序内。
方法如：
CustomerHandler：
StatementHandler：
PaymentHandler：
这样，如果开发人员想要接收他/她知道要转到PaymentHandler的付款。我的同事认为像GetPayments（customerID）这样的函数属于管理客户的类。所以，它就像Customer.GetPayments（）AS Payments。但是，如果我有一些像Worker这样的其他实体，那么就会有Worker.GetPayments（）AS Payments。所以，我看到了这两种方法的逻辑。第一个将事物分组在一起，这样，无论付款来自谁，您都可以通过GetPaymentsByCustomer（CustomerID）和GetPaymentsByWorker（WorkerID）等功能从一个类中获取。通过这种方式，您不必偶然通过不同的处理程序或经理对象来获得付款。这两种方法对我都有意义，你呢？或者，我们都关闭了，还有更好的方法吗？ 提前谢谢！
答案 0 :(得分：2)
如果您正在设计API，那么也许您可以尝试从预期用户的角度编写一些模型。实现一些用例，即使它只是在白板上，看看哪种方法更有价值。
在您的付款示例中，工作人员和客户都可以实施Payable接口。如果您以后必须添加一个可以“付费”的对象，您只需让它实现相同的界面即可。如果您有一个支付处理程序并且需要添加可以支付的新类型的东西，则必须通过添加新方法来更改处理程序。随着时间的推移，我想这可能会变得很麻烦。您当然可以使用两者的组合，并使用处理程序实用程序作为支付系统的前端。
答案 1 :(得分：2)
您几乎描述了数据访问的两种方式（模式）：
请获取Martin Fowler的书Patterns of Enterprise Application Architecture，并阅读所有优点和缺点。特别是如果您尝试将对象和API公开为Web服务，您可能希望使用数据映射器方法（如您所建议的那样）。
活跃记录非常受欢迎，因为它更简单。自己决定最适合自己需求的套装。
答案 2 :(得分：0)
在“它属于哪里”的辩论中，我通常根据它返回的内容决定某些东西所属的位置。如果您有一个返回Payment对象列表的GetPayments（）方法，它应该在PaymentHandler上。
这确实是一个非常主观的事情，但是通过返回类型执行它可以确保创建Payment对象的所有内容都在PaymentHandler中，CustomerHandler中的Customer对象等等。
当您需要稍后进行更改时，这可以简化一些事情，正如您所提到的那样，您的API用户很容易找出他们需要调用的处理程序 - 如果他们需要客户，他们将会工作与CustomerHandler合作。
如果你有像GetPayments（customerId，workerId）这样的假设方法可以为客户和工人付款，那么它也可以消除混淆。使用您的同事建议，由于涉及付款，客户和工作人员，因此不清楚此方法的用途。按返回类型分类几乎总是清楚的，因为函数只返回一件事。