Wie kann ich eine Klasse sinnvoll aufbauen ?

[TMC]

Na ja, du hast es scheinbar auch ohne Kommentare gecheckt.

Ich hangle mich so durch  
Ist zwar etwas hin- und herspringerei zwischen den Klassen, Functions etc. aber komm dann schon drauf :-)

[TMC]

Noch eine Frage:

Warum gibt es diese Sub in der History Main?

Code

   Private Sub clear()
      Call m_doc.ReplaceItemValue("History", "")
   End Sub

[animate]

die löscht alle Einträge aus dem Dokument.
dann schreib ich alle Einträge, die ins Feld passen wieder rein.

Also statt die überschüssigen Einträge aus dem Dokument zu entfernen schmeiße ich erstmal alle raus und schreibe nur die gewünschten wieder rein.
Das erschien mir der einfachere Weg

[animate]

ich gebe zu, es ist nicht sehr fein, weil die Klasse somit auch Feldnamen kennen muss.
Vielleicht wäre es besser, der HistoryEntry-Klasse eine Delete-Methode zu verpassen. Sehr wahrscheinlich sogar.
Das erste Refactoring kommt bestimmt...

[TMC]

Ah, ok.
Die Frage kam u.a. daher, weil ich in meiner Version "03" in der Sub write() der History Entry Klasse den Code "Set m_itmHistory = m_doc.ReplaceItemValue( m_strHistoryFieldName, m_vaTarget )" hatte, also direkt reinschrieb / überschrieb.

Ansonsten war mir das auch klar, dass vorgegebene Feldnamen wie "History" nicht besonders elegant ist (kam glaub ich ja ursprünglich von mir aufgrund Faulheit).

Sollte imho auch mehr- oder weniger zentral definiert werden; evtl. in den Global Decs der Maske (und dann via Objekt "HistoryMonitorDoc" in das History-Objekt kippen.)

[TMC]

Hab gerade ein Debug-Problem (in R5) festgestellt:

Wird bei laufendem Debugger ein "Save" durchgeführt kommt überhaupt nix. Nur wenn ich einen Error = XY einbaue, kommt erst die Fehlermeldung, und dann erst sehe ich den Debugger.

Ist das ein Notes-Bug? Scheint wohl so  


*edit* Ich platziere das Problem mal separat im R5-Problemforum, da wird das eher wie hier mittendrin....

[TMC]

Ich habe eine Frage zur geplanten Klasse "Field":

zu den Hilfsfunktionen:
Explode und ErrorHandler sind Kandidaten für eine 'Hilfsfunktions-Bibliothek'

die anderen haben alle was mit Feldern zu tun (gib mir Werte, zeig mir Unterschiede, ...) damit haben wir einen neuen Kandidaten für eine Klasse 'Feld'. die all diese Funktionalität zur Verfügung stellt.

ich habe Anmerkung zu der neuen Klasse.

Was du gemacht hast ist, vereinfacht ausgedrückt, die Funktionen gepackt, in eine Bibliothek gepackt und 'Class' drum herum geschrieben.

Das ist nix Schlimmes, nur ist das nicht so ganz das, was ich mir vorgestellt habe, als ich schrieb, wir brauchen eine Feld-Klasse, und das ist ja auch nicht schlimm.

Da wir hier aber in einem Thread sind, in dem es darum geht, wie man geschickt objektorientiert analysiert, entwirft und programmiert, versuche ich zu erklären, was ich beim Schreiben im Kopf hatte.
Ein Objekt der Klasse 'Feld' repräsentiert genau ein zu überwachendes Feld aus dem Notesdokument. D.h., wenn ich drei Felder überwachen will, dann brauche ich drei Objekte. Jedes Objekt kann mir Auskunft darüber geben, welchen Wert 'sein' Feld hat, welchen es ürsprünglich hatte bzw. worin der Unterschied zwischen den beiden Werten besteht.
Unser History-Objekt müsste alle Feld-Objekte instanziieren und würde so alle kennen. Wenns dann zum schreiben der Änderungen geht, frägt das History-Objekt der Reihe nach seine Feld-Objekte nach ihren Änderungen und gibt die Ergebnisse an das HistoryEntry-Objekt oder evtl. noch besser, sie übergibt die Feld-Objekte an das History-Entry-Objekt und das fragt selbst nach.

