Quali sono le alternative più aggraziate alle interfacce costanti?

Stavo guardando un codice sviluppato da un gruppo off-shore. Vedo almeno una "interfaccia costante" per modulo definito. Esempio (non reali):Quali sono le alternative più aggraziate alle interfacce costanti?

public interface RequestConstants{ 
    //a mix of different constants(int,string,...) 
    public static final int MAX_REQUESTS = 9999; 
    public static final String SAMPLE_REQUEST = "Sample Request"; 
}

Per la mia comprensione, è un anti-modello in quanto questi non lo fa qualsiasi utilità in fase di esecuzione, e dovrebbero essere evitati o affrontati in modo diverso. Quali sono i modi eleganti per rappresentarlo? È possibile utilizzare enums?

fonte

2011-09-15 ring bearer

Wow! giù voto. ma perché? –

Raccomando di testare rigorosamente la funzionalità della loro programmazione e di non preoccuparsi di problemi come questo fino a quando non trovi funzionalità interrotte. – emory

En enum probabilmente non è una buona idea a meno che tutti i parametri non siano strettamente correlati. Con i due parametri nel tuo esempio, direi che non sono strettamente correlati per qualificarsi come enum.

Ma non è necessariamente una cattiva idea includere una classe/interfaccia di costanti come questa. Ha il vantaggio di essere centralizzato, il che significa che questa configurazione può essere facilmente spostata all'esterno del programma, ad esempio un file di proprietà, un decodificatore da riga di comando, un database o persino un'interfaccia socket, con un impatto minimo su le altre classi. È davvero una questione di quale direzione prenderà il progetto.

A meno che non stiate pensando di seguire questa strada, tuttavia, direi che le finali statiche nelle classi in cui vengono utilizzati i rispettivi parametri è la strada da percorrere, come è stato già suggerito.

fonte

2011-09-15 19:59:41 Uffe

Sono d'accordo. L'uso di enumerazioni o di classi invece di interfacce potrebbe interrompere il codice esistente. Non lo vedo come un serio anti-modello. – emory

Trasforma l'interfaccia in una classe final con un costruttore private.

fonte

2011-09-15 19:49:24 nfechner

Sarebbe bello ... –

preferisco mettere le costanti nella classe dove fanno sono più rilevanti, e poi se mi avere per riferirsi a loro altrove, basta fare in modo - possibilmente utilizzando le importazioni statiche, se questo ha un senso (ad esempio, per Math.PI).

L'unica vera ragione per inserire le costanti nelle interfacce era consentire all'utente di "implementare" l'interfaccia priva di metodo e ottenere l'accesso alle costanti tramite i loro nomi semplici senza ulteriori qualifiche. Le importazioni statiche rimuovono questa ragione.

fonte

2011-09-15 19:49:25

Le importazioni statiche non raggiungono esattamente l'effetto desiderato in alcune circostanze. Se ho più classi in un file .java (ad esempio file nidificati), ogni classe può avere il proprio insieme di costanti e alcune di esse potrebbero avere nomi sovrapposti. L'utilizzo di un'importazione statica significherebbe un conflitto. – emory

@emory: vero. D'altra parte, non vorrei usare il trucco dell'interfaccia in quel caso - avere lo stesso nome costante che significa cose diverse nello stesso file suona come una cattiva idea per me. –

@Jon Skeet - "L'unica vera ragione per mettere le costanti nelle interfacce era consentire di" implementare "l'interfaccia senza metodo e ottenere l'accesso alle costanti tramite i loro nomi semplici" - I suoni sono molto interessanti. Ma non è una pratica peggiore da un punto di vista OO - come si relaziona nel mondo reale? - grazie per la tua risposta. –

Utilizzare la classe finale non istantanea, ovvero una con un costruttore privato.

fonte

2011-09-15 19:49:45

... se i downvotes su queste risposte sono stati spiegati. –

Quali sono le alternative più aggraziate alle interfacce costanti?

risposta

Problemi correlati