Buchungsklasse bei Splitbuchung übernehmen #535
Conversation
| @@ -160,7 +156,14 @@ public void setStatus(int status) throws RemoteException | |||
| @Override | |||
| public Buchungsklasse getBuchungsklasse() throws RemoteException | |||
| { | |||
| return (Buchungsklasse) getAttribute("buchungsklasse"); | |||
| Long l = (Long) super.getAttribute("buchungsklasse"); | |||
There was a problem hiding this comment.
Ich fände es super, wenn wir anfangen würden, Konstanten für die Strings zu verwenden.
There was a problem hiding this comment.
Könnt ihr mir erklären was das in dieser Art von File für einen Vorteil bringen soll. Das ist doch hier einfach nur doppelte Arbeit und doppelt fehleranfällig.
Ich sehe da nicht wirklich einen Vorteil.
There was a problem hiding this comment.
Was meinst du mit "doppelte Arbeit" und "doppelt fehleranfällig"?
Die Konstante deklarieren und dann zweimal verwenden? Einmal hier und einmal in der Zeile, die mit 003d6be eingefügt wurde? Außerdem werden Feldnamen ja auch noch in anderen Java-Dateien (z. B. db updates) verwendet.
Konstanten haben den Vorteil, dass der Compiler deren Verwendung checkt. Wenn man einen Tippfehler macht, meckert er sofort. Das kann er bei Strings nicht erkennen. Außerdem lassen sich Strings nicht refactoren im Sinne von umbenennen, Konstanten schon. Falls man doch mal die Deklaration, also den String ändern will/muss, macht man das genau an einer Stelle. Das ist dann weniger fehleranfällig, als mehrere Strings zu ändern und ggf. einen zu übersehen, auch wenn es insgesamt ganz wenige Strings sind.
Zu guter Letzt kann man noch die Verwendung von Konstanten ganz einfach feststellen: Rechtsklick -> References. Das geht auch nicht mit Strings.
Das Refactoring von Strings funktioniert insofern ganz gut, als das man Rechtsklick -> Refactor -> Extract Constant... wählen kann.
In meinen Projekten verwende ich durchgehend Konstanten statt Strings, mit Ausnahme von englischen Fehlermeldungen, die exalt so ins log geschrieben werden sollen. Das reduziere ich jedoch auch weitestgehend, da sie nicht lokalisierbar/übersetzbar sind.
Bitte verstehe mich nicht falsch. Es ist nur ein Vorschlag, der meiner Ansicht nach die Code Qualität und das spätere Arbeiten verbessert.
There was a problem hiding this comment.
Ok, habe es verstanden. Das macht wohl dann Sinn.
Dann reicht es aber nicht nur die zwei Zeilen zu ändern. Dann muss ich auch alle Stellen finden wo der String verwendet wird damit das mit dem umbenennen usw. auch wirklich funktioniert.
There was a problem hiding this comment.
Refactor -> Extract Constant...
Ist dein Freund. 😄 Es wäre schon mal ein Anfang, wenn man es in der einen Datei macht. Dann kann man projektweit suchen, wo es ggf. noch als String verwendet wird.
Implementiert #529