Wie kann ich eine Klasse sinnvoll aufbauen ?

[TMC]

Im Konstruktor des History-Objekts (oder in einer Methode, die von dort aus aufgerufen wird) erzeugen wir für jeden Eintrag im Dokument ein HistoryEntry-Objekt und fügen es unserem Array (m_HistoryEntries, s. oben) hinzu.

Meinst Du damit, dass pro Feld-Änderung ein HistoryEntry-Objekt erzeugt wird? Also: Feld1 hat sich geändert -> wir machen ein neues HistoryEntry-Objekt auf, Feld2 hat sich geändert -> wir machen ein weiteres neues HistoryEntry-Objekt auf usw. ?

[animate]

nein. pro Eintrag.
Ein Eintrag enthält alle Änderungen eines Speichervorgangs.
wenn deine Einträge einzeilig wären, könnte man sagen ein Objekt pro Zeile

[animate]

das heißt, du liest beim Öffnen des Dokuments erstmal alle History-Einträge aus (musst du ja sowieso machen, um die Größe zu bestimmen).

[TMC]

Danke, hab ich nun soweit verstanden.

Das hier bestätigt es auch:

Wir haben jetzt also alle HistoryEntry-Objekte in unserem Array, und können bevor wir sie ins Dokument schreiben jedes HistoryEntry-Objekt fragen, wie groß es ist, und mit dieser Information entscheiden, wie viele Einträge wir machen.

Blöde Frage: Was bringt es, alle Einträge separat in einem Objekt zu haben? Oder anders herum: Ist das eleganter, als wie wenn man das komplette Array (also ein String-Array mit den History-Einträgen) als ganzes behandelt?
Ich sehe da noch nicht ganz den Vorteil.

[animate]

Nur ne Idee. Einigermaßen verständlich?

Leider nicht ganz.
Liegt wohl auch an meinem etwas anderen Ansatz.

Also wie gesagt, im Konstruktor der History lesen wir die bisherigen History-Einträge im Dokument aus und erstellen für jeden Eintrag ein HistoryEntry-Objekt. Alle HistoryEntry-Objekte wandern in ein Array/Liste/...
Die Liste ist Attribut der History (Membervariable)

Zu dieser Liste kommt noch der HistoryEntry für die aktuelle Änderung.

Ein Dokument wurde bis jetzt dreimal gespeichert und gerade wurde es zum vierten Mal gespeichert, ergo haben wir vier HistoryEntry-Objekte.

O1 vom 10.06.
O2 vom 12.06.
O3 vom 17.06.
O4 vom 25.06.

So, nun müssen wir die History im Notesdokument aktualisieren und dabei aufpassen, dass wir nicht zuviel Text schreiben.
Die max. Größe ist unserem History-Objekt bekannt.
Ebenfalls kennt dieses Objekt alle HistoryEntry-Objkete, die ins Dokument müssen.

Mein Gedanke ist nun, dass das HistoryObjekt nacheinander jedes HistoryEntry-Objekt fragt, wie groß es ist und zwar solange, bis die Gesamtgröße überschritten wurde oder eben kein Objekt mehr zum Fragen da ist.

Also:
Größe max = 15k

O4, wie groß bist du? - 4k -> Summe 4, OK
O3, wie groß bist du? - 4k -> Summe 8, OK
O2, wie groß bist du? - 4k -> Summe 12, OK
O1, wie groß bist du? - 4k -> Summe 16, mööp

O2, schreib dich ins Dokument
O3, schreib dich ins Dokument
O4, schreib dich ins Dokument


oder zumindest so ähnlich.
etwas klarer?

[TMC]

Danke für die Ausführung, Thomas.

Nun habe auch ich das verstanden  

Die Vorgehensweise klingt sehr vernünftig. So vermeidest Du auch Endlos-Schleifen (wie ich z.B. vorhin erzeugt habe).

Frage: Würde das nicht auch via eine normale Function realisierbar sein?
Also sowas wie
Function Irgendwas (vInput, iMax) as Variant
Den Rückgabewert würde ich da dann ins History-Item setzen.

Soll jetzt wirklich nicht negativ klingen. Als Übung werde ich versuchen das so via Objekte umzusetzen (ich will ja OO lernen), aber mir macht es den Anschein, dass da eine Function hier einfacher wäre.

[animate]

Was bringt es, alle Einträge separat in einem Objekt zu haben? Oder anders herum: Ist das eleganter, als wie wenn man das komplette Array (also ein String-Array mit den History-Einträgen) als ganzes behandelt?
Ich sehe da noch nicht ganz den Vorteil.