Wir könnten hier das gleiche Prinzip anwenden, wie ich bei der HistoryEntry-Klasse vorgeschlagen habe, also eine abstrakte Basisklasse 'Feld' und davon abgeleitete Klassen 'Textfeld' und 'RTFFeld'
(ich hab da in deinem Code irgendwas mit "I AM RTF" gesehen, ich weiß zwar nicht genau, wofür das ist, aber evtl. könnte man sowas durch solche Subklassen umgehen...)

Ich habe ja bisher 2 Functions hierfür:
a) Differences: Man kippt 2 Arrays rein: 1 Array mit den bisherigen Feldinhalten (Inhalt von Company, Street, City etc.) und 1 Array mit den neuen Feldinhalten.
Als Ergebnis erhält man dann Array, das alle Änderungen enthält.

b) ItemValuesToArray
Hier kippt man ein NotesDocument und ein Array (Namen der Felder) rein und erhält die Feldinhalte als Array

So richtig verstehe ich jetzt nicht, was mir nun ein Objekt pro Feld hier bringt.
Denn die Abarbeitung der Objekte müsste ich dann doch wieder z.B. über eine Function machen (ItemValuesToArray z.B......), die ja wohl nicht in der Feld-Klasse Sinn macht.

[animate]

ich bin nicht mehr so ganz auf dem Laufenden, ich versuche mal zu erklären

also die Klasse Feld könnte ungefähr so aussehen.

Attribute:
anfangswert
endwert
(evtl. das notesitem)

Methoden:
getUnterschied

So, die History würde also für jedes zu überwachende Feld ein Objekt erzeugen und die Attributwerte setzen (vorher, nachher).
Wenn die History einen HistoryEintrag veranlassen möchte, frägt sie erstmal jedes Feld: "Gibts du mir bitte deine Unterschiede?"
Das Feld tut das, die History baut sich daraus was zusammen und übergibt das an den HistoryEintrag.

Vorteil(e)

du kannst diese Feld-Klasse in anderen Applikationen unverändert einsetzen. Es kann ja vorkommen, dass du mal nicht die Unterschiede mehrerer Felder in einem Array brauchst, sondern einzeln oder auch ganz anders kombiniert.
Du kannst dich darauf verlassen, ein Feld-Objekt gibt dir immer den UNterschied. Was du damit machst kann variieren.
Deine beiden Funktionen kannst du nur in diesem Anwendungsfall nutzen.
Für andere Fälle müsstest du neue Funktionen machen, die sich vielleicht sogar nur marginal unterscheiden, oder die bestehenden Funktionen erweitern (mit if..then, o.ä.).

was auch noch cool sein könnte: wenn du die Klasse Feld abstrakt machst und davon spezielle Klassen ableitest (z.B. Textfeld, RTFeld, Zahlfeld),
dann wärst du sehr variabel bei der Form der Unterschiede.
D.h. ein Textfeld gibt die den Unterschied als Text zurück, ein RTFeld gibt dir Datum der Änderung zurück, ein Zahlfeld gibt dir eine Differenz/Summe zurück, etc.
Da können beliebig viele Spezialfälle hinzukommen, dein Code, der die Unterschiede vom Feld-Objekt verlangt, muss sich nicht ändern (oder nur sehr gering) Die Spezialbehandlung erfolgt in den jeweiligen Klassen, darum brauchst du dich als Nutzer der Klassen nicht kümmern (natürlich musst du es vorher programmieren).

ich glaube, dass ich das noch nicht klar rübergebracht habe.
Hak bitte nach, wenn nötig

[TMC]

Danke Thomas, ist nun verständlich und klingt auch sehr sinnvoll.

[TMC]

Was ich noch nicht ganz kapiere ist der Zusammenhang Field-Objekt mit FieldText-Objekt.
Hatten wir ja glaub ich auch schon bei HistoryEntry und HistoryEntryText etc.

Wie ich das sehe:
Das Field-Objekt ist ein Auto.
Das FieldText-Objekt ist der Reifen vorne Links.

Was ich gesehen habe wird das Auto kursiv in den UML-Diagrammen dargestellt. Ich glaub ich kann dann auch das Auto-Objekt nicht direkt erzeugen. Ich fange beim Reifen an.

Wie sind denn hier die Zusammenhänge? Und: Warum ist das Auto "kursiv"? Warum mache ich nicht ein normales Auto-Objekt, welches dann auch Objekte wie Reifen vorne links und Fahrersitz enthält?

(wohl eine absolute Beginner Frage)

Matthias

[animate]

Was ich noch nicht ganz kapiere ist der Zusammenhang Field-Objekt mit FieldText-Objekt.
Wie ich das sehe:
Das Field-Objekt ist ein Auto.
Das FieldText-Objekt ist der Reifen vorne Links.

falsch.
das ist Vererbung.
Field ist ein Auto.
FieldText ist ein Sportwagen.
FieldRTF ist ein Kombi.
FieldNumbers ist ein Jeep.

Alle sind Autos und alle haben was gemeinsam. Aber bei speziellen Dingen unterscheiden sie sich.
Bei unseren Feldern wäre z.B. eine Gemeinsamkeit, dass alle eine Wert vor und einem nach dem Speichern haben können.
Das Spezielle ist, dass jede Feld-Art den Unterschied zwischen Vor- und Nachher anders "berechnet".

Was ich gesehen habe wird das Auto kursiv in den UML-Diagrammen dargestellt. Ich glaub ich kann dann auch das Auto-Objekt nicht direkt erzeugen. Ich fange beim Reifen an.

Wie sind denn hier die Zusammenhänge? Und: Warum ist das Auto "kursiv"? Warum mache ich nicht ein normales Auto-Objekt, welches dann auch Objekte wie Reifen vorne links und Fahrersitz enthält?

Auto ist kursiv, weil es das nicht wirklich gibt. Es gibt nur Jeeps, Cabrios, Kombis, Limousinen, etc.
Auto ist der Oberbegriff für alle.

Feld ist kursiv, weil es kein allgemeines Feld bei uns gibt (wir erinnern uns: kursiv bedeutet abstrakte Klasse, d.h. von dieser Klasse kann keine Instanz erzeugt werden, weil es die ja gar nicht geben kann.)

Ein schönes Beispiel aus "Head First Java" (frei übersetzt):

Es gibt eine Klasse "Tier"
Von dieser erben die Klassen "Canidae" und "Felidae".

Von "Canidae" erbt "Hund", "Wolf"
Von "Felidae" erbt "Katze", "Löwe"

Es macht Sinn, Objekte der Klasse "Hund", "Wolf", "Katze" und "Löwe" zu erstellen.
Aber was genau ist ein "Tier"-Objekt??
Welche Form hat es? Welche Frabe, Größe, Anzahl an Beinen...

Wenn du versuchst, ein "Tier"-Objekt zu erstellen, dann ist das wie ein verheerender Transporterunfall in StarTrek. So einer, wo bei Beam-Vorgang irgenwas schlimmes mit dem Puffer (der, in dem die Transportmuster sind) passiert.

Du brauchst aber trotzdem eine Klasse, die Gemeinsamkeiten vererben kann. Um zu vermeiden, dass Objekte einer Klasse erstellt werden, für die das keinen Sinn macht, machst du die Klasse abstrakt.
Zumindest in Java. In LotusScript gibt es keine abstrakten Klassen, ich tue aber so, als ob.

[TMC]

Danke Thomas, nun wird für mich vieles klarer :-)

Sehr gute Erkärung.

Na ja, nächste Frage kommt bestimmt noch, aber das ist ja u.a. auch Sinn und Zweck dieses Threads  

[TMC]

Neue (allgemeine) Frage:

Wann nehme ich "sub new(irgendwas as ...)" und wann "Public Property Set", um meinem Objekt Eigenschaften zu geben?

OK, sub new() geht ja nur, wenn ich das Objekt erzeuge.

Warum ich frage:
Es könnte ja sein, dass ich in der Klasse eine Function habe, die braucht aber unbedingt eine Variable. Soll man da dann die Variable gleich zu Beginn der Objekterzeugung geben lassen (eben über sub new) Aber vielleicht kenne ich die am Anfang noch gar nicht?
Denn wenn die Property nicht gesetzt ist (Public Property Set...), dann erhalte ich einen Fehler, weil ja die Function eine Variable braucht.

Ich hoffe meine Frage ist einigermaßen verständlich....  

[TMC]

Noch ne Frage zu abstrakten Klassen:

So wie ich das jetzt kapiere, versucht man wohl, so viel wie es Sinn macht in eine übergeordnete, abstrakte Klasse zu packen - und nur die Unterschiede dann in die darunterliegenden Klassen. Um auch u.U. später neue darunterliegende Klassen erzeugen zu können.

Wie ich oben in einem Code gesehen habe, ruft man die Abstrakte Klasse via
"Public Class UNTERKLASSE As ABSTRAKTEKLASSE" auf.

Ich habe damit auch Zugriff auf private Membervariablen der "ABSTRAKTEKLASSE".
Was kann ich noch alles auslagern in eine abstrakte Klasse? Functions/Subs wohl bestimmt.
Get/Set-Methoden gehen wohl nicht, wenn ich von da aus eine Function einer Unterklasse aufrufen will. Denn die abstrakte Klasse lässt sich dann nicht kompilieren.....

[Semeaphoros]

Zuerst mal zur ersten Frage, tatsächlich macht es Sinn, möglichst früh irgendwleche Member-Variablen zu besetzen, vor allem, wenn sie später unbedingt gebraucht werden, also wenn immer möglich werden die schon mit New initialisiert, wenn das nicht geht, dann muss man eben über eine setter-methode arbeiten. Man kann das aber auch kombinieren, indem eine Setter-Methode definiert und bei New überprüft, ob der Parameter gültig ist, wenn ja, wird von New aus die Setter-Methode aufgerufen.

Zu den abstrakten Klassen (wobei das in diesem Falle irrelevant ist, ob die Oberklasse abstrakt ist oder "konkret", abstrakt besagt ja nur, dass man diese Klasse selbst nicht instanziieren kann (oder im Falle von LS sollte) und hat sonst nix zu bedeuten).

Du kannst alles in die Basisklasse hinüberbringen, was Sinn macht, inklusive Setter- und Getter Methoden. Die werden alle schön brav mitvererbt. Vielleicht studierst Du mal die Vererbung in der Hilfe und die für LS besondere Schreibweise, wenn eine an sich überschriebene Methode der Basisklasse aufgerufen werden soll, da gibts dann die besondere DotDot-Notation:

Basisklase..MethodeDerBasisklasse

Für Fortgeschrittene zum Nachschlagen: Early binding und Late Binding spielt hier auch eine Rolle (und dann sind wir schon bald einmal bei abstrakten Methoden). Um, das ist schon eine geballte Ladung, aber gibt vielleicht eine Idee davon, dass wir es hier mit einer ziemlich komplexen Vererbungsstruktur zu tun haben.

[TMC]

Danke, Jens, für die Infos.

Gerade DotDot - Notation ist da für mich sehr hilfreich.

[TMC]

Nun hänge ich wieder fest:

Ich habe 1 sozusagen abstrakte Klasse.

Da steht u.a. drin:

Code

   Public Property Get myDifference As Variant
      myDifference = .getDifference("Wert 1")
   End Property      

Dann habe ich eine Unterklasse ("HistoryField2Text"), da ist u.a. folgende Function:

Code

   Private Function getDifference(strTest As String) As String
      getDifference = strTest & "bla bla"
   End Function

Nun habe ich einen Button in einer Maske mit folgendem Code:

Code

Sub Click(Source As Button)
   
   Dim myHiFiText As HistoryField2Text
   Dim test As Variant   
   test = myHiFiText.myDifference
   Msgbox test   
   
End Sub

Beim Ausführen kommt in der Zeile "test = myHiFiText.myDifference" die Fehlermeldung "Object Variable not set".

Any idea?
Ich habe bewusst nicht den ganzen Code zwecks Übersichtlichkeit gepostet. Wenn nötig hänge ich den aber natürlich rein.

[Semeaphoros]

Füge mal ein:

Set myHiFiText = New HistoryField2Text

irgendwo nach dem Dim myHiFiText

[TMC]

Jo mei, klar, danke. (ist ja schon fast peinlich  , egal da muss ich durch )

[TMC]

Nächste Fehlermeldung im o.g. Beispiel:
"Named product object does not exist"

Fehlermeldung kommt in Zeile "myDifference = .getDifference("Wert 1")" (steht in der abstrakten Klasse).

Erscheint mir so, dass die Function "getDifference" nicht gefunden wird....

Lt. Debugger werden sauber beide sub new() der Klassen durchlaufen.

Was möchte ich überhaupt:
In der abstrakten Klasse eine Property definieren, aber den Code dann in einer Unterklasse haben.