2016-04-04 17 views
10

In questo momento sto avendo una grande quantità di stringhe costanti ed enumerazioni nel mio progetto. Dal momento che l'inizio di esso stavo usando il seguente approccio (pseudo PHP codice di esempio):Come mantenere le mie costanti in PHP

class Constants implements iStatuses, iEmailTypes { 
} 

interface iStatuses { 
    const STATUS_NEW = 1; 
    cosnt STATUS_UPDATED =2; 
    ... 
} 

interface iEmailTypes { 
    const EMAIL_TYPE_NEW = 1; 
    const EMAIL_TYPE_UPDATED =2; 
    ... 
} 

Questo approccio mi ha permesso di mettere le costanti in un modo seguente in qualsiasi punto di un codice, dal momento che ho inserito classe 'Costanti' in l'index.php.

$this->sendEmailByType(CONSTANTS::EMAIL_TYPE_NEW); 

Tuttavia, posso vedere totalmente aspetti negativi di questo approccio:

  1. Costanti di classe è sovraccarico con un sacco di enumerazioni e costanti ed è molto difficile da ottenere costante destra. La convenzione di denominazione aiuta a risolverlo, ma non mi piace, dal momento che richiede ulteriori riflessioni per identificare quale costante ho bisogno
  2. La classe delle costanti è troppo grande e caotica
  3. Ho bisogno di tenere traccia di tutte le interfacce, essendo implementato dalla classe Cosntants.

Dal momento che il mio progetto sta diventando molto più grande ora e abbiamo bisogno di unirlo con un altro codice di progetto, è necessario che l'approccio di classe delle costanti sia cambiato. Tuttavia, ho ricevuto troppe dipendenze basate su quella classe. Come dovrei ristrutturare questo approccio, per non rompere il vecchio codice che utilizzava i valori della classe delle costanti.

Per favore, condividi i tuoi pensieri e suggerimenti, come migliorare il mio approccio alle 'costanti', o confermare che è decentemente buono e dovrei sostenerlo.

Grazie in anticipo.

+0

è difficile rispondere senza conoscere il resto della struttura, ma vorrei individuare eventuali costanti nella parte superiore di qualsiasi classe di controller associato (o anche entità) che si occupano di quell'area. – DevDonkey

+0

Cosa succede se voglio avere costanti condivise su molti controller? –

+4

È un requisito rigoroso avere tutte le costanti nella classe 'Constants'? Mi aspetterei che le costanti relative a ogni classe siano accessibili tramite quella classe (è anche il modo in cui esistono costanti PHP integrate). – apokryfos

risposta

11

Perché non solo avere classi costanti per ogni contesto. vale a dire

class Statuses 
{ 
    const STATUS_NEW = 1; 
    const STATUS_UPDATED =2; 
    ... 
} 

class EmailTypes 
{ 
    const EMAIL_TYPE_NEW = 1; 
    const EMAIL_TYPE_UPDATED =2; 
    ... 
} 

Più tardi, quando voi o altri programmatori vuole contribuire alla vostra applicazione che facilmente possono controllare le costanti relative sull'argomento si aspetta, invece guardando in una grande piscina di costante.

.e.g, una volta cercando una bandiera attorno ai tipi di email, mi aspetterei di trovarla entro EmailType:: e se non è presente, sentitevi sicuri di aggiungerla nella stessa classe.

+1

Questo è decisamente meglio della mia Idea. Tuttavia, quale classe dovrebbe fare qualche logica addizionale, relativa alle costanti?Ad esempio, ho 10 stati, alcuni dei quali stanno 'finendo' nel senso che se l'e-mail è in stato 'Accettato', non può cambiare in nessun altro, e alcuni di essi sono 'InProgress', che significa, quello stato cambierà più a lungo. Quindi ho bisogno di un fuckedion isStatusFinal ($ status). Devo implementare nella classe Statuses, come suggerito? –

+3

Suggerirei persino di eliminare il prefisso ridondante. 'Statuses :: NEW' andrà bene. – deceze

Problemi correlati