Wie kann ich eine Klasse sinnvoll aufbauen ?

[TMC]

Ich bin bezügl. Klassen ein Anfänger, da ich noch nie wirklich größere Klassen erstellt habe.

Wie baut Ihr sinnvoll Klassen auf?

Ich nehme als Beispiel eine History-Scriptlibrary, bisher hab ich alles als Subs & Functions in der Lib.

Was passiert:
A) User öffnet ein Dokument
+ Im Postopen werden zu überwachende Feldnamen und Feldinhalte jew. ein eine globale Variable (Array) gesetzt
B) User speichert ein Dokument
+ Im PostSave (nicht Querysave da RTF-Überwachung inclusive):
     - Array-Vergleich vorher / nachher, wenn keine Änderung: mache nix
     - setze History-Log zusammen, dabei Unterschied ob RTF oder nicht
     - Definiere 1. und 2. "Spalte" (durch Tab getrennt), hier Datum und Username
     - Setze String für Textfeld zusammen
     - Hänge Änderungen ans Textfeld an
     - Save

Ziel ist für mich, die Klasse prinzipiell für viele DB's verwenden zu können. Dinge wir den Namen des History-Feldes, die Anzahl der Historien-Einträge, etc. will ich der Klasse übergeben.
Bisher setze ich hier in der ScriptLib auch Standard-Functions wie Explode, Implode, CompareArray etc. ein.

Ich bin für jeden Ansatz dankbar, wie ich das in eine Klasse übernehmen könnte.

[TMC]

Nachtrag:
Gibt es irgend eine (3rdParty) - Möglichkeit für Notes-LS, um Klassen übersichtlicher als im Designer zu entwickeln? Ich denke da an eine Browse-Möglichkeit. Dass kompilieren in 3rd-Party wohl nicht möglich ist, ist mir klar, aber zumindest um den Überblick zu behalten wäre das wohl sehr hilfreich.

[animate]

ich kenne leider kein Tool, das objektorientierte Programmierung mit Notes irgendwie erleichtert. Hier im Forum wurde mal ein Projekt geboren (lssEclipse), ich glaube aber, dass es nicht mehr sehr lebendig ist.

zum Ansatz, den du wünschst:

schreib doch mal kurz auf, was diese Klasse können soll und, ggf., mit welchen anderen Klassen sie kooperieren soll.

und noch eine Frage hinterher:
warum möchtest du eine Klasse haben? Du hast ja scheinbar schon etwas funktionierendes in deiner History-Scriptlibrary...

[TMC]

Schade dass es da wohl nichts gibt, um Klassen besser bearbeiten zu können. Wenn ich mir überlege, dass ich den jetzigen Code komplett in die Declarations kopiere: ich würde k. wenn dann Anpassungen nötig sind  

warum möchtest du eine Klasse haben? Du hast ja scheinbar schon etwas funktionierendes in deiner History-Scriptlibrary...

Sehr berechtigte Frage, ich glaube ich werde es dabei lassen. Die Subs/Functions, die ich ausschließlich in dieser ScriptLib verwende, mache ich noch zu "Private", dokumentiere das ganze in den Declarations, und dann sollte das gut so sein.

Mein Ziel war, etwas dabei zu lernen. Aber ich denke das gehe ich mal neu an bei einem anderen passenden Projekt.

[Semeaphoros]

Es gibt da so einen Kompromiss, der manchmal ganz nützlich ist: man defniert eine Klasse, die einzelnen Member-Routinen machen aber nichts anderes, als eine normale Sub oder Function aus der gleichen ScriptLib auf. Man achtet dann natürlich darauf, dass beim Verwenden der Klasse nie die Klasse selbst dadurch umgangen wird, dass man die Subs und Functions direkt aufruft. Damit hat man dann aber die gewünschte gewohnte Designer-Darstellung für seine "Methoden".

Class Beispiel
  daten as Datentyp

