Devo usare una classe per una costante?

Bene, in primo luogo, i nomi delle classi sono solitamente singolari per convenzione.

Quindi, le costanti dovrebbero esistere nelle loro classi pertinenti.

Ad esempio:

public class Building{
    public static final integer MAX_HEIGHT=300;
    ... more constants and behavior ...
}

public class WindowPane{
    public static final integer MAX_HEIGHT=400;
    ... more constants and behavior ...
}

public class PlantStalk{
    public static final integer MAX_HEIGHT=100;
    ... more constants and behavior ...
}

Building.MAX_HEIGHT è più intenzionalmente evidente di Constants.MAX_HEIGHT .

Inoltre, evidentemente, Building.MAX_HEIGHT , WindowPane.MAX_HEIGHT e PlantStalk.MAX_HEIGHT non hanno nulla a che fare l'un l'altro, quindi non è come se fossero "violare SRP" .

Avere le costanti nelle loro classi pertinenti risolve entrambi i "dovrei avere un solo dilemma di classe" di costanti e il "dovrei avere una classe con una sola costante e nessun comportamento " dilemma.

Risposte correlate:

Uso di classi pubbliche nidificate per organizzare le costanti

È una cattiva pratica avere un'interfaccia per definire le costanti?

Pensiamo a questo in termini di astrazione (s) disponibili per i programmatori client.

AppConstants.HEIGHT_MAX non è la migliore interfaccia.

Innanzitutto, supponendo che altezza, larghezza e conteggio siano effettivamente correlati, dobbiamo almeno nominare la classe qualcosa di rilevante per il dominio, qualcosa che indica che tutte le costanti sono correlate.

In secondo luogo, è necessario specificare alcune unità in qualche modo. Ad esempio, l'altezza in pollici rispetto all'altezza in cm. (È un peccato che molti linguaggi di programmazione comuni non offrano caratteristiche specifiche (tipo sistema) per questo.)

Idealmente, naturalmente, il concetto ora ben definito (invece di AppConstants ) viene anche inserito in uno spazio dei nomi che aiuta a comunicare il suo significato.

Per ottenere la risposta alla tua domanda, tutto sommato, IMHO, è meglio avere una buona, unificata e utile astrazione piuttosto che separare questi elementi per il solo scopo di (importare l'overhead mascherandosi come) una singola responsabilità. L'astrazione unificata che raccoglie le costanti è una singola responsabilità, mentre le singole costanti da sole creano astrazioni impoverite.

Per quanto riguarda le alternative, direi che il sovraccarico di gestione di più classi / importazioni per quei client che hanno bisogno di più di una delle costanti, penso, superi il sovraccarico (praticamente inesistente) dell'importazione di più costanti del necessario in una classe orientata al dominio per quei client che hanno bisogno solo di una delle costanti.

Probabilmente scoprirai anche che alcuni comportamenti sono desiderabili all'interno dell'astrazione. Conversioni, ecc. Vorrei ancora dire che questo rende l'astrazione migliore e più completa e suddividere le cose fa più male che aiuto.

Qualcosa come HEIGHT_MAX è davvero un livello di applicazione costante? Sicuramente l'altezza massima è legata ad alcuni dati o funzionalità specifici e dovrebbe essere espressa più vicino a questo? Come in una costante di livello di classe. O forse dovrebbe essere localizzato nella configurazione e poi passato in fase di inizializzazione dell'oggetto pertinente.

È difficile dire qualcosa di definitivo senza conoscere il caso d'uso, ma ho il strong sospetto che al di sotto del tuo enigma ci sia un problema di design più grande.

+1 sulla ridenominazione. Considera, quali sono le costanti relative concettualmente / semanticamente. Questo dovrebbe essere il principio di raggruppamento, non i meccanismi di importazione ecc.

Quindi, HEIGHT_MAX di cosa? WEIGHT_MAX di cosa? Ottieni la mia direzione. Il "Important_Thing" a cui si riferiscono è l'informazione più utile.