Ereditarietà con singleton

Penso che il design sia ben orientato, ma vorrei suggerire il seguente:

• Le licenze e i componenti aggiuntivi sono mappati tramite la proprietà $addon_name ma un metodo matches(add_on_name) deve essere aggiunto alla classe base per sapere se una licenza appartiene a un determinato componente aggiuntivo, o meglio ancora non passare nome aggiuntivo, ma il componente aggiuntivo stesso, in modo che il metodo matches possa eseguire una convalida più complessa in merito all'appartenenza o meno della licenza a tale componente aggiuntivo
• Occorre prestare attenzione in BundleLicense per ridurre la visibilità dei costruttori ereditati in modo che non possano essere utilizzati per creare un'istanza. Poiché ciò potrebbe essere complicato, una soluzione migliore sarebbe che ogni classe genitore abbia i propri costruttori privati (non so se questo possa essere applicato in PHP) e invece fornisca un metodo getInstance() . Tutte le classi non singleton restituirebbero una nuova istanza, ma il singleton restituirebbe sempre la stessa istanza. In questo modo non devi ridurre la visibilità dei costruttori delle superclassi, che non so se sia possibile in PHP.
• Un possibile difetto è che BundleLicense sembra coprire tutti i componenti aggiuntivi, dando potenzialmente accesso a componenti aggiuntivi a cui non dovrebbe dare accesso. Quindi suggerisco alle classi di avere un elenco privato di nomi di componenti aggiuntivi in una singola proprietà $addon_name . Le licenze non bundle avrebbero un elenco contenente un singolo nome aggiuntivo, ma le licenze bundle conterranno un elenco con due o più nomi aggiuntivi.

Una licenza è fondamentalmente un documento. Mi sembra strano che la tua licenza abbia metodi come Activate () e Deactivate (). Mi aspetterei una classe LicenseManager che faccia queste cose. La classe della licenza non dovrebbe fare altro che incapsulare la licenza. Potrebbe avere metodi Read () e Write () per leggere la licenza o scrivere la licenza su un file ma non dovrebbe contenere la logica che fa cose con le licenze.

Se sei veramente severo, non dovrebbe nemmeno leggere direttamente o scrivere sui file, dovrebbe avere un costruttore che accetta una stringa e offre una o più proprietà che forniscono la licenza nei formati per mantenerla o per visualizzarla . Potrebbe convalidare la licenza nel senso che "questa potrebbe essere una licenza valida" e lanciare se non è una licenza valida ma non dovrebbe conoscere l'applicazione o l'ambiente.

La licenza è dati. Fare la valutazione se la licenza è valida o meno per un utente, l'ambiente o il periodo di tempo e / o l'attivazione della licenza è una preoccupazione diversa che dovrebbe essere separata dalla licenza stessa.

Ho un prefisso che non so molto di php e di come Singleton è implementato in php .

L'uso di singleton condurrà sempre a discussioni, alcune persone sono categoricamente contro di loro, alcune sono sulla recinzione, altre vanno bene. Mi sono inserito nella categoria "on-the-fence". Ci sono alcuni posti in cui sono utili, per me il più delle volte quando si tratta di entità in cui si desidera un singolo punto di accesso senza dover passare qualcosa lungo una lunga catena di chiamate. Per esempio. una funzione di registrazione, gestione della memoria .... Limitare la pluralità di qualcosa da un business case (i tuoi requisiti) per me non è un buon caso d'uso per singleton. IMHO se rendi questa limitazione esplicita nel tuo codice piuttosto che usare qualcosa come un costrutto singleton, sarà molto più flessibile a lungo termine e richiederà meno cambiamenti nel codice quando i requisiti cambiano.