sub MemberMachIrgendwas (Param As String)
   Call ExtMachIrgendwas (Param)
End Sub

function MemberMachWasAnderes (X as Integer) As String
  MemberMachWasAnderes = ExtMachWasAnderes(X)
End Funcition

End Class


'****

sub ExtMachIrgendwas (Param As String)
  REM Hier der effektive Code
End Sub


'****

function ExtMachWasAnderes (X as Integer) As String
   ExtMachWasAnderes = "Die durchzuführende Berechnung mit X"
End Function

[TMC]

Danke, das klingt interessant Jens. Werde ich mir mal im Detail ansehen.

[animate]

warum möchtest du eine Klasse haben? Du hast ja scheinbar schon etwas funktionierendes in deiner History-Scriptlibrary...

Sehr berechtigte Frage, ich glaube ich werde es dabei lassen. Die Subs/Functions, die ich ausschließlich in dieser ScriptLib verwende, mache ich noch zu "Private", dokumentiere das ganze in den Declarations, und dann sollte das gut so sein.

Mein Ziel war, etwas dabei zu lernen. Aber ich denke das gehe ich mal neu an bei einem anderen passenden Projekt.

Ich denke, du kannst auch was lernen, wenn du ein objektorientiertes History-Framework entwickelst.
Meine Frage sollte nicht bewirken, dass du einen Rückzieher machst. Ich wollte wirklich nur wissen, warum - und 'lernen' ist schon ein ziemlich guter Grund.

Also nochmal: der erste Schritt ist, aufzuschreiben, was das Ding alles können soll. Los gehts...

[TMC]

Los gehts...

OK  

Der Grobablauf steht schonmal ganz oben.

Hab mir mal überlegt das etwas zu gliedern:


Wo es imho schon mal hängt ist, dass ich im Postopen-Event was in eine (in der Maske definierten) globalen Variable schreibe, worauf ich im Postsave wieder zugreifen will. Kann ich das in der Klasse machen oder muss ich das direkt im Postopen/Postsave machen?

[TMC]

OK, was ich der Bible von Rocky und Brian entnommen habe, ist das schon mal ein must-have in jeder Klasse:

[koehlerbv]

Schau mal hier, Matthias:
http://www-106.ibm.com/search/searchResults.jsp?searchType=1&searchSite=dW&query=%22bruce+perry%22&searchScope=lotus&Search.x=23&Search.y=13

Meines Erachtens ein hervorragender Einstieg !

Was Deine Klassen-Methoden angeht: Du kannst entweder die sowieso erforderliche Methode New dafür hernehmen, um
- alle globalen Variablen (als members Deiner Klasse) mit dem Ausgangsstatus zu versehen (in PostOpen) oder
- dieser erstmal nur "leer" zu instantiieren. Dann müsstest Du in PostOpen gleich nachschieben, die Methode "GetOriginalValues" zu verwenden (die das tun sollte, was ihr Name verspricht)
- In QuerySave oder PostSave rufst Du dann Deine Methode "WriteDifferences" auf, die den jetzt aktuellen Stand mit den Member-Variablen Deiner Klasse vergleicht und entsprechend verfährt.
Sowas wie die Prüfung auf die max. Grösse eines Textfeldes sollte dann innerhalb der Klasse als Private deklariert werden.

HTH,
Bernhard

PS: Sag an, wenn es wieder klemmt. Die ersten Schritte sind IMHO erstmal sehr schwer, aber wenn man darüber erstmal hinaus ist, fallen einem wirklich die "Schuppen aus den Haaren"  

[animate]

ok.
vorneweg: als geschickt würde ich es empfinden, midestens zwei Klassen zu erstellen:
Klasse History
Klasse HistoryEntry

wobei HistoryEntry eine abstrakte Klasse ist und als Basisklasse für zwei andere Klassen dient:
Klasse RTFHistoryEntry
Klasse TextHistoryEntry