Eleganter ist es vielleicht, aber vor allem ist es objektorientiert, und genau das wollen wir hier üben, wenn ich das richtig verstanden habe.
 

Im Ernst, einen direkt messbaren Vorteil kann ich dir für diesen Fall nicht nennen. Ich vermute, dass du einen Vorteil hast, wenn sich mal was an den Anforderungen an deine History ändert, das diese Stelle betrifft (mir fällt grade keine gescheite Änderung ein). Kann natürlich sein, dass der Fall nie eintritt.

Ich persönlich finde es auf die Art, die ich beschrieben habe einfacher und leichter verständlich.

[TMC]

OK  
Wie auch immer, ich werde auf jeden Fall Deinen Weg gehen - alleine schon weil es eine gute Übung für mich ist  

[animate]

Frage: Würde das nicht auch via eine normale Function realisierbar sein?
Also sowas wie
Function Irgendwas (vInput, iMax) as Variant
Den Rückgabewert würde ich da dann ins History-Item setzen.

klar, warum nicht?!

Soll jetzt wirklich nicht negativ klingen. Als Übung werde ich versuchen das so via Objekte umzusetzen (ich will ja OO lernen), aber mir macht es den Anschein, dass da eine Function hier einfacher wäre.

Kein Problem. Das mit dem 'einfacher' ist halt so eine Sache.
Für dich ist es einfacher, das auf die Art zu lösen, die du bis jetzt immer benutzt hast. Wen wundert das?
Für mich ist es einfacher, das etwas anders anzugehen. Und es macht mir verdammt viel Spaß

[TMC]

Für dich ist es einfacher, dass auf die Art zu lösen, die du bis jetzt immer benutzt hast. Wen wundert das?

Da passt der Spruch "Was der Bauer nicht kennt, das isst er nicht".

Ich habe ja oben schon geschrieben dass ich OO lernen will - und das war ja auch der Auslöser dieses Threads. Erst wenn ich das drauf habe (und das wird wohl bestimmt nicht von heute auf morgen sein) steht es mir imho zu, über Pro/Contra hierüber zu diskutieren  

[Marinero Atlántico]

Hi,

Total offtopic:
trotz anders angekündigt, komme ich später zum code zurück.
Das ganze hier finde ich ziemlich interessant. Ich mache nur am Mittwoch meine letzte Websphere certi und WAS gibt mir momentan eine harte Zeit mit zahlreichen kleinlichen ErrorMeldungen, wie

Code

In der JMSConnection für MDB SampleMDB, JMSDestination jms/sampleQ ist ein Fehler aufgetreten: javax.jms.JMSException: MQJMS2008: Fehler beim Öffnen der MQ-Warteschlange.  

[TMC]

Hab mir das jetzt so überlegt:

Im Konstruktor des History-Objekts (oder in einer Methode, die von dort aus aufgerufen wird) erzeugen wir für jeden Eintrag im Dokument ein HistoryEntry-Objekt und fügen es unserem Array (m_HistoryEntries, s. oben) hinzu.

Problem dabei ist, dass ich ja ein History-Entry - Objekt auch unabhängig erzeugen will, um beispielsweise auch so mal was in die History zu schreieben ("Dokument freigegeben" etc.)

Daher habe ich mir überlegt, eine "HistorySize" - Klasse zu erstellen (siehe Grafik oben). Ob das so 100% Sinn macht kann ich noch nicht sagen  

[animate]

was ist denn die Aufgabe der HistorySize-Klasse?
was spricht dagegen, dem HistoryEntry ein Attribut Size zu verpassen?
Auch die History selbst könnte ein Attribut Size haben, das ist dann ganz einfach die Größen aller Einträge addiert.

was hindert dich daran, einen HistoryEntry "einfach so" zu erstellen?

[TMC]

Thomas, ich hab hier mal (nicht UML-konform) zusammengestellt wie ich Deine Vorgehensweise verstehe:


Was ich hier nicht kapiere:
Wie würde den der Code aussehen, wenn ich unabhängig eine neue Zeile der History hinzufügen will?

Aktuell kann ich ja folgendes machen:

Code

Sub Click(Source As Button)
   Dim session As New NotesSession
   Dim db As NotesDatabase
   Dim doc As NotesDocument   
   Dim uiws As New NotesUIWorkspace
   Dim uidoc As NotesUIDocument
   Dim HistoryEntry As HistoryEntry
   Dim strEntry(0) As String   
   Set db = session.CurrentDatabase
   Set uidoc = uiws.CurrentDocument
   Set doc = uidoc.Document
   strEntry(0) = uiws.Prompt(PROMPT_OKCANCELEDIT,"Historien-Eintrag", "Hier einen Text eingeben:" , "" ,"")
   Set HistoryEntry = New HistoryEntry(doc, 10)
   HistoryEntry.Action =    strEntry
   Call HistoryEntry.write()
   Call doc.save(True,True)
   Call uidoc.refresh
End Sub

[TMC]

was ist denn die Aufgabe der HistorySize-Klasse?

Ich hatte mir gedacht, dass ich pro Eintrag im Historyfeld ein HistorySize-Objekt erstelle. Also ähnlich wie Du oben vorgeschlagen hast, das über HistoryEntry-Objekte abzubilden.

[animate]

Was ich hier nicht kapiere:
Wie würde den der Code aussehen, wenn ich unabhängig eine neue Zeile der History hinzufügen will?

mal überlegen...
bevor du einen Eintrag ins Dokumnet schreiben kannst, musst du ja erst prüfen, ob genügend Platz da ist.
Das weiß die History, weil sie ja alle Einträge (und damit deren Gesamtgröße) und auch die maximale Größe kennt.

Im Moment fällt mir dazu folgendes ein: du erstellst einen HistoryEntry und übergibst ihn an eine (noch zu erstellende) Methode der History (z.B. addEntry, falls es die nicht schon gibt).
Die History macht dann das gleiche, was sie auch mit einem "normalen Eintrag" macht (also zum Array hinzufügen, Größe prüfen, schreiben)

so kann ich mir das zumindest vorstellen

[animate]

was ist denn die Aufgabe der HistorySize-Klasse?

Ich hatte mir gedacht, dass ich pro Eintrag im Historyfeld ein HistorySize-Objekt erstelle. Also ähnlich wie Du oben vorgeschlagen hast, das über HistoryEntry-Objekte abzubilden.

ok. dann würde diese Klasse nur ein Attribut enthalten (also die Größe selbst)? Dann macht es keinen Sinn, dafür eine Klasse zu bauen.

und eine Klasse, die in Beziehung zu einer anderen steht ist im Prinzip nichts anderes als ein Attribut dieser Klasse. Eben ein etwas komplexeres. Das Attribut Size dürfte bei uns wohl ein Integer oder sowas sein, das kannst du ruhig als Attribut der HistoryEntry-Klasse nehmen.

[TMC]

Aber ist es nicht einfacher, man hält die Aufgaben auseinander?

Also:
HistoryMain:
+ Ausschließlich für PostOpen / Postsave; Zweck ist Feldvergleich und damit
    Aufbereitung des "Actions"-Textes.

HistoryEntry:
+ Einträge ins History-Feld eines Dokumentes schreiben;
   dabei überwachen, dass
     a) Textfeldgröße nicht überschritten wird
     b) Maximal erlaubte Anzahl an Einträgen nicht überschritten wird

(ich denke wahrscheinlich schon wieder viel zu funktionsorientiert.... )

[animate]

Aber ist es nicht einfacher, man hält die Aufgaben auseinander?

Also:
HistoryMain:
+ Ausschließlich für PostOpen / Postsave; Zweck ist Feldvergleich und damit
    Aufbereitung des "Actions"-Textes.

HistoryEntry:
+ Einträge ins History-Feld eines Dokumentes schreiben;
   dabei überwachen, dass
     a) Textfeldgröße nicht überschritten wird
     b) Maximal erlaubte Anzahl an Einträgen nicht überschritten wird

nicht in meinen Augen.
nur die History selbst weiß, wieviele Einträge es gibt und wie groß die sind.
sie hat den Überblick und sollte deshalb entscheiden, wer noch ins Dokument darf und wer nicht.

ich kann mir ehrlich gesagt gar nicht vorstellen, wie diese Aufgaben vom HistoryEntry übernommen werden könnten.

(ich denke wahrscheinlich schon wieder viel zu funktionsorientiert.... )

das ist wohl möglich. aber nicht ungewöhnlich. du kannst nicht den Schalter umlegen und von heute auf morgen die Denkweise umstellen. das kommt schon noch, wenn du weiter interssiert bleibst und irgendwann mal erkennst, wie simpel man sich das Leben mit dieser Sache machen kann.

[Marinero Atlántico]

nicht einfach euch zu folgen. Im Grunde ist die History Size durch das Sternchen in

Code

HistoryMain 1 -------- * HistoryField

schon ausreichend behandelt.