Ho,
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.
Hmm. Soweit ich verstehe, wird das Composite-Pattern dazu verwendet, Teile-Ganzes-Hierarchien abzubilden und die Elemente uniform zu behandeln.
Letzteres natürlich nur da, wo es Sinn macht. Bei Implementierungen der konkreten Klassen müssen diese Besonderheiten/Einschränkungen berücksichtigt werden. Das heißt z.B., Root, Thread und Posting könnten weitere Konkretisierungen von Knoten sein. Ein Root hat keinen Parent und hat auch nur Kinder vom Typ Thread.
Das ist für mich eine Variation bzw. Implementierung des Kompositionsmusters.
Java ist für mich keine saubere objektorientierte Sprache eben genau da sie
einen Unterschied macht zwischen Objekten und primitiven Typen.
Hätte man dieses Design doch nur auch von Smalltalk übernommen...
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.
?? Aber das ist doch kein Problem der OO, sondern ist unabhängig vom Programmierparadima, oder? Nichts spricht gegen Caching, selbst OO nicht.
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 weiß nicht, wie das hier im Forum gelöst ist. Eine OO-Realisierung heißt aber nicht, dass ich Perfromanzfragen nicht Rücksicht nehmen müsste ;-)) Was spräche dagegen, die in XML persistent gemachten Daten im RAM zu cachen und nur auf diese Daten bei der Baumgeneration zuzugreifen?
Das Problem, abgesehen vom langsamen XML-Parser, ist meiner Meinung nach hauptsächlich das Öffnen vieler einzelner Dateien sowie die Locks darauf.
Davon habe ich nun gar keine Ahnung.
Viele Grüße,
Martin