(abstrakte Klasse bedeutet, dass von dieser Klasse nie eine Instanz/ ein Objekt erzeugt wird. Basisklasse bedeutet, dass von ihr andere Klassen abgeleitet sind, die ihre Methoden und Attribute erben)

in der Praxis könnte das dann so aussehen, dass ein History-Objekt ermittelt, welcher Eintrag (Text oder RTF) erzeugt werden muss.
Das kann es z.B. anhand eines Feldwerts oder der Präsenz bzw. Absenz eines Felds im Notesdokument entscheiden.
Das History-Objekt erzeugt dann ein entsprechendes HistoryEntry-Objekt und übergibt diesem die Daten, die es enthalten soll.
Das HistoryEntry-Objekt kennt das Notesdokument und weiß, wie es sich ins darin verewigen muss (also entweder als RTF oder als Text).

[animate]

Wo es imho schon mal hängt ist, dass ich im Postopen-Event was in eine (in der Maske definierten) globalen Variable schreibe, worauf ich im Postsave wieder zugreifen will. Kann ich das in der Klasse machen oder muss ich das direkt im Postopen/Postsave machen?

Du kannst die Behandlung von Events, die von der Maske ausgelöst werden, an die Klasse delegieren (das steht auch in dem Artikel, den Bernhard anführt).

Stichwort 'On Event x From y Call z'

[koehlerbv]

Ich würde das für den Anfang einfacher halten. EINE Klasse, und diese
- wird in den Declarations der Form instantiiert
- New löst entweder das Belegen der zu überwachenden Felder im Originalzustand aus oder es wird mit einer eigenen Methode der Klasse diese Belegung aufgerufen (auf jeden Fall: Ein Array der zu überwachenden Feldnamen wird an New übergeben)
- Ein Compare/Write History vergleicht und schreibt dann das History field.

Das Ganze kann man dann ja beliebig ausbauen  

Bernhard

[TMC]

Danke für Eure Tipps !

wobei HistoryEntry eine abstrakte Klasse ist und als Basisklasse für zwei andere Klassen dient

Hab ich das so jetzt richtig verstanden?




Was mir da noch nicht klar ist:
Ich (bzw. der Postopen- oder Postsave - Event) kommuniziere nur mit der Klasse "History" ? Die in den anderen Klassen benötigten Dinge gebe ich intern dann entsprechend weiter?

[animate]

Wo es imho schon mal hängt ist, dass ich im Postopen-Event was in eine (in der Maske definierten) globalen Variable schreibe, worauf ich im Postsave wieder zugreifen will. Kann ich das in der Klasse machen oder muss ich das direkt im Postopen/Postsave machen?

Du kannst die Behandlung von Events, die von der Maske ausgelöst werden, an die Klasse delegieren (das steht auch in dem Artikel, den Bernhard anführt).

Stichwort 'On Event x From y Call z'

Hier als Beispiel dazu ein Ausschnitt aus einer Klasse
Im QueryOpen-Event des Dokuments wird ein Objekt dieser Klass erzeugt. Alle für mich interessanten Events, die danach ausgelöst werden, werden von diesem Objekt behandelt (das wird in dem Konstruktor (Sub New) festgelegt).

Public Class xyz
   Private m_udFrontendDoc As notesuiDocument
   Private m_docBackendDoc As notesDocument

   Sub New(udCurrentDoc As notesUIDocument)
%REM
------------------------------------------------------------------------------------------------------------------------
Author:      TV
Date:      23.10.2003
Description:   Ich initialisiere meine Attribute und sorge dafür, dass Events aus dem FrontendDocument
         durch mich bearbeitet werden.
Parameter:   udCurrentDoc: NotesUIDocument
            Das Frontend-Dokument, das die Agent-Informationen anzeigt
