(Java) Welcher Datentyp für ne IBAN?

6 Antworten

Ich würde einen eigenen Datentyp für die IBAN erstellen und dort die Länderkennung extra kodieren.

Wenn das nicht möglich sien sollte, dann sollte ein String verwendet werden, sonst wird das am Ende unverständlich.

Wäre es z.B. sinnvoll, die Länderkennung als Zeichenkette und die restliche Ziffernfolge als ganze Zahl zu speichern?

Definitiv nicht.

Da vermutlich nicht nur IBAN deutscher Banken gespeichert werden können sollen, ist gar nicht gewährleistet, dass nach der Länderkennung nur noch Ziffern kommen, sondern es sind bei IBAN verschiedener Länder auch in diesem Teil Buchstaben möglich.

Du kannst die IBAN schon deswegen nicht als ganze Zahl speichern, weil die Zahlenfolge potenziell führende Nullen beinhalten kann. Zahlen können aber keine führenden Nullen haben. Das einzig sinnvolle ist, die IBAN als String zu speichern. Zumal Du später ja ohnehin die komplette Zeichenkette brauchst - würdest Du es getrennt speichern, müsstest Du jedes Mal konvertieren, mit Nullen auffüllen und zusammensetzen. Viel zu umständlich.

Kontostände sind Dezimalzahlen. Such Dir einen Datentyp aus.

POpmapus 
Fragesteller
 17.10.2023, 15:47

Dankeschön!

Würde das auch so gehen:

class Bankkonto {

    String name;

    String vorname;

    String iban; 

    int kontostand;  // in cent 

    double limit;    

}

0
ohwehohach  17.10.2023, 15:47
@POpmapus

Kannst Du so machen, aber wenn Du den Kontostand als int in Cent angibst, warum dann nicht auch das Limit?

1
POpmapus 
Fragesteller
 17.10.2023, 15:49
@ohwehohach

ich hatte es auch vorher so wegen der einheitlichkeit. ich mach es wieder rückgängig danke!

0

Was spricht denn gegen einen String für die ganze IBAN? Man kann doch sowieso nicht sinnvoll mit den IBANs rechnen, z.B. zwei IBANs addieren.

POpmapus 
Fragesteller
 17.10.2023, 15:44

Na ja die Aufgabenstellung hat es so gemeint dass string gar nicht sinnvoll wäre.. oder vielleicht habe ich das einfach missverstanden.

1
ohwehohach  17.10.2023, 15:44
@POpmapus

Nein, das sagt die Aufgabenstellung nicht. Im Gegenteil fragt sie, ob die Auftrennung sinnvoll wäre. Gegenargumente zur Auftrennung sind in meiner Antwort zu finden.

1
tunik123  17.10.2023, 15:48
@POpmapus

Beachtenswert ist auch das Argument von ohwehohach, das gegen eine Speicherung des numerischen Teils als ganze Zahl spricht.

Da die Anzahl der Ziffern einer IBAN bekannt ist, könnte man zwar theortisch die führenden Nullen rekonstruieren. Aber das will man sich wirklich nicht antun.

2
POpmapus 
Fragesteller
 17.10.2023, 15:48
@ohwehohach

Dankeschön. Hab es dummerweise missinterpretiert

0

Für die IBAN würde ich String nehmen und für den Kontostand Float.

POpmapus 
Fragesteller
 17.10.2023, 15:46

Für den Kontostand meinte die nette Dozentin es wäre keine gute Idee float/double zu verwenden da beim compilen die Zahlenfolge aufgerundet wird, so würde also zB. bei 2300.33€ 33ct verloren gehen weil es auf 2300€ aufgerundet wird.

class Bankkonto {

    String name;

    String vorname;

    String iban; 

    int kontostand;  // in cent 

    double limit;    

}

0
ohwehohach  17.10.2023, 15:48
@POpmapus

Das mit dem Runden ist Quatsch. Erstens hat das nichts mit dem Kompilieren zu tun und zweitens ist der Sinn von float/double, etc. ja gerade, dass man mit Nachkommastellen arbeiten kann.

Manche Zahlen können aber nicht präzise durch float/double dargestellt werden - vielleicht meint sie das?

Die Speicherung in Cent simuliert halt Zahlen mit fester Anzahl Nachkommastellen. Sprich, um das später irgendwo anzuzeigen, musst Du entweder eine Float-Division durch 100.0 machen (und das dann dasselbe Problem wie wenn Du es direkt gespeichert hättest) oder Du musst eine Funktion machen, die in den String an festen Positionen dann eben das Dezimalkomma einfügt.

1
Destranix  17.10.2023, 16:41
@POpmapus

Dein Dozent hat recht, der Nutzer redet wirr.

Man speichert Kontostände als Integers eben wegen der Ungenauigkeiten von Fließkommazahlen. (Bzw. iirc speichern manche Naken ihre Zahlen sogar als Strings glaube ich. Sehr schräg.)

0