I would like to build a system that basically offers the option to make various APIs interchangeable for usage to the end user. For example, the person using the software would have the option of choosing a single existing supported Billing System at any one time. They could for example choose to use WHMCS, Host Bill or Blesta.

The way I picture doing this, I have a base "Billing_System" class that has generic methods that are then inherited and implemented differently depending on the system chosen. For example...


class Billing_System
    /* Connect to Billing System API */
    public function connect($hostname, $username, $password)


    /* Fetch list of all due invoices */
    public function get_invoices()


    /* Fetch invoice data by invoice ID */
    public function get_invoice($invoice_id)


    /* Fetch invoices for specific client */
    public function get_client_invoice($client_id)



Then have WHMCS, HostBill and Blesta classes that extend Billing_System and re-implement these methods as needed for the specific API's being used.

My question would be is this a plugin type system or just architecture? Would it be possible to somehow initialize the Billing System by name making it easier to add additional systems without having to update mass amounts of existing files to add includes/etc?


$billing = new Billing_System("WHMCS", "whmcs.mysite.com", "admin", "1234abcd");

All I can see above is just an application of the strategy pattern.

How much you have to extend this code to make this a real "plugin architecture" is debatable, but IMHO the central point is to have the deployment of new billing system implementations decoupled from the deployment of the main system. Ideally, you, your team, or a third party can deliver new Billing_System classes without the necessity to deploy a new release of your main system. There should be a fixed, stable, documented plugin API. And ideally it should not even be necessary to restart your server after a new billing system was added (though I think that's not mandatory).

  • That is exactly what I was looking for, thank you. I have wanted to do similar things with past projects and not knowing this was a strategy pattern, I implemented less efficient implementations that worked but not fully decoupled. So this alone would not technically make it a plugin system? Regardless, it does address my question and needs exactly and will be very useful to know now :) Nov 7 '14 at 16:19
  • @BrettPowell: in my understanding of the term "plugin system" a strategy class alone does not make a plugin. It may be debatable if plugin systems can always be interpreted as a kind of "strategy pattern", even when implemented without any object orientated tools.
    – Doc Brown
    Nov 7 '14 at 16:30
  • Perfect explanation, thank you. I suppose a true plugin system would actually auto load all of them to some extent, where you would then enable/disable as needed. In this particular case however, we would only be using one of each type at a time while others may be available. Nov 7 '14 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.