Return Value:   <Name, Datentyp und Erklärung des Rückgabewertes>
History:      
------------------------------------------------------------------------------------------------------------------------
%END REM   
      
      'Frontend-Dokument und zugehöriges Backend-Dokument besorgen
      Set m_udFrontendDoc = udCurrentDoc
      
      'Achtung! Das BackendDokument ist in normalen Masken erst im Postopen Event verfügbar!
      'In Dialogboxen kann es schon im QueryOpen Event verfügbar sein.
      Set m_docBackendDoc = udCurrentDoc.Document
      
      'auf Events des FrontendDokuments reagieren
      On Event Postopen From m_udFrontendDoc Call ProcessPostopen
      On Event Postrecalc From m_udFrontendDoc Call ProcessPostrecalc
      
      'Zeitgesteuerte Agenten suchen und dem Benutzer zur Auswahl anzeigen
      Call initAgentMap()   
      Call collectScheduledAgents
      Call m_docBackendDoc.ReplaceItemValue(ST_DEFI_AMGR_AvailableAgents, m_asScheduledAgents)
   End Sub

   Sub ProcessPostopen(Source As Notesuidocument)
%REM
------------------------------------------------------------------------------------------------------------------------
Author:      TV
Date:      23.10.2003
Description:   Ich aktualisiere das FrontendDokument
Parameter:   <Name, Datentyp und Erklärung des Übergabeparameters>
Return Value:   <Name, Datentyp und Erklärung des Rückgabewertes>
History:      
------------------------------------------------------------------------------------------------------------------------
%END REM
      Call m_udFrontendDoc.Refresh()
   End Sub

End Class

[animate]

das könnte jetzt etwas wirr werden, aber wenn wir damit jetzt schon anfangen, dann machen wir das gleich gescheit.
Ich hab mal das Klassendiagramm mit UML gemalt. Das ist einfach der Standard, um sowas zu modellieren. Das Diagramm hängt als Attachment hier dran.

