LotusScript - abgeleitete Klassen

[Hive]

Mhh ich sitze gerade mal wieder an einem kleinen Projekt und will der eigenen Weiterbildung wegen ein wenig mit Klassen auseinandersetzen.

Vorweg sei gesagt das ich mich mit dem Konzept der Objekt Orientierung, Vererbung und Implementierung noch recht gut auskenne aus Studienzeiten (damals per Java)

Also hier ein paar Fragen:
1. Was genau sind Produkt Klasssen (product class) von denen man nicht ableiten kann. Gehört z.B. NotesDocument und NotesDocumentCollection dazu?? Weshalb kann man von diesen nicht ableiten??

2. Bei Java konnte man sehr angenehm Objekte von Vektoren bilden geht das bei LS auch irgendwie, ich würde gerne eine Collection von Objecten (wie z.B.) die NotesDocumentCollection haben wollen.

Danke schon mal
KAI

[azique]

Hallo
ja, unter Produktklassen verstehe ich das gleiche wie du.
Warum man davon nicht ableiten kann? Das ist die Frage, auf die ich auch gerne eine Antwort hätte >.< Ich nehme mal an, damit keine Probleme auftauchen, wenn IBM was an diesen Produktklassen ändert. Ähnlich ist das ja bei den Swing-Klassen (öhm, hab ich vor kurzen wo gelesen ^^ aber ohne Gewähr)

Wir haben auch ein klassenbasiertes Framework ertüftelt, bei dem zum Beispiel Listen unserer eigenen Objekte verwendet werden - dabei haben wir uns hauptsächlich an die Java-Klassen gehalten, damit es für uns nicht so verwirrend ist, wenn wir mal hier mal dort arbeiten. Wie genau wir das gemacht haben, kann ich zwar nicht verraten (weil ich es nicht genau weiß), aber prinzipiell geht das wohl

[JulianBuss]

Produktklassen - genau wie von azique beschrieben. Eine Ableitung davon ist nicht möglich, ich denke vor allem, weil diese Klassen intern auf C++-Klassen gemappt sind.

Eine eigene NotesDocumentCollection Klasse habe ich mittels Arrays implementiert. Die simple Methode ist es, intern ein Array von NotesDocuments zu führen.
Das ist aber mit Vorsicht zu genießen wenn Du viele Dokumente verwalten willst.

Sicherer, aber auch abstrengender, ist es, das interne Array nur mit Note-IDs zu füllen und bei einem Zugriff auf ein konkretes Dokument dieses dann per NotesDatabase.getDocumentByID zu holen.

Ein Konzept wie die Vector Klasse von Java gibt es unter LS nicht direkt; das musst Du selbst implementieren oder ergoogeln.

Hilfreich in vielen Fällen sind jedoch die LS-Listen, das ist ein bisschen so ähnlich wie ein Array, man muß es aber nicht ständig neu dimensionieren und der Zugriff erfolgt via stringbasierten Keys.

[flaite]

In Java können auch bestimmte Klassen nicht erweitert werden. Z.B. ist java.lang.String final.
Ausserdem gilt eine Über-Benutzung von Vererbung als schlechter OO-Stil. (favour composition over inheritance). Es bricht separation of concern. Eine Klasse wie NotesDocument erfüllt seinen Zweck.
Praktisch jedes selbstrespektierende OO-Buch warnt vor einer Überbenutzung von Vererbung (z.B. Gang of Four, Domain Driven Design)
Man sollte da nicht eigenes per Vererbung dranwerkeln, sondern eher in einer eigenen Klasse NotesDocument benutzen:

Code

class MyClass {

NotesDocument doc;

public MyClass (NotesDocument doc) {
 this.doc = doc; 
}

public void myStuffWithDoc() {
 ... do stuff with doc ...
}

Das ist in 99.5% der Fälle besser.

Domingo (http://domingo.sourceforge.net/) geht sehr weit in der Erzeugung eigener Notes Produkt-Klassen (per Composition). Im dortigen Source Code kannst du dir anschauen wie das geht. Die machen das zum großen Teil, um recycle() im Anwender code unnötig zu machen. Ist aber sehr viel Arbeit, weil du irgendwann dabei endest, sämtliche Methoden der originalen Notes-Produktklassen selbst zu implementieren.

In J2EE aka EE5 und JUnit4 wurden übrigens ganz viele Vererbungsbeziehungen weggemacht, wobei das zugegeben nur wegen Java Annotations möglich war, so dass dieses Argument polemisch ist, weil Annotations auch eine Art von kontextabhängiger Vererbung bewirkt. 

Ich hab in meinen Leben noch keine Klasse des Java Collection Frameworks (sowas wie java.util.List, java.util.HashSet oder java.util.Vector überschrieben. Wozu auch?
Auch in modernen Java-Frameworks wie Spring und Hibernate überschreibst du meist nur abstrakte Klassen, die extra dafür vorgesehen sind, dass sie überschrieben werden. Ich würd in meinem Leben nicht die Spring-Produktklasse ApplicationContext überschreiben. Anfänger könnten das für eine gute Idee halten. Es ist in 99.9% der Fälle eine schlechte Idee.
In eigenen kleinen Frameworks, die ich schreiben mußte, gab ich den Benutzern auch immer nur bestimmte Methoden zum überschreiben. Total viel Methoden mach ich final, Klassen sowieso (bessere Kapselung).

 

[Axel]

Zur Vererbung von vorhandenen Notes-Klassen gabs in ganz grauer Vorzeit mal einen Artikel im Notes-Magazin (5/2000) dazu. Den hab' ich mir damals mal rauskopiert.

Ich hänge ihn mal als PDF an. Leider sind die Grafiken mit den Quelltexten nicht besonders. Aber ich denke man kommt damit zurecht.

[Hive]

Danke für die Antworten wollte ich unbedingt noch sagen. Hat sehr geholfen ..

MfG Kai