L'idea alla base di incapsulamento nella programmazione orientata agli oggetti sta spostando i dati e il codice che lo usa insieme.
Non c'è "ma i dati sono costanti, trattali in modo speciale". Se hai colori, mantienili in una classe Color . La classe Calendar di Java contiene costanti di campo del calendario. BigDecimal e BigInteger contengono ciascuno costanti del proprio tipo.
L'idea è che le costanti di riferimento coinvolgono il loro ambito: BigDecimal.ZERO per esempio. So che è uno zero decimale perché ho digitato BigDecimal.ZERO e non BigInteger.ZERO .
Uno dei peggiori anti-schemi a questo riguardo è avere una "interfaccia costante" che è onestamente pigra e poco chiara. A volte ti imbatti in un'interfaccia contenente un insieme di costanti casuali messe insieme e le classi implementano l'interfaccia solo per rendere più facile fare riferimento alle costanti. Questo generalmente finisce per violare LSP e rende difficile determinare cosa fanno quelle costanti.
Le costanti dovrebbero essere:
-
Un enum se appropriato, come java.math.RoundingMode . I campi del calendario Java creati prima della presenza di enum dovrebbero essere enumerati. Ciò necessariamente li spazia correttamente e assicura che le altre costanti non si trovino nello stesso spazio dei nomi (campo statico finale della classe).
-
Situato nella classe che definisce il loro tipo, se appropriato. Questo copre i numeri riutilizzabili su BigDecimal per esempio.
-
Individuato da qualche altra parte dove le costanti come sono insieme e non sono mescolate con altre, a differenza delle costanti.
Si potrebbe sostenere che questa è una questione di opinione. Sento che se hai chiesto ad un gruppo di esperti di confrontarti, ad es. BigDecimal e alcune classi di costanti AWT casuali, arriveremmo a un consenso sul fatto che ci sono alcune pratiche veramente cattive nella realtà e alcune che rendono il codice più chiaro e più facile da capire.