Die Kästen sind Klassen (im Moment noch ohne Methoden/Attribute).
Ganz oben in jedem Kasten steht der Klassenname, gefolgt von den Attributen und den Methoden.
Kursiv geschrieben Klassennamen bedeuten, die Klasse ist abstrakt (von ihr wird keine Instanz erzeugt).
Die Linien mit den großen Pfeilen am Ende heißen Genrealisierung ('ist ein')
Die Linien ohne Pfeile sind ungerichtete Assoziationen ('gehört zu', 'hat')
Die Zahlen, die bei diesen Assoziationen stehen sind die Kardinalitäten  (bestimmt bekannt aus ERD. 'Zu einem History-Objekt gehören n HistoryEntry-Objekte)

[TMC]

Was Deine Klassen-Methoden angeht: Du kannst entweder die sowieso erforderliche Methode New dafür hernehmen, um
- alle globalen Variablen (als members Deiner Klasse) mit dem Ausgangsstatus zu versehen (in PostOpen) oder
- dieser erstmal nur "leer" zu instantiieren. Dann müsstest Du in PostOpen gleich nachschieben, die Methode "GetOriginalValues" zu verwenden (die das tun sollte, was ihr Name verspricht)

Du kannst die Behandlung von Events, die von der Maske ausgelöst werden, an die Klasse delegieren (das steht auch in dem Artikel, den Bernhard anführt).
Stichwort 'On Event x From y Call z'

Was mir noch überhaupt nicht klar ist:

Ich habe bisher u.a. folgenden Code in der Maske (Auszüge):

Global Declarations

Code

Dim vGlobalHistoryFields As Variant
Dim vGlobalHistoryFieldTitles As Variant
Dim vGlobalHistorySource As Variant

PostOpen

Code

   vGlobalHistoryFields = fExplode(CHISTORYFIELDS, "##")
   vGlobalHistoryFieldTitles = fExplode(CHISTORYFIELDTITLES, "##")
   If Not Source.IsNewDoc Then
           'Write field values in global variable
      vGlobalHistorySource = fHistoryStoreItemValuesInArray(doc, vGlobalHistoryFields)
   End If

Was passiert da:
Es werden die zu überwachenden Feldnamen und die Item-Inhalte als Array in die globalen Variablen der Maske gesetzt.
Warum mach ich das:
Im Postsave hole ich mir die globalen Variable-Inhalte und mach was damit (vergleichen, etc.).

Jetzt die Frage:
Was kann ich davon in eine Klasse 'outsourcen' ? Kann ich die in der Maske ge-dim-ten  Variablen in einer Klasse setzen (ich will ja im PostSave wieder auf die im Postopen gesetzten Variablen wieder zurückgreifen können)? Oder muss ich das im Masken-Event erledigen?

(Ich hoffe dass ich die Frage einigermaßen klar rüberbringe....)

[animate]

Was mir da noch nicht klar ist:
Ich (bzw. der Postopen- oder Postsave - Event) kommuniziere nur mit der Klasse "History" ? Die in den anderen Klassen benötigten Dinge gebe ich intern dann entsprechend weiter?

Ja, genau, du erzeugst ein History-Objekt im Postopen-Event, und das wars dann schon an Code, den du in der Maske benötigst.

Wenn du das wirklich zur Übung machen willst, um OOx zu lernen dann würde ich mal darüber nachdenken, ob wir evtl. nicht eine Klasse Dokument brauchen (ich hab das schon in meinem Diagramm angedeutet)
Das wäre in meinen Augen korrekt.

[animate]

Ich habe bisher u.a. folgenden Code in der Maske (Auszüge):

Global Declarations

Code

Dim vGlobalHistoryFields As Variant
Dim vGlobalHistoryFieldTitles As Variant
Dim vGlobalHistorySource As Variant

PostOpen

Code

   vGlobalHistoryFields = fExplode(CHISTORYFIELDS, "##")
   vGlobalHistoryFieldTitles = fExplode(CHISTORYFIELDTITLES, "##")
   If Not Source.IsNewDoc Then
           'Write field values in global variable
      vGlobalHistorySource = fHistoryStoreItemValuesInArray(doc, vGlobalHistoryFields)
   End If

aha, so machst du das. vGlobalHistoryFields sind die Felder, die beobachtet werden sollen, stimmts?
Mein erster Gedanke ist, dass wir hier wieder einen Kandidaten für eine Klasse haben. Ich muss mal kurz nachdenken.
Aber egal, was dabei rauskommt, du solltest das alles aus der Maske rausbringen. Ok, die Information, welche Felder beobachtet werden sollen, kann man evtl. in der Maske lassen, aber keine Logik

[TMC]

das könnte jetzt etwas wirr werden, aber wenn wir damit jetzt schon anfangen, dann machen wir das gleich gescheit.
Ich hab mal das Klassendiagramm mit UML gemalt. Das ist einfach der Standard, um sowas zu modellieren. Das Diagramm hängt als Attachment hier dran.

Die Kästen sind Klassen (im Moment noch ohne Methoden/Attribute).
Ganz oben in jedem Kasten steht der Klassenname, gefolgt von den Attributen und den Methoden.
Kursiv geschrieben Klassennamen bedeuten, die Klasse ist abstrakt (von ihr wird keine Instanz erzeugt).
Die Linien mit den großen Pfeilen am Ende heißen Genrealisierung ('ist ein')
Die Linien ohne Pfeile sind ungerichtete Assoziationen ('gehört zu', 'hat')
Die Zahlen, die bei diesen Assoziationen stehen sind die Kardinalitäten  (bestimmt bekannt aus ERD. 'Zu einem History-Objekt gehören n HistoryEntry-Objekte)

Danke für die Tipps und die Zeichnung.
Wo "malt" man sowas am besten? Ich habe hier MS Visio 2002. Na ja, ist damit sicherlich machbar. Werde mir mal ein paar Visio-Shapes dafür zusammenzimmern (wenn diese nicht eh schon dabei sind).