È cattiva progettazione lasciare una classe Constants durante il refactoring?

Il problema non è che non dovresti avere una classe di costanti. Sta avendo una classe che tu pensi come "la nostra classe di costanti". Se fossi un giovane giovane sviluppatore della tua squadra e avessi visto una "classe di costanti", potrei pensare "oh, quindi questo è dove mettere quella costante di PI di cui ho bisogno. La metterò proprio accanto a questa costante" percorso " entrambi iniziano con p.

Cosa c'è di sbagliato in questo? Immagina come sarà questa classe tra 5 anni.

Dai a questa cosa una singola responsabilità e un nome che lo rispecchia. In seguito troverai meno confusione.

Se ciò non può essere fatto perché c'è già molto confuso disordine, allora inizia a buttare fuori le cose.

Le costanti che esistono per supportare la stessa cosa dovrebbero stare insieme. Le costanti che supportano cose diverse dovrebbero essere separate.

Ciò dovrebbe consentire a coloro che cambiano insieme di stare insieme e quelli che cambiano in modo indipendente di vivere separatamente.

Altrimenti hai appena messo un cassetto della spazzatura nel cuore della tua applicazione. Non esattamente un design elegante.

Se potessi dare un po 'più di contesto attorno al dominio e alla natura delle costanti, saremmo probabilmente in grado di aiutarti un po' di più.

Ma, nella maggior parte dei casi, una costante fa parte di un dominio specifico. Di conseguenza, questa costante dovrebbe risiedere in una classe specifica (che incapsula l'intera logica di questo dominio). Idealmente, non dovresti avere% classi% co_de. Invece, dovresti strutturare il tuo sistema come un insieme di classi, dove le costanti richieste vengono distribuite a queste classi e ogni classe esegue una logica specifica basata su queste costanti, esponendo questa logica tramite un'API ben definita agli utenti di questa classe (ma di nuovo idealmente, senza esporre le costanti stesse).