Come si definisce una classe di costanti in Java?

Supponi di dover definire una classe che tutto ciò che fa è contenere costanti.

public static final String SOME_CONST = "SOME_VALUE";

Qual è il modo preferito per farlo?

1. Interfaccia
2. Classe astratta
3. Classe finale

Quale dovrei usare e perché?

Enumerazioni : non userò le enumerazioni, non enumererò nulla, ma raccolgo solo alcune costanti che non sono correlate tra loro in alcun modo.

Interfaccia : non imposterò nessuna classe come una che implementa l'interfaccia. Voglio solo utilizzare l'interfaccia per richiamare le costanti in questo modo: ISomeInterface.SOME_CONST.

Usa una lezione finale. per semplicità puoi quindi utilizzare un'importazione statica per riutilizzare i tuoi valori in un'altra classe

public final class MyValues {
  public static final String VALUE1 = "foo";
  public static final String VALUE2 = "bar";
}

in un'altra classe:

import static MyValues.*
//...

if(variable.equals(VALUE1)){
//...
}

Il tuo chiarimento afferma: "Non userò enumerazioni, non enumererò nulla, raccoglierò solo alcune costanti che non sono correlate tra loro in alcun modo".

Se le costanti non sono affatto correlate tra loro, perché vuoi raccoglierle insieme? Metti ogni costante nella classe a cui è più strettamente correlata.

I miei suggerimenti (in ordine decrescente di preferenza):

1) Non farlo . Crea le costanti nella classe effettiva in cui sono più rilevanti. Avere una classe / interfaccia "bag of constants" non sta seguendo le migliori pratiche OO.

Io e tutti gli altri ignoriamo il numero 1 di tanto in tanto. Se hai intenzione di farlo, allora:

2) classe finale con costruttore privato Questo almeno impedirà a chiunque di abusare del tuo "bagaglio di costanti" estendendolo / implementandolo per ottenere un facile accesso alle costanti. (So ​​che hai detto che non l'avresti fatto, ma questo non significa che qualcuno verrà dopo che non lo farai)

3) interfaccia Funzionerà, ma non è mia preferenza a menzionare l'eventuale abuso al punto 2.

In generale, solo perché queste sono costanti non significa che non dovresti ancora applicare loro i normali principi oo. Se nessuno tranne una classe si preoccupa di una costante, dovrebbe essere privato e in quella classe. Se solo ai test interessa una costante, dovrebbe essere in una classe di test, non nel codice di produzione. Se una costante è definita in più posizioni (non solo accidentalmente la stessa), eseguire il refactoring per eliminare la duplicazione. E così via - trattali come faresti con un metodo.

Come osserva Joshua Bloch in Effective Java:

• Le interfacce devono essere utilizzate solo per definire i tipi,
• le classi astratte non impediscono l'istanziabilità (possono essere sottoclasse e suggeriscono persino che sono progettate per essere sottoclasse).

Puoi usare un Enum se tutte le tue costanti sono correlate (come i nomi dei pianeti), inserire i valori delle costanti nelle classi a cui sono correlati (se hai accesso ad essi), o utilizzare una classe di utilità non instanciabile (definire un costruttore predefinito privato) .

class SomeConstants
{
    // Prevents instanciation of myself and my subclasses
    private SomeConstants() {}

    public final static String TOTO = "toto";
    public final static Integer TEN = 10;
    //...
}

Quindi, come già affermato, puoi utilizzare le importazioni statiche per utilizzare le tue costanti.

Il mio metodo preferito è non farlo affatto. L'età delle costanti è praticamente morta quando Java 5 ha introdotto le enumerazioni typesafe. E anche prima di allora Josh Bloch ha pubblicato una versione (leggermente più prolissa) di quella, che ha funzionato su Java 1.4 (e precedenti).

A meno che non sia necessaria l'interoperabilità con un codice legacy, non c'è davvero alcun motivo per utilizzare più costanti String / integer denominate.

Usa solo la lezione finale.

Se vuoi essere in grado di aggiungere altri valori usa una classe astratta.

Non ha molto senso usare un'interfaccia, si suppone che un'interfaccia specifichi un contratto. Vuoi solo dichiarare alcuni valori costanti.

Gli enum non sono la scelta migliore per questo tipo di cose?

enumvanno bene. IIRC, un elemento in Java effettivo (2a edizione) ha enumcostanti che enumerano le opzioni standard che implementano una [parola chiave Java] interfaceper qualsiasi valore.

La mia preferenza è quella di utilizzare una [parola chiave Java] interfacerispetto a una final classper le costanti. Ottieni implicitamente il file public static final. Alcune persone sosterranno che un interfaceconsente ai cattivi programmatori di implementarlo, ma i cattivi programmatori scriveranno codice che fa schifo qualunque cosa tu faccia.

Quale sembra migliore?

public final class SomeStuff {
     private SomeStuff() {
         throw new Error();
     }
     public static final String SOME_CONST = "Some value or another, I don't know.";
}

O:

public interface SomeStuff {
     String SOME_CONST = "Some value or another, I don't know.";
}

Oppure 4. Inseriscili nella classe che contiene la logica che utilizza maggiormente le costanti

... scusa, non ho resistito ;-)

1. Uno degli svantaggi del costruttore privato è che l'esistenza del metodo non potrebbe mai essere testata.

2. Enum per il concetto di natura buono da applicare in un tipo di dominio specifico, applicarlo a costanti decentralizzate non sembra abbastanza buono

Il concetto di Enum è "Le enumerazioni sono insiemi di elementi strettamente correlati".

3. Estendere / implementare un'interfaccia costante è una cattiva pratica, è difficile pensare alla necessità di estendere una costante immutabile invece di fare riferimento direttamente ad essa.

4. Se si applicano strumenti di qualità come SonarSource, ci sono regole che costringono gli sviluppatori a eliminare l'interfaccia costante, questa è una cosa imbarazzante poiché molti progetti godono dell'interfaccia costante e raramente vedono cose "estese" accadere su interfacce costanti