Warum wird nicht empfohlen, Konstanten in einer separaten Klasse zu speichern?

Es wurde mir gesagt (und ich habe diese Aussage an einigen anderen Stellen gesehen), dass es nicht empfohlen wird, Ihre Konstanten in einer separaten Klasse in Java zu speichern, um sie in den anderen Klassen zu verwenden. Aber ich habe nirgends gesehen warum ist es so. Aus welchem Grund sollte ich sie nicht in ihrer eigenen Schnittstelle/Klasse speichern?Warum wird nicht empfohlen, Konstanten in einer separaten Klasse zu speichern?

Ich kam von C nach Java und in C würde ich eine .h Datei machen nur, wo ich mit Ausgabe #define

Quelle

2013-02-24 Bujanca Mihai

Sprechen wir hier über Konstanten oder Einschränkungen, und wenn die Letzteren, welche Einschränkungen meinen Sie? –

Warten Sie eine Minute ... Beziehen Sie sich auf * Konstanten * oder * Einschränkungen *? –

Entschuldigung, ich habe es schlecht geschrieben, danke –

Konstanten in einer dedizierten Datei sind aus stilistischen Gründen verpönt. Eine Klasse, die Konstanten gewidmet ist, kann Entwickler dazu ermutigen, immer mehr unzusammenhängende (undokumentierte?) Konstanten zu einer Datei hinzuzufügen, die langsam außer Kontrolle gerät.

Im Gegensatz dazu ist es ein skalierbareres und lesbareres Design, wenn Konstanten mit den Klassen verbunden sind, auf die sie sich beziehen.

Quelle

2013-02-24 20:45:23

"Single" ist relativ. Pro Paket oder UOR ist angemessen. Pro gesamte Codebasis wahrscheinlich nicht. Und auf den Servern von Google sollte es sicher keine zentrale Config-Datei geben, die die übrigen Java-Entwickler über eine Web-Oberfläche pflegen. – djechlin

Wäre es nicht viel einfacher, dokumentiert zu werden, wenn alle für jedes Paket eine einzige Klasse bilden? Selbst wenn Entwickler dazu neigen, zu viele Konstanten hinzuzufügen, werden sie diese beim Erstellen der Dokumentation los. Es erscheint mir immer noch besser, als Konstanten in verschiedene Klassen einzubauen oder sie sogar in einer einzigen Klasse zusammenzufassen und dann die nutzlosen bei der Erstellung der Dokumentation loszuwerden. –

@BujancaMihai Persönlich denke ich nicht. Ich halte Konstanten mit den Klassen verbunden, denen sie "angehören". Ich finde das einfacher zu lesen (jede Klasse kann einige private Konstanten haben, einige paket-private usw.). Gegebenenfalls sammele ich verwandte Konstanten in einer Aufzählung. –

-5

Konstanten definiert ist, dass sie außerhalb des Quellcodes leben ganz werden sollte. Sie sollten etwas wie Apache Commons Config verwenden oder zumindest aus einer .properties Datei laden.

Ich werde auch feststellen, dass ich "single" in Bezug auf einen vernünftigen Umfang interpretiere. Zum Beispiel sollte es keine Konfigurationsdatei für alle Java-Entwickler geben, die auf den Servern von Google mit einem Anfrageformular zum Ändern gespeichert sind. Es sollte wahrscheinlich nicht für Ihre gesamte Codebasis getan werden; pro UOR oder Paket ist jedoch ein vernünftiger Umfang, und ist derjenige, den ich in der Praxis verwende.

Quelle

2013-02-24 20:42:46 djechlin

Wieder ... das OP fragt * warum * sie sollten nicht in einer dedizierten Klasse gespeichert werden. –

Nein, sie sollten nicht außerhalb des Quellcodes leben, da zum Beispiel ein ganzes Paket Klassen hat, die es benutzen, aber es gibt keine externe Abhängigkeit –

@DuncanJones "Was ist der Grund, warum ich sie nicht in ihrer eigenen Schnittstelle speichern sollte/Klasse?" weil sie in keiner Schnittstelle/Klasse sein sollten. – djechlin

So können Sie ein Ingenieur sein und Konstanten und ihre Standorte als eine technische Wahl messen. Das ist großartig und gut, wenn Sie an leistungskritischen Systemen oder an coolen kleinen Snippets arbeiten. Sobald Ihre Anwendung jedoch wächst, wird es immer schwieriger, die Geschäftsanforderungen und die Bedürfnisse der Endbenutzer zu erfassen, die sich im Code widerspiegeln.

Anstatt über Stil zu denken - separate Klasse, Eigenschaftendatei oder innerhalb einer Klasse verschachtelt - tendiere ich dazu, zu folgen domain driven design - wenn die Menge der Konstanten ausschließlich zu einer bestimmten Klasse (Entität) gehören, verschachteln Sie die Konstanten; Wenn das Konzept mehr als eine Entität in Ihrem Domänenmodell berührt, können Sie es als separate Entität definieren.

Und bitte denken Sie daran, dass seit Java 5, Sie enums zu Ihrer Verfügung haben.

Quelle

2013-02-24 20:44:02

Danke für den Rat, aber immer noch, Sie sagen mir nicht wirklich, warum sollte ich eine separate Klasse verwenden, um Konstanten zu speichern –

Guter Fang, bearbeitet nach Ihrem Rat. –

Es scheint mir schwieriger zu sein, Ihre 'public' Konstanten zu verfolgen, die in mehr Klassen verwendet werden, wenn Konstanten über viele Klassen verteilt werden. Natürlich stimme ich zu, dass "private" Konstanten in ihren Klassen bleiben sollten. –

Eine separate Konstantenklasse ist kein objektorientiertes Design. In OO stellt eine Klasse (oder Schnittstelle) einen Vertrag dar, und eine Klasse, die nur Konstanten enthält, definiert keinen Vertrag.

Eine weitere objektorientierte Überlegung ist, dass eine separate Konstantenklasse den Missbrauch der Vererbung fördert. Die Vererbung soll anzeigen, dass eine Klasse vollständig an den von einer anderen Klasse oder Schnittstelle definierten Vertrag gebunden ist. Vererbung sollte nicht nur verwendet werden, um Funktionalität oder Konstanten zu teilen; das ist, was public Methoden und Felder sind für. Daher ist dieser Code falsch:

class SomeApplicationClass 
implements ScrollPaneConstants // Incorrect, import ScrollPaneConstants instead

Quelle

2013-02-25 13:40:07 VGR

Warum wird nicht empfohlen, Konstanten in einer separaten Klasse zu speichern?

Antwort

Verwandte Themen