String oder Objekt, Vor- und Nachteile

[jadon]

Hallo,

ich habe eine Frage. Ich muss bestimmte Informationen speichern, nämlich eine Zahl (byte) und ein oder zwei Namen (Strings). Diese Information füge ich jeweils der Session eines Users gesammelt hinzu.

Nennen wir es die Information [X]. Davon kann jeder User mehrere enthalten (jeweils natürlich mit einem anderen Inhalt). Nun überlege ich, wie ich dies am Besten realisieren soll.

Soll ich dafür ein eigenes Objekt erstellen, welches zwei Strings und einen byte-Wert enthält und getter/setter. Dieses würde ich dann dem User in einer Liste bereitstellen ArrayList<Informationsobjekte>. Oder soll ich die Information jeweils in einen String packen, der dann so aussieht: "byte String1 String2" und diese in einer Liste ArrayList<String> dem User hinzufügen?

Nachteil bei String: wenn ich die Informationen brauche, muss ich konvertieren (String splitten, in byte umwandeln) ->umständlich, braucht Zeit
Nachteil bei Objekt: braucht vermutlich mehr Speicherplatz als String. Man braucht vermutlich auch länger zum Erzeugen!

Die Objekte/Strings werden übrigens öfters abgefragt als erzeugt, aber es kann tatsächlich sein, dass SEHR VIELE von diesen Objekten verwendet werden müssen.

Was ist eure Meinung hierzu, bzw wie würdet ihr das lösen?
Danke

 

[faetzminator]

Ein Objekt machen. Auf die Laufzeit muss man zu 99% nicht schauen. Sondern auf schönen, objektorientierten Code.

Nachteil bei Objekt: braucht vermutlich mehr Speicherplatz als String. Man braucht vermutlich auch länger zum Erzeugen!

Und wie viel Zeit benötigt jedes Mal [c]Integer.valueOf()[/c] ?

 

[jadon]

hab mich gerade vertan, brauche kein int oder Integer, sondern byte .. eigentlich habe ich einen Binär-Wert aus vier Stellen zb 0110, den ich zusammen mit den zwei Strings abspeichern will

wo sollte ich denn Integer.valueOf brauchen? versteh das gerade nicht

was meinst du denn zu dem Argument mit dem Speicherplatz? Ich meine, Objekte brauchen doch mehr Speicherplatz, oder? Und wenn man annimmt, dass VIELE user die Applikation nutzen, spielen Zeit und Speicherplatz doch auch eine Rolle, oder nicht?

 

[faetzminator]

wo sollte ich denn Integer.valueOf brauchen? versteh das gerade nicht

Dann halt ein byte oder was auch immer. Du musst das schlussendlich wieder konvertieren, wenn du den ursprünglichen Datentypen willst.

was meinst du denn zu dem Argument mit dem Speicherplatz? Ich meine, Objekte brauchen doch mehr Speicherplatz, oder? Und wenn man annimmt, dass VIELE user die Applikation nutzen, spielen Zeit und Speicherplatz doch auch eine Rolle, oder nicht?

Im einen Fall hast du 3 Referenzen, zwei Strings und ein byte. Im anderen Fall hast du 1 Referenz, und einen (grösseren) String. Ausrechnen kannst du es dir selber
Wenn deine Applikation wirklich Memoryprobleme haben wird, dann sollte man sich nicht um solche Details kümmern, zumindest nicht als erstes. Da kann man das Design überdenken, die Daten in einer DB halten etc.

 

[jadon]

Dann halt ein byte oder was auch immer. Du musst das schlussendlich wieder konvertieren, wenn du den ursprünglichen Datentypen willst.

ja, habe ich ja auch schon selber gedacht...

Nachteil bei String: wenn ich die Informationen brauche, muss ich konvertieren (String splitten, in byte umwandeln) ->umständlich, braucht Zeit

Im einen Fall hast du 3 Referenzen, zwei Strings und ein byte. Im anderen Fall hast du 1 Referenz, und einen (grösseren) String. Ausrechnen kannst du es dir selber
Wenn deine Applikation wirklich Memoryprobleme haben wird, dann sollte man sich nicht um solche Details kümmern, zumindest nicht als erstes. Da kann man das Design überdenken, die Daten in einer DB halten etc.

Ich würde nicht so blöd fragen, wenn ich es mir selber ausrechnen könnte... und ich denke, man sollte so oder so immer bestmöglich programmieren, also so, dass es übersichtlich UND effizient ist, deshalb mache ich mir gedanken darum. klar, man kann immer was besser machen, aber ich will es nun eben so machen, dass es wenigstens halbwegs vernünftig ist!

 

[faetzminator]

Übersichtlichkeit vor Geschwindigkeit. Und es würde IMHO nie jemand auf die Idee kommen, wegen der Geschwindigkeit Daten in einem String zusammenzufassen.
Eine Referenz hat IMHO 32b (bzw. auf einem 64b System natürlich 64b). Jeder [c]char[/c] hat 16b und jedes [c]byte[/c] 8b. Allerdings müsste innerhalb des Strings das Array auch noch referenziert werden? Naja wie auch immer, es tut sowieso nichts zur Sache...

 

[Gast2]

und ich denke, man sollte so oder so immer bestmöglich programmieren, also so, dass es übersichtlich UND effizient ist, deshalb mache ich mir gedanken darum. klar, man kann immer was besser machen, aber ich will es nun eben so machen, dass es wenigstens halbwegs vernünftig ist!

Es ist NIE eine gute Idee eine Datenstruktur in einen String plattzuklopfen. Alleine das rausparsen der einzelnen Elemente durch z.B. split ist wieder eine Sache die a) getested werden muss, b) unflexibel ist (was machst du wenn du mehr Datenbrauchst, sich die Datentypen ändern etc), c) Fehleranfällig ist

Dazu kommen dann die Typkonvertierungen von String zu byte oder was auch immer du als Datentyp der einzelnen Elemente brauchst.

Von dem Design her kommt wirklich nur ein eigenes Object zu definieren in Frage wenn du es sauber haben willst. Wenn du damit wirklich Performance Probleme bekommst (was ich nicht glaube), dann kannst du das nachher immer noch einfach wieder ändern.

Vernünftig und sauber -> eigenes Object
quick'n'dirty und unflexibel -> String

 

[maki]

Ich würde nicht so blöd fragen, wenn ich es mir selber ausrechnen könnte... und ich denke, man sollte so oder so immer bestmöglich programmieren, also so, dass es übersichtlich UND effizient ist, deshalb mache ich mir gedanken darum. klar, man kann immer was besser machen, aber ich will es nun eben so machen, dass es wenigstens halbwegs vernünftig ist!

Übersichtlichkeit geht vor Effizienz.
Voreilige Optimierung ist der häufigste Grund für schlechten Code.
Bei deinem Wissensstand solltest überhaupt gar nicht an Optimierung denken, sondern nur versuchen, das Problem zu lösen.

 

[Guardi]

Wenn ich eine Applikation will, die Millionen von Operationen in Echtzeit bestmöglich skaliert und ich darauf selbst großen Einfluss nehmen will, nehme ich persönlich nicht Java. Aber das Thema wurde zigfach im gesamten Netz und diversen Foren schon durchgekaut und ist für dich auch nicht relevant.

In erster Linie gehts um saubere OOP UND(!) um eine vernünftige Architektur. Selbst wenn deine Anwendung es augenscheinlich nicht braucht, sollte man austauschbar, wiederverwendbar, klar gekapselt etc. programmieren.

Überleg dir doch z.B. Mal wo die Fehleranfälligkeit größer ist.
Oder sowas wie Typsicherheit.

 

[jadon]

gut, alles klar, dann mache ich das so - ich wollte nur nochmal sicher gehen!
Vielen Dank für die Antworten, kam ja eigentlich bei allen das gleiche heraus!