I have to implement classes that work with payment system (let’s call it PaymentSystem) API that allow operations listed below:
- Issue an invoice to the user
- Check the invoice
- Get users balance
- Check payee existence
What I’ve got now is:
abstract class PaymentSystemBase where all the settings are remain (security token, password, RESTful APIs URL, etc.)
a class for each API entry:
PaymentSystemIssueInvoicePaymentSystemCheckInvoicePaymentSystemGetBalancePaymentSystemCheckUser
each of this classes are inherited from PaymentSystemAPI with methods (inherited from PaymentSystemBase, of course):
request– performs request over HTTPparseResponseto parse response from API (basically tells whether request was successful or we’ve got an error)
So my question is: would it be convenient to use some creation design pattern for the APIs (IssueInvoice, CheckInvoice, GetBalance, CheckUser)?
If you have suggestion for me how I should’ve implemented the API in the another way, please feel free to answer/comment the question.
Thank you.
This may be similar to command (noted by Irfy).
If you have complex logic that determines which subclass of a base class to use (i.e. more than is reasonable to do with a few constructor params), then you can use the factory pattern.
I’ll throw strategy out there as well, but we may be getting off-track.
As a general note on design patterns, you should use them with a purpose. Typically patterns are used to:
In particular, if the subclasses you are choosing may change in the future, it is good to abstract the code that decided which one to use. The factory pattern does this by encapsulating this logic in a single class.
I strikes me as odd that you are using a handful of classes to represent what looks like methods. But, it sounds like you’re working with another API, so I’d need more info to advise further.