Designfrage: Viele, kleine Objekte

[tincup]

Hi.

Ich entwickle grade an einer Bibliothek (soll also auch mal von anderen Programmierern genutzt werden), welche unter anderem eine Container-Klasse mit Zahlenpaaren enthält. Diese Zahlenpaare können in großer Zahl auftreten (50-100.000) und stellen an sich auch diskrete Objekte dar (sagen wir mal "Datensätze"), welche über die Containerklasse auch z.B. einzeln ausgelesen werden können.

Jetzt ist die Frage, was für einen Datentyp sollte man verwenden. Irgendwie scheint es mir "zuviel", wenn ich dafür extra wieder eine eigene Klasse erstelle, wo dann zwei Zahlen drinstehen. Einfacher wäre vielleicht ein int[] der Größe 2. Ist sicher hässlich, aber effizienter. Oder auch nicht, weil Arrays in Java auch Objekte sind?

Hat jemand da vielleicht eine Meinung oder generell ein paar Gedanken zu?

Grüsse,
Tin

 

[Backwardsman]

wie groß bzw. klein kann so eine einzelne zahl denn werden!? wird der ganze int-bereich ausgenutzt? wenn nicht, könnte man bestimmt was optimieren... aber so wie es sich anhört würde ich zu einem int-array tendieren, ein extra objekt für ein zahlenpaar wäre wohl etwas too much ;-)

 

[tincup]

Danke schonmal für die Antwort.

OK am konkreten nativen Datentyp könnte man sicher optimieren. Aber generell scheint das mit dem int[] ziemlich hässlich, irgendsone Methode
int[] getRecord(...)

Die dann was zurückgibt mit der Konvention, arr[0] ist der erste und arr[1] der zweite Wert. Nicht so ganz Java-like, und doch insbesondere schlecht, wenn man den Code nicht nur für interne Zwecke benutzt, oder?

 

[Wildcard]

Abhängig von deinen Daten ist vielleicht das Fliegengewicht Design Pattern etwas für dich?

 

[Backwardsman]

naja, was heißt denn "hässlich"!? welche anderen möglichkeiten hast du denn (welche nicht auf objekten abgesehen von arrays basiert)? ein int-array wird da immer noch das "maschinennaheste" sein.

und wer will denn gleich die ganze liste haben? das packt man schön in ein objekt, von welchem man sich dann einzelne einträge geben lassen kann, bzw. funktionalitäten wie sortieren, vergleichen etc. anbietet.

kannst natürlich auch schon einen baum oder ähnliches implementieren, dann ist es vielleicht "schön", aber halt eben overkill.

insgesamt müsste man einfach mehr wissen worum es geht, was das für daten sind, was damit gemacht werden kann und soll... sonst kann man solche entscheidungen gar nicht treffen!

 

[tincup]

Ich muss leider gestehen, dass ich mich mit Designpatterns nicht sehr gut auskenne. Ich mache sowas meist so aus dem Gefühl heraus (Asche auf mein Haupt).

Nach einigem Nachdenken (der erste Post ist zwar nicht lange her, aber seither hab ich mir alles mögliche überlegt ) denke ich, dass ich folgenden Ansatz benutzen werde:

Ich speichere die Paare intern als großes, eindimensionales int[] Array, dieses sollte die größtmögliche Performance haben. Ein paar ist dann entsprechend an den indizies i und i+1 für ganze Zahlen i. Falls der Benutzer sich einzelne Interaktionen rausholt (das passiert wahrscheinlich nicht so häufig) extrahiere ich den Kram und packe ihn wohl doch in einen entsprechenden Container ODER gebe ihn als ähnlich aufgebautes Array zurück.

Hab mal kurz nach diesem Fliegengewicht Pattern geschaut, auf die schnelle habe ich gefunden:

Nutze Objekte kleinster Granularität gemeinsam, um grosse Mengen von ihnen effizient verwenden zu können.

Ich denke mal, mein Ansatz geht etwa in diese Richtung.

Danke nochma. Grüsse,
Tin

 

[Wildcard]

Ich muss leider gestehen, dass ich mich mit Designpatterns nicht sehr gut auskenne. Ich mache sowas meist so aus dem Gefühl heraus (Asche auf mein Haupt).

Das solltest du ändern.
Wenn ein halbwegs erfahrener Entwickler sein erstes Buch über Patterns liest, wird er feststellen das er vieles davon schon intuitiv getan hat. Ebenfalls wird er feststellen, dass das echte Pattern meist noch eine Spur besser/flexibler als seine Lösung ist.
Davon abgesehen hat es Vorteile dem Kind einen Namen geben zu können, das erhöht das Verständnis im Team.

 

[tincup]

Full Ack!

Gibt es da ein Buch, welches du empfehlen könntest?

 

[Wildcard]

Ich bin großer Fan des Originals:
http://www.amazon.de/Patterns-Elements-Reusable-Object-Oriented-Software/dp/0201633612

 

[kaesebrot]

zum lernen auch sehr angenehm:

http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124

 

[Marco13]

Irgendwie sehe ich kaum einen Grund, dafür KEINE eigene Klasse zu erstellen (Zumal ein Array auch ein echtes Objekt ist). Eine Klasse "Tuple2i" vielleicht, die dann auch schicke equals- hashCode und toString-Methoden anbieten könnte...!? Wenn es brutalst um Performance gehen würde, würde man nicht viele 2-arrays nehmen, sondern einen großen Array, und mit passenden indizes drauf zugreifen ....

 

[Backwardsman]

Wenn es brutalst um Performance gehen würde, würde man nicht viele 2-arrays nehmen, sondern einen großen Array, und mit passenden indizes drauf zugreifen ....

also mich würde es schon sehr wundern, wenn das was bringen würde... intern wird ein 2 dimensionlaer int-array doch nicht anders im speicher abgelegt als ein 1 großer dimensionaler nur dass halt die jmv die adressierung übernimmt...

 

[tincup]

Bei vielen kleinen 2-Arrays hat man halt das Problem des Objekterstellungs-Overhead, würde ich sagen.

Danke schonmal für die Buchtipps, eins von den beiden werde ich mir wohl bezeiten mal zulegen müssen.

 

[Marco13]

Nun - wie der Speicher eines 2D-int-arrays aussieht, weiß fast niemand.... Zumindest kann man mit ziemlicher Sicherheit davon ausgehen, dass ein 1D-Array in einem einzelnen Block liegt, aber man kann sicher NICHT davon ausgehen, dass ein 2D-Array in einem "1D"-Block liegt, der nur anders adressiert wird. Spätestens bei

int a[][] = new int[]{ {1,2}, {3,4}, {5,6} };
int b[][] = new int[]{ a[2], a[0], a[1] };

kann ja zwangsläufig einer von beiden NICHT als zusammenhängender Speicherblock vorliegen :wink: