nicht angemeldet
Hi
in erster Linie ist das jedoch dazu
da, verschiedene Arten von Objekten die zusammenhängen können zu Speichern,
Einspruch: Nach meinem Verständnis ist es ein Weg, die Realität (="zusammenhängende
Objekte") _abzubilden_ bzw. zu modellieren.
Für mich ist es intuitiver, die Daten dieses Forums durch ein Object mit dem Namen
"MessageTree" zu modellieren, welches dann genau über die Methoden verfügt, die ich
ewarte: getRoot(), getParent(), getChild() etc..
Also ist der Thread für dich das Grouping Objekt, dann hätten wir die Hauptdatei
und als ein Grouping von Threads und Threads als ein Grouping von Postings das
sowohl ein Knoten als auch ein Grouping darstellt. Zusätzlich hast du aber noch
mehr Bedingungen die bei einem Composite Pattern nicht gegeben sind. Eine Hauptdatei
kann nur Threads beinhalten, jedoch keine Postings direkt. Genauso kann ein
Thread keine Hauptdateien beinhalten und ein Posting nur weitere Postings. Die
Struktur ist also nicht frei, sondern eindeutig hierarchisch in der wirklichen
Welt. Diese Einschränkungen können nicht so einfach mit dem Composite Pattern
abgebildet werden, resp, das fehlen dieser Beschränkungen führt bei sauberem
Design beinahe zwangsläufig zu diesem Pattern.
Zumindest in Java werden für die Speicherung aus Performancegründen komplexe Objekte
oftmals sogar "aufgebrochen", d.h. in ihre Teilobjekte zerlegt, und oft sogar nur deren
primitiven Attribute/Datentypen persistent gemacht - in relationalen DBs.
Java ist für mich keine saubere objektorientierte Sprache eben genau da sie
einen Unterschied macht zwischen Objekten und primitiven Typen.
Ganz genau diese Persistent ist das Problem, hier kommen Performanceprobleme
hinzu die nicht zu vernachlässigen sind bei einem Forum wie diesem, du
siehst ja selber wie gross diese Probleme bei diesem hier im Moment zumindest
teilweise sind. Das teuerste bei der Datenspeicherung ist nunmal der Zugriff
auf den Datenträger, deswegen sollte das so selten wie nur möglich geschehen.
Hätten wir nur Objekte ohne persistente Speicherung hätten wir damit keinerlei
Problem.
Wieso? Habe ich doch im vorigen Posting beschrieben.
Siehe oben Beschreibung der Datenstruktur mit den Einschränkungen was welche
Elemente beinhalten darf.
da reicht auch ein einfacheres Konstrukt.
Was meinst Du mit "einfacheres Konstrukt"? Ich finde es einfach - weil naheliegend -, ein rekursives Problem rekursiv zu lösen.
Ich sage nicht, das ein einfacheres Konstrukt nicht rekursiv arbeiten würde, es
hätte nur die Freiheit mit alles darf alles beinhalten nicht.
Trotzdem krieg ich das ganze nicht zusammen, ohne im entsprechenden Programm mit
Rekursion zu arbeiten, und das macht mir das ganze zu langsam.
Ich meine nicht, das dieser Schluß der wichtigste einer Performanzanalyse ist. Da würde
ich dann eher auf die Frage "XML ja oder nein?" kommen.
Das Performanceproblem bei Rekursion ist nur der reine Datenzugriff, viele
einzelne Files zu öffnen oder viele einzelne Male auf eine Datenbank zuzugreifen
ist viel aufwändiger als ein einzelner Zugriff auf eine grössere Datei. Der Zusatzaufwand
durch die Rekursion selber ist vernachlässigbar gering (Anlegen des Stacks,
Aufruf einer Funktion/Methode).
Ich kann mir keine
möglichkeit Vorstellen, Threads objektorientiert zu Speichern als ein
Haufen Postingobjekte die ihre Kinder kennen.
Die Frage bleibt, ob _das_ das lohnende Ziel für Performanzsteigerungen ist. Vielleicht
wissen da andere mehr.
Das Problem, abgesehen vom langsamen XML-Parser, ist meiner Meinung nach hauptsächlich das Öffnen vieler einzelner Dateien sowie die Locks darauf.
Zudem ist Rekursion ein Grundprinzip objektorientierter Programmierung.
Hmm, ich bin kein Informatiker, vielleicht liegt es ja daran. Aber: "Rekursion" habe ich »» noch nicht im Zusammenhang mit _Grundprinzipien_ objektorientierter Programmierung gelesen »» bz. gehört. Hast Du einen Link?
Link nicht, entsprechende Bücher lagere ich auch alle im Büro, ich kann mich da
nur an meine ersten Kurse in Objektorientiertem Softwaredesign erinnern.
Gruss Daniela