Best Practices > Diskussionen zu Best Practices

Has-A vs. Is-A

(1/2) > >>

Gandhi:
Bin gerade dabei die Datenstruktur für ein Neues Webprojekt mit Domino zu erstellen.
Habe vor dies auch zu Lernzwecken mit 8.5 zu erstellen und ggf. XPages zu nutzen.

Dabei stellt sich mir die Frage, ob es hier sinnvoll ist, die Daten zu "relationalisieren".

Beispiel:
Ich möchte gerne für alle Dokumente einen Historie :-:nabschnitt haben.
Das kann ich über eine Teilmaske lösen.
Aus irgendwelchen Gründen kam mir jedoch dann ein Pattern Buch in den Kopf, in dem es hieß, dass es immer besser sei etwas zu besitzen, als etwas zu erben.
Man könnte auch sagen, dass es besser ist die Datenstruktur zu normalisieren, weil ich derzeit nicht plane die Masken mit eigenständigen Funktionen zu versehen.
Im Konkreten Fall würde dann ein Historiendokument auf ein Dokument verweisen.

Im Notes hatte das bislang immer auch ziemlich gravierende Nachteile.
Nun bin ich mir aber gerade mal nicht so sicher, ob man das noch und auch für Webapplications sagen kann/muss und mein Halbwissen zu XPages (damit habe ich noch rein gar nichts gemacht) macht die Entscheidung nicht einfacher.

Ich stelle daher die Benutzung von Teilmasken in diesem Umfeld (WebApp, Xpages) zur Diskussion:

Ist es in diesem Zusammenhang noch optimal Teilmasken zu verwenden oder sollte man eigenständige Dokumente zu einem Hauptdokument assoziieren?

Aus meiner bisherigen Erfahrung spricht gegen eine solche Assoziierung:
- Viele Dokumente - lahme DB (in dem Fall eher nicht problematisch)
- Links können verloren gehen, wenn sie auf die aktuelle UNID verweisen (leicht zu umgehen, indem man die UNID bei Erstellung nutzt)
- Gleichzeitiges Editieren mehrerer Dokumente kaum möglich (das sollte sich aber mit XPages erledigt haben, wenn ich das richtig verstehe?), sollte auch bei Einsatz von Dojo und Nutzung von Domino ausschließlich als XML Quelle und Senke möglich sein.

Dafür sprechen würde
- Die Komplexität der einzelnen Masken wird reduziert.
- Ich kann auch auf diese Weise in mehreren Ebenen strukturieren (in der Art Teilmaske in Teilmaske)
- Der Code ist besser getrennt - doppelte Feldnamen sind zum Beispiel möglich (z.B. ID)
- Unterschiedliche Bereiche können von verschiedenen Personen gleichzeitig editiert werden, da es sich dann um faktisch separate Dokumente handelt, die nur als ein Dokument angezeigt werden (ist für das Historiendokument nicht sooo wichtig - in einer weiteren Ebene könnte man dann aber noch die durchgeführten Transaktionen {Feldname;Altwert;Neuwert} auf diese Weise Abstrahieren.


Fazit: Meine Erfahrung sagt mir: Mach das nicht.
Mein Gefühl sagt mir: Das ist viel besser.

Wie denkt Ihr darüber?


Variante 1: Dokument hat Teilmaske Historie
Variante 2: Historiendokument verweist auf Dokument

WernerMo:
Hallo

mit XPages sollte das egal sein ob V1 oder V2.
Grundsätzlich würde ich Dir aber die Version 8.5.1 empfehlen, wenn Du mit XP beginnst.

Gruß Werner

ata:
In meinen Datenbanken verwende ich in der Regel die Version 1 - Daten der Historie werden im Dokument gespeichert und nicht extern. Damit kann die Historie nicht verloren gehen, bzw. ist alles vor Ort und muß bei Auswertungen nicht zusammengetragen werden. Nur im Spezialfall würde ich Version 2 wählen.

Toni

flaite:
Hm. Ich verstehe is-a und has-a völlig anders.
is-a bezieht sich rein auf Vererbungsbeziehungen. Die sollten nicht zu ausufernd sein. Du wirst auch bei komplexen Frameworks selten mehr als 2 Vererbungsebenen unterhalb einer abstrakten Klasse sehen.
Es ist allerdings schon richtig, das man in OO mehr dazu neigt, die Datenstrukturen im Hinblick auf die Menge der Attribute zu verkleinern. Das hat gute Chancen die Übersichtlichkeit zu erhöhen.
In Java würd ich history immer in einer eigenen Klasse definieren und diese Klasse dann irgendwo als Attribut in eine eigene Klasse hängen. Das ist has-a. BUT: Wenn ich die history als zusätliche Attribute in andere Objekte schreiben würde, ohne dass sie durch eine eigene Klasse "zusammengehalten" würden, dann ist das NICHT is-a.

In OO kann man Daten problemlos in so viele Teile zerstückeln wie einem das sinnvoll erscheint. Es existieren keine merklichen physischen Kosten. Objekte leben im Arbeitsspeicher.
Eine Operation

--- Code: ---
myObj.getHistory().getSubject();

--- Ende Code ---
heißt in Java nichts anderes als:
Suche die Speicheradresse, die in dem Property history von myObj gespeichert ist.
Suche dort die Speicheradresse des property subject und gebe dieses zurück (es ist ein Objekt vom Typ java.lang.String)
Im Arbeitsspeicher läuft das alles rasend schnell.
Es beansprucht vom Rechner nicht viel mehr Arbeit als:

--- Code: ---myObj.getHistorySubject();

--- Ende Code ---
Hier spart man die Suche der Speicheradresse des Objekts des Typs History. Diese Operation ist aber nicht kostspielig.
Das sieht anders aus, wenn man sich wie in Notes die Daten erstmal von Platte holt. Da bedeutet die Suche und das Lesen von history (also der Zwischenschritt) deutlich kostspieligere IO Operationen.

Heute abend folgt noch eine Anekdote, warum das in RDBMS Sinn machen könnte, die History in einer eigenen Tabelle abzuspeichern. RDBMS ist aber nicht OO.

Design Pattern Bücher enthalten keine Regeln, wie man zu programmieren hat. Patterns sind solutions in a context. Dies drückt bereits aus, dass die Anwendung eines Patterns oder einer Design-Best-Practice wie has-a oft besser als is-a immer eben auch kontextabhängig ist.

Aber wie gesagt: Mit is-a hat das ganze null zu tun.

Gandhi:
Ja, der Titel ist 'misleading'
Aber diese Patterngeschichte (auch wenn es nicht is-a ist) hat mich auf den Gedanken gebracht, der tatsächlich eher auf Normalisierung als auf Vererbung (was ich damit meine ist die Teilmaske, die sehr Abstrakt und aus meiner Sicht eine Art Vererbung ist, da die Maske von der Teilmaske Attribute und Methoden 'erbt' - wenn auch andere OO Features natürlich nicht umgesetzt werden können) abzielt.
Insofern ist der Titel nicht so gut gewählt.

Dennoch bleibt für mich die Frage, wie das optimal zu lösen ist. Sind Teilmasken nocht Mittel der Wahl oder verknüpfe ich besser Dokumente miteinander. Also: Erstelle ich da eine Relation (Ja, Notes ist keien Relationale DB - aber das heißt ja nicht, dass man keine Relation erstellen kann). Und wenn ja: Was spricht dafür und was dagegen.

Navigation

[0] Themen-Index

[#] Nächste Seite