Domino 9 und frühere Versionen > ND6: Entwicklung

DocumentCollection mit Dokumenten aus mehreren Datenbanken

<< < (4/5) > >>

koehlerbv:
Markus, schau Dir dazu auch die DesignerHelp an. Dort wird ja auch beschrieben, welche Klasse von welcher anderen abhängt. Finde dann eine Property oder eine Methode, die eine DocumentCollection zurückgibt, die nicht an eine bestimmte Datenbank gebunden ist.

A propos DesignerHelp - hier der erste Satz zur Class NotesDocumentCollection:

--- Code: ---Represents a collection of documents from a database, selected according to specific criteria.
--- Ende Code ---

Bernhard

MadMetzger:
Das habe ich ja. Da steht etwas von "Containment", was für mich übersetzt "enthalten" bedeutet. An anderer Stelle wird in der DesignerHelp bei Vererbung immer von inherit und subclass gesprochen. Also das kann so immer noch nicht nachvollziehen, dass diese Dinge in einer Vererbungsbeziehung stehen. Denn eine Vererbung bedeutet ja, dass Struktur und Verhalten einer Klasse weitergegeben werden. Wenn dies so wäre, müsste ein Database-Objekt ebenso beispielhaft die Methode SendConsoleCommand nutzen können. An der Sache mit den Dokumenten innerhalb einer Datenbank zweifele ich nicht, aber ich führe dies nicht auf Vererbung zurück. Die sagt dieses ja auch nicht aus.

koehlerbv:
Wenn Du eine Tochter zeugst, hat diese dann alles von Dir geerbt, Markus?

Schau Dir die Properties - offensichtlichstes Merkmal des "vererbten Materials" - der NotesDocumentCollection an. Du findest dort NotesDocumentCollection.Parent. Der Typ ist ...

Abgesehen davon - um auf Deinen anderen Einwurf zurückzukommen - müssen ja gerade Methoden nicht weitervererbt werden. Zumindest nicht direkt, den
NotesDocumentCollection.Parent.SendConsoleCommand funktioniert sehr wohl  ;)

Bernhard

MadMetzger:

--- Zitat von: koehlerbv am 17.11.06 - 22:15:52 ---Wenn Du eine Tochter zeugst, hat diese dann alles von Dir geerbt, Markus?

--- Ende Zitat ---
Tja, im realen Leben ist Mehrfachvererbung machbar... in der Programmierung geht das ja nicht...  ;)

--- Zitat von: koehlerbv am 17.11.06 - 22:15:52 ---Schau Dir die Properties - offensichtlichstes Merkmal des "vererbten Materials" - der NotesDocumentCollection an. Du findest dort NotesDocumentCollection.Parent. Der Typ ist ...

Abgesehen davon - um auf Deinen anderen Einwurf zurückzukommen - müssen ja gerade Methoden nicht weitervererbt werden. Zumindest nicht direkt, den
NotesDocumentCollection.Parent.SendConsoleCommand funktioniert sehr wohl  ;)

--- Ende Zitat ---

Der Hinweis mit den Properties spielt eigentlich genau mir in die Arme, da der parent-Aufruf meiner Meinung nach keine Vererbung ist. Hier wird Delegation verwendet um trotzdem bestimmte Methoden/Properties nutzbar zu machen. Deshalb konntest du mich immer noch nicht überzeugen, dass du recht hast. Bei Vererbung ist es immer so, dass immer alle Methoden von "oben nach unten" weitervererbt werden, also müsste mein Beispiel ohne den Parentaufruf nutzbar sein. Wonach sollte also entschieden werden, welche Methode weitervererbt wird und welche nicht. Ich kenne kein sprachliches Kennzeichen, welches das innerhalb von LS oder auch Java macht.

Das einzige, was man sagen könnte, wäre, dass an dieser Stelle Vererbung durch Delegation an das parent-Objekt simuliert wird.

Markus

koehlerbv:
Okay, Markus: Jetzt sind wir bei Begrifflichkeiten - Vererbung oder Delegation. NotesDocumentCollection hat Parent geerbt (das ist sicherlich unstrittig), darüber wird dann delegiert.

Aber in der eigentlichen Frage sind wir kein Stück weiter: NotesDocumentCollection ist immer an NotesDatabase gebunden (wie auch immer), nie aber direkt an NotesSession. Findest Du eine Beziehung, an der NotesDocumentCollection direkt mit NotesSession verbandelt ist, hast Du einen Weg gefunden. Stolperst Du auch immer über NotesDatabase: No way für die Aufnahme von NotesDocuments aus mehreren NotesDatabases.

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete