Costanti e proprietà pubbliche per la configurazione

2

La mia applicazione ha alcune opzioni di configurazione di alto livello come le directory che verranno utilizzate per varie cose, le informazioni sulla connessione al database e alcune altre impostazioni richieste per l'esecuzione dell'applicazione.

Sto discutendo con me stesso se le costanti sono o meno meglio delle variabili per questo scopo e vorremmo qualche input.

Avendo:

 $config = new Config;
 new Whatever($config->foo, $config->bar);

Invece di:

new Whatever(Config::FOO, Config::BAR);

Ottengo il potere del polimorfismo, posso rapidamente scambiare le impostazioni di configurazione istanziando $ config come una classe diversa con gli stessi membri della classe.

Ovviamente c'è un compromesso qui. Qualunque cosa abbia bisogno delle opzioni di configurazione deve istanziare un oggetto $ config, usare la memoria e creare un codice extra e renderlo così le opzioni di configurazione non sono immutabili a lungo.

Il problema dell'immutabilità potrebbe essere risolto con un metodo, ad es. $ Config > get ( 'foo'); quindi è potenzialmente un non-problema, anche se aggiunge alla verbosità e una chiamata al metodo è più costosa della lettura di una costante o di una variabile.

    
posta Tom B 02.03.2014 - 23:14
fonte

2 risposte

1

Per le opzioni di configurazione, è meglio usare proprietà (o metodi) invece di costanti. Il motivo è che le opzioni di configurazione cambiano quando si distribuisce l'applicazione in un ambiente diverso.

Quando usi proprietà / metodi, puoi scegliere di leggere i valori rilevanti da un file di configurazione all'avvio, il che non è possibile se usi costanti.

Il sovraccarico di creazione di un oggetto Config può essere ridotto al minimo disponendo di un oggetto globale e rendendolo disponibile in tutta l'applicazione utilizzando Dortency Injection o il pattern Singleton.
La preoccupazione per l'overhead di una chiamata di funzione è molto probabilmente l'ottimizzazione prematura. È improbabile che importi e nei rari casi in cui lo fa (ad esempio in un circuito chiuso), ci sono altre soluzioni, come la lettura del valore di configurazione in un momento non critico e il caching del valore in una proprietà / variabile.

    
risposta data 03.03.2014 - 09:16
fonte
1

Le costanti hanno una cattiva abitudine di non restante costante, specialmente per lunghi periodi di tempo.

Se si scende lungo la rotta delle costanti, alcuni strumenti di sviluppo estraggono il valore "costante" in tempo di compilazione e seppelliscono tale valore in qualsiasi modulo di codice che stanno costruendo. Efficiente? Sì. Ma, se in seguito decidi che devi cambiare quella "costante" ad alcuni altri valori, allora quelle applicazioni "early-bound" verranno interrotte. Il tuo nuovo codice riconoscerà il nuovo valore, ma quegli altri componenti passeranno ancora il vecchio.

Se passi alla strada delle proprietà pubbliche, ogni applicazione arriverà al tuo componente in fase di esecuzione per acquisire il valore e così otterrà sempre quella giusta (a meno che non l'abbia scritta in modo sconveniente in qualche archivio dati esterno , ovviamente). Proteggiti da ciò evitando di riutilizzare gli stessi valori sottostanti: se hai utilizzato inizialmente i valori 0 .. 3, non utilizzare alcun di questi valori dopo il refactoring.

Saluti,    Phill W.

    
risposta data 03.03.2014 - 18:28
fonte

Leggi altre domande sui tag