Questo sarebbe considerato un plugin o un'architettura di tipo di modello?

1

Mi piacerebbe creare un sistema che fondamentalmente offra la possibilità di rendere diverse API intercambiabili per l'utilizzo all'utente finale. Ad esempio, la persona che utilizza il software avrebbe la possibilità di scegliere un singolo sistema di fatturazione esistente esistente in qualsiasi momento. Potrebbero ad esempio scegliere di utilizzare WHMCS, Host Bill o Blesta.

Il modo in cui immagino di farlo, ho una classe base "Billing_System" che ha metodi generici che vengono poi ereditati e implementati in modo diverso a seconda del sistema scelto. Ad esempio ...

<?

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)
    {

    }
}

?>

Quindi disponi di classi WHMCS, HostBill e Blesta che estendono Billing_System e reimplementa questi metodi come necessario per le API specifiche utilizzate.

La mia domanda sarebbe: questo è un sistema di tipo plugin o solo architettura? Sarebbe possibile in qualche modo inizializzare il sistema di fatturazione per nome rendendo più semplice l'aggiunta di sistemi aggiuntivi senza dover aggiornare quantità massicce di file esistenti per aggiungere include / etc?

Esempio:

$billing = new Billing_System("WHMCS", "whmcs.mysite.com", "admin", "1234abcd");
    
posta Aidan Knight 07.11.2014 - 15:07
fonte

1 risposta

1

Tutto quello che posso vedere sopra è solo un'applicazione del modello di strategia .

Quanto devi estendere questo codice per renderlo una vera " architettura di plugin " È discutibile, ma IMHO il punto centrale è avere la distribuzione di nuove implementazioni del sistema di fatturazione disaccoppiata dall'implementazione del sistema principale. Idealmente, tu, il tuo team o una terza parte puoi offrire nuove classi Billing_System senza la necessità di distribuire una nuova versione del tuo sistema principale. Ci dovrebbe essere un'API di plugin fissa, stabile e documentata. E idealmente non dovrebbe nemmeno essere necessario riavviare il server dopo aver aggiunto un nuovo sistema di fatturazione (anche se penso che non sia obbligatorio).

    
risposta data 07.11.2014 - 17:10
fonte