Ich habe die Frage und die Antworten gelesen: Wie lassen sich Konstanten am besten in Java implementieren?
Und kam zu der Entscheidung, dass enum ist besser Weg, um eine Reihe von Konstanten zu implementieren. Außerdem habe ich ein Beispiel auf der Sun-Website gelesen, wie man das Verhalten zu enum hinzufügen kann (siehe den Link im zuvor erwähnten Beitrag). Es ist also kein Problem, den Konstruktor mit einem String-Schlüssel zur enum hinzuzufügen, um eine Reihe von String-Werten zu speichern.
Das einzige Problem hier ist, dass wir ".nameOfProperty" hinzufügen müssen, um Zugriff auf den String-Wert zu erhalten. Überall im Code müssen wir also den Wert der Konstante nicht nur mit ihrem Namen ansprechen (EnumName.MY_CONSTANT), sondern auf diese Weise (Enum.MY_CONSTANT.propertyName).
Bin ich hier richtig? Was halten Sie davon?
0 Stimmen
Könnten Sie die Frage präzisieren? Verwenden Sie eine Mitgliedsvariable anstelle einer Accessor-Funktion?
0 Stimmen
Wie auch immer. Sagen wir, eine Accessor-Funktion. Das gibt zusätzlich () Die Frage war über Ausführlichkeit, wie KLE und N. Fortescue schrieb. Aber wie gesagt, ich kann toString überschreiben (interessante Entscheidung), und vor allem kann ich sehen, dass die Verwendung von enum hier eine gute Praxis sein kann.
0 Stimmen
@EugeneP Für mich und viele andere,
toString()
soll ein Debug-String sein (gut bei der Fehlersuche, für technische Protokolle und dergleichen). Das Problem bei der Verwendung dieses Strings im normalen Betrieb der Anwendung besteht darin, dass er eines Tages von jemandem überschrieben wird, um mehr Informationen im Debug-Modus anzuzeigen, weil er denkt, dass dies keinen Einfluss auf das Verhalten der Anwendung hat.0 Stimmen
Hm. Interessant. Das Problem hier ist, dass diese Struktur (enum) verwendet werden, um Strings und nichts mehr zu halten. Im Allgemeinen kann ich also verstehen, dass ein Objekt sie nur zu Debug-Zwecken verwenden sollte, aber das ist hier nicht der Fall, meinen Sie nicht? Meiner Meinung nach ist unser Enum hier eine Art String-Objekt! Wenn wir also über ein String-Objekt sprechen, verwenden wir seine Methode toString nicht zu Debugging-Zwecken! Liege ich da richtig?
1 Stimmen
Java toString soll eine "knappe, aber informative Darstellung bieten, die für eine Person leicht zu lesen ist". Obwohl es von einigen für Debug-Code verwendet wird, ist dies ein Bruch des Vertrags und sollte nicht als korrekt angesehen werden. Die korrekte Verwendung ist die Erstellung einer druckbaren Version. Wenn Sie toString auf die richtige Art und Weise verwenden, brauchen Sie sich keine Sorgen zu machen, dass eines Tages jemand kommt und etwas falsch macht. Das kann immer passieren, und dann können Sie genauso gut gar nichts tun.
0 Stimmen
@Jasper Genau, die Beschreibung ist für eine Person zu lesen (wie in einem Protokoll), und kann auf einem präzisen Bildschirm angebracht sein oder nicht. Meiner Erfahrung nach wird ein Objekt oft in mehreren Bildschirmen verwendet, mit unterschiedlichen Darstellungen. Außerdem haben die meisten Objekte mehrere Felder, die in verschiedenen Feldern mit entsprechender Formatierung angezeigt werden, so dass die Erstellung eines toString() für die Anzeige für den Endbenutzer nicht sinnvoll ist. Daher glaube ich, dass die von Ihnen gegebene Beschreibung meiner Vorstellung von einem Debug-String entspricht (der in Debug- oder Protokolldateien angezeigt wird und die Anwendung nicht beschädigt). @EugeneP Enums könnten jedoch ein Sonderfall sein!
0 Stimmen
@KLE Ein Debug-String ist keine prägnante, informative Darstellung, da er Debug-Daten enthält. Die Verwendung in der von Ihnen vorgeschlagenen Weise ist im Vertrag nicht vorgesehen. Daher muss jeder, der ihn verwendet, nicht mit diesem Verhalten rechnen.