I am designing an API and I would like it to be easy to use. So, if I have customers, applications and payments. Does it make sense to have such objects as: Customer, CustomerHandler, Statement, StatementHandler, Payment, PaymentHandler? Thus, when a developer wants to do something with clients that he / she knows to create a CustomerHandler, then all the functions that you would like to perform with the client are inside the handler.
Methods: CustomerHandler: AddCustomer (customer), GetCustomer (customerID), GetCustomerCount () ... StatementHandler: AddStatement (customerID), GetStatement (statementID), GetStatementCount (customerID) ... PaymentHandler: GetPaymentsByCustomer (customerID), GetPayment (paymentID) , GetPaymentCountByCustomer (customerID) ...
Thus, if the developer wants to work on receiving payments that he / she knows, to go to PaymentHandler. My colleague believed that features like GetPayments (customerID) belong to the class that manages the client. Thus, it will be similar to Client.GetPayments () AS Payments. But if I have another organization, such as Worker, there will be Worker.GetPayments () AS Payments. So, I see the logic with both approaches. The first combines things so that, regardless of which one of you receives the payment, you receive everything from one class, having functions such as GetPaymentsByCustomer (CustomerID) and GetPaymentsByWorker (WorkerID). Thus, you should not stumble upon different objects of the handler or manager in order to receive payments. Both approaches make sense to me, how about you? Or we both leftand is there a better way to do this? Thanks in advance!