Perché non è consigliabile memorizzare le costanti in una classe separata?

Mi è stato detto (e ho visto questa affermazione in pochi altri punti) che non è consigliabile memorizzare le costanti in una classe separata in Java, per poterle utilizzare nelle altre classi. Ma non ho visto da nessuna parte PERCHÉ è così. Qual è la ragione per cui non dovrei memorizzarli nella loro interfaccia/classe?Perché non è consigliabile memorizzare le costanti in una classe separata?

Sono venuto da C a Java e in C vorrei solo fare un file .h dove ho definito costanti con #define

fonte

2013-02-24 Bujanca Mihai

stiamo parlando costanti o vincoli qui, e in quest'ultimo caso, allora che cosa vincoli vuoi dire? –

Attendi un minuto ... Ti riferisci a * costanti * o * vincoli *? –

scusate, l'ho scritto male, grazie –

Le costanti in un file dedicato sono disapprovate per motivi stilistici. Avere una classe dedicata alle costanti può incoraggiare gli sviluppatori ad aggiungere un numero crescente di costanti non documentate (non documentate?) a un file che rallenta lentamente senza controllo.

Al contrario, avere costanti associate alle classi a cui sono correlate è un design più scalabile e leggibile.

fonte

2013-02-24 20:45:23

" Single "è relativo. Per pacchetto o UOR è ragionevole. Per l'intero codice base, probabilmente no. E certamente non ci dovrebbe essere un file di configurazione centrale memorizzato sui server di Google che gli sviluppatori Java del resto del mondo effettuano tramite un'interfaccia web. – djechlin

Non sarebbe molto più facile essere documentati se tutti fossero messi in una singola classe per ogni pacchetto ?. Anche se gli sviluppatori tendono ad aggiungere troppe costanti, si libereranno di esse quando creano la documentazione. Mi sembra ancora meglio che incorporare delle costanti in classi diverse o persino enumarle in una singola classe e poi ancora liberarsi di quelle inutili quando si fa la documentazione. –

@BujancaMihai Personalmente, penso di no. Tengo le costanti associate alle classi a cui "appartengono", trovo che sia più facile da leggere (ogni classe può avere alcune costanti private, alcune private di pacchetti, ecc.) Se appropriato, raccolgo costanti relative in un enum. –

-5

problema è che essi dovrebbero essere vivente al di fuori del codice sorgente del tutto. Dovresti usare qualcosa come Apache Commons Config, o almeno caricare da un file .properties.

Noterò anche che sto interpretando "singolo" rispetto ad uno scopo ragionevole. Ad esempio, non dovrebbe esserci un solo file di configurazione per tutti gli sviluppatori Java utilizzati memorizzati sui server di Google con un modulo di richiesta per la modifica. Probabilmente non dovrebbe essere fatto per l'intero codice base; tuttavia, per UOR o pacchetto è un ambito ragionevole ed è quello che uso in pratica.

fonte

2013-02-24 20:42:46 djechlin

Ancora .. l'OP chiede * perché * non dovrebbero essere memorizzati in una classe dedicata. –

No, non dovrebbero vivere al di fuori del codice sorgente, poiché ad esempio un intero pacchetto ha classi che lo usano, ma non c'è dipendenza esterna –

@DuncanJones "Qual è il motivo per cui non dovrei memorizzarli nella loro interfaccia/classe?" perché non dovrebbero essere in alcuna interfaccia/classe. – djechlin

Così puoi essere un ingegnere e misurare le costanti e le loro posizioni come scelta tecnica. Questo è ottimo e utile quando lavori su sistemi con prestazioni critiche o su piccoli snippet. Tuttavia, una volta che la domanda tende a crescere, diventa sempre più difficile cogliere i requisiti aziendali e le esigenze degli utenti finali riflesse nel codice.

Quindi invece di pensare allo stile - classe separata, file di proprietà o nidificato all'interno di una classe - Tendo a seguire domain driven design - se l'insieme di costanti appartiene esclusivamente a una classe specifica (entità), annidare le costanti; se il concetto tocca più di una delle entità nel tuo modello di dominio, sentiti libero di renderlo un'entità separata.

E per favore, ricorda che dal Java 5, hai enums a tua disposizione.

fonte

2013-02-24 20:44:02

Grazie per il consiglio, ma ancora, non mi dici veramente perché dovrei usare/non usare una classe separata per memorizzare le costanti –

Buona cattura, modificata secondo il tuo consiglio. –

Mi sembra più difficile tenere traccia delle costanti 'public', utilizzate in più classi se le costanti vengono diffuse attraverso molte classi. Naturalmente, sono d'accordo che le costanti 'private' dovrebbero rimanere nelle loro classi –

Una classe di costanti separata non è una progettazione orientata agli oggetti. In OO, una classe (o interfaccia) rappresenta un contratto e una classe che contiene solo costanti non definisce alcun contratto.

Un'altra considerazione orientata agli oggetti è che una classe di costanti separata incoraggia l'uso improprio dell'ereditarietà. L'ereditarietà dovrebbe indicare che una classe aderisce pienamente al contratto definito da un'altra classe o interfaccia. L'ereditarietà non dovrebbe essere utilizzata solo per condividere funzionalità o costanti; questo è quello che i metodi e i campi public sono per. Così, questo codice non è corretto:

class SomeApplicationClass 
implements ScrollPaneConstants // Incorrect, import ScrollPaneConstants instead

fonte

2013-02-25 13:40:07 VGR

Perché non è consigliabile memorizzare le costanti in una classe separata?

risposta

Problemi correlati