CODEWITHSUNDEEP
design-patterns
Nemoden
Nemoden

Reputation: 9056

Which design pattern should I use? (Payment system API)

I have to implement classes that work with payment system (let's call it PaymentSystem) API that allow operations listed below:

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:

each of this classes are inherited from PaymentSystemAPI with methods (inherited from PaymentSystemBase, of course):

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.

Upvotes: 1

Views: 3391

Answers (1)

Tony R
Tony R

Reputation: 11524

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:

  1. Increase code readability
  2. Increase code reusability.
  3. Separate what may change from what will not change.

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.

Upvotes: 2

Related Questions