Wie kann ich eine Klasse sinnvoll aufbauen ?

[Axel]

@ata

Danke für dein Beispiel. Das werde ich mal probieren.

Mit diesen Code-Feldern habe ich mich auch schon mal beschäftigt, bin aber auf keinen grünen Zweig gekommen.


Axel

[TMC]

Zwischenfrage, Thomas:

Wofür stehen eigentlich die Präfixe "m_" in Deinem Beispiel? Ist das nur so gewählt, oder hat das irgend einen Zweck?

[animate]

Kennzeichnung für Membervariablen

[TMC]

Habe nun meine History komplett implementiert, allerdings in "nur" 3 Klassen:




Dabei ist vorgesehen, dass man ein "HistoryEntry" auch so erzeugen kann.
Man setzt dann einfach die Property z.B. auf historyentry.Action = "Status auf 'In Progress' gesetzt" und führt dann ein Call historyentry.write(doc) aus.

Danke nochmal für Dein Beispiel, Thomas, das war sehr hilfreich.

[animate]

wo machst du denn jetzt die Unterscheidung zwischen RTF-History und Text-History?

[TMC]

RTF habe ich vorerst nicht eingebaut. In der jetzigen Lösung schreibe ich die Werte in 1 Textfeld (Liste).

Die Unterscheidung würde ich in der "HistoryMain" machen in der "Private Sub writeHistory()".


Das ist übrigens mein bisheriger Code-Draft der Klasse "HistoryEntry":

Code

Public Class HistoryEntry
   Private m_itmHistory As NotesItem
   Private m_vAction As Variant
   Private m_strHistoryEntry As String
   '------------------------------------------------------------------------------------------------   
   Public Sub new()
      
   End Sub
   '------------------------------------------------------------------------------------------------   
   'Get/Set-Methoden
   Public Property Set Action As Variant
      m_vAction = Action   
   End Property
   '------------------------------------------------------------------------------------------------   
   Public Sub write(doc As NotesDocument)
        'neuen History - Eintrag schreiben
      Call assembleHistory()
      Set m_itmHistory = doc.GetFirstItem("History")
      Call m_itmHistory.AppendToTextList( m_strHistoryEntry )
'      Call doc.Save(True, True)
   End Sub
   '------------------------------------------------------------------------------------------------   
   Private Sub assembleHistory()
      'History zusammenstellen
   'Output ist in m_strHistoryEntry
      Dim session As New notessession
      Dim strName As String
      Dim strDate As String
      Dim i As Integer
      strName = session.CommonUsername
      strDate = Format$( Now , "dd.mm.yyyy hh:mm")
      
      For i = 0 To Ubound(m_vAction)
         If i=0 Then
            m_strHistoryEntry = strDate & Chr(9) & strName & Chr(9) & m_vAction(i)
         Else
            m_strHistoryEntry = m_strHistoryEntry & Chr(13)+Chr(10) & Chr(9) & Chr(9) & m_vAction(i)
         End If
      Next
      
   End Sub
   '------------------------------------------------------------------------------------------------   
   
End Class

Was aber nicht heißen soll, dass Deine Aufteilung nicht gut ist - war mir nur als Anfänger etwas zu kompliziert.

Was hier in der HistoryEntry - Klasse imho u.a. noch nicht perfekt ist:
 - Datumsformat ist statisch
 - Username ist statisch (vielleicht brauche ich mal ein anderes Format)
 - Prüfung wieviele History-Zeilen existieren ist noch nicht eingebaut.

[TMC]

Noch 'ne Frage:

Gibt's eigentlich spezielle Regeln  und Tipps für ErrorHandling in Klassen?

Oder macht man das "ganz normal" wie üblich in Functions und Subroutinen:
Wo man direkt eingreifen kann z.B. mit "If.....Then" abfangen, ansonsten am Anfang ein "On Error goto ErrorHandler"?
Wo habt Ihr den Code für die Fehlerabarbeitung? In den jeweiligen Klassen selber oder in einer eigenen Function/Sub, die Ihr von der Klasse aus aufruft?

[animate]

ich kenne keine speziellen Regeln.

[Marinero Atlántico]

Das mit dem ErrorHandling ist ein guter Punkt.

@Thomas: Verate uns ungewaschenen Massen den Trick, wie man in HistoryEntry die Factory implementiert , um das Strategy-Pattern für die Subklassen zu implementieren.
oder schickt mir eine nsf, wenn es für euer Zeugs bisher eine Implementierung aka Beispieldatenbank gibt.

Gruß Axel

[animate]

der Code und die Diagramme, die ich hier gepostet habe, sind von mir schnell zusammengezimmert worden. TMC hat das in eine DB gepackt und hier in den Thread gehängt.

Ich verwende kein Strategy und auch kein Factory-Pattern.

Wie TMC das jetzt gemacht hat, weiß ich nicht genau.
In meinem Fall war HistoryEntry abstrakt. Die Subklassen hatten spezielles Wissen darüber, wie sie die Informationen ins NotesDokuemnt schreiben müssen.
Als 'Factory' musste die History-Klasse selbst herhalten, die z.B. anhand eines Wertes/Feldes im betroffenen Dokument entscheidet, welches spezielle HistoryEntry-Objekt sie erstellt.

Wir können das sehr gerne weiter ausbauen. Mein Lösungsvorschlag ist vermutlich noch far from perfect und erhebt keinerlei Anspruch darauf, als Referenz herzuhalten.
Sowas ist vielleicht sogar ein interessantes Projekt für hier, weil zeitlich sehr überschaubar und evtl. von großem allgemeinem Nutzen.

[animate]

ah, ok. dieses HistoryEntry-Konstrukt kann man tatsächlich als Strategy sehen. War nicht bewusst von mir. Aber Factory hab ich keine. Das übernimmt die History-Klasse selbst
Aber ich bin echt auf Ideen gespannt, wie man das besser machen kann

[TMC]

Man gebe mir etwas Zeit, dann poste ich denn kompletten Sourcecode meiner bisherigen Umsetzung.  

[Marinero Atlántico]

Als 'Factory' musste die History-Klasse selbst herhalten, die z.B. anhand eines Wertes/Feldes im betroffenen Dokument entscheidet, welches spezielle HistoryEntry-Objekt sie erstellt.

Genau das habe ich gemeint. Warum Factory in Anführungszeichen. Für mich ist das eine Factory. Oder warum soll sie das nicht sein?

Das Geheimnis von Design Patterns ist, dass sie eigentlich nicht so geheimnisvoll sind und man schnell selber draufkommt. Wenn man sie kennt, hat man die Möglichkeit einer gemeinsamen Meta-Sprache.

Ich versuch das manchmal im Büro, wenn ich den code von jemand anders übernehme, beim Gespräch alles in Design Patterns auszudrücken. Zur Übung. Die sagen immer: "Axel, hör auf".  

[animate]

Genau das habe ich gemeint. Warum Factory in Anführungszeichen. Für mich ist das eine Factory. Oder warum soll sie das nicht sein?

naja, unter einer Factory verstehe ich halt eine Klasse, deren einzige Aufgabe es ist, Objekte rauszurücken.
Und die Klasse History hat in diesem Fall zusätzliche Aufgaben. Objekte zu erzeugen ist nur eine Nebenaufgabe.

Irgendwie gefällt mir diese Klasse sowieso nicht, so wie sie jetzt ist...

[animate]

solch eine Factory-Klasse habe ich übrigens absichtlich erstmal rausgelassen.
es kamen ja schon Gegenstimmen, als ich vorschlug, mehrere Klassen zu verwenden für diese Geschichte. Da wollte ich es für den Anfang mal etwas langsam angehen lassen.

[animate]

RTF habe ich vorerst nicht eingebaut. In der jetzigen Lösung schreibe ich die Werte in 1 Textfeld (Liste).

Die Unterscheidung würde ich in der "HistoryMain" machen in der "Private Sub writeHistory()".

ich habe mich falsch ausgedrückt.
wenn du da jetzt zusätzlich noch RTF-Histories schreiben willst - wo wirst du den zusätzlichen Programmcode hinschreiben?

[animate]

Das Geheimnis von Design Patterns ist, dass sie eigentlich nicht so geheimnisvoll sind und man schnell selber draufkommt. Wenn man sie kennt, hat man die Möglichkeit einer gemeinsamen Meta-Sprache.

Da hast du recht. Das Problem ist, dass diese Sprache hier schätzungsweise 97% nicht sprechen.
Aber natürlich ist es auch schwierig darüber zu diskutieren, ohne die Sprache zu kennen (ich hab gerade mal versucht, deinen Satz

wie man in HistoryEntry die Factory implementiert , um das Strategy-Pattern für die Subklassen zu implementieren

in neutraler Sprache zu formulieren - geht natürlich nicht.

Ich versuche, langsam vorzugehen...

[TMC]

OK, wie versprochen hier meine bisherige Umsetzung:

history_01.nsf (320KB)

Kann sich das hier u.a. bitte mal wer anschauen:


Weiß nicht; ist das noch objektorientiert, oder unsauber, diese Scripts auszulagern aus der Klasse?


Ach ja, noch kurze Erklärung zum Aufbau der angehängten DB:
* Das History-Feld ist in einer Teilmaske. Dort arbeite ich mit 2 Feldern. Grund: wegen Mehrfachwerten und Zeilenumbruch, sonst bringe ich die Darstellung nicht sauber hin.
* Die zu überwachenden Felder werden hier in den Global Declarations der Maske "MyForm01" definiert
* Anzahl History-Einträge wird noch nicht überwacht, muss ich noch einbauen

Bugs (gerade entdeckt - 16:09 Uhr):
- Wird das Dok nur gespeichert, aber nicht geschlossen, dann werden die InitialValues nicht aktualisiert.

[TMC]

RTF habe ich vorerst nicht eingebaut. In der jetzigen Lösung schreibe ich die Werte in 1 Textfeld (Liste).

Die Unterscheidung würde ich in der "HistoryMain" machen in der "Private Sub writeHistory()".

ich habe mich falsch ausgedrückt.
wenn du da jetzt zusätzlich noch RTF-Histories schreiben willst - wo wirst du den zusätzlichen Programmcode hinschreiben?

Hmm, ich würde wohl die HistoryEntry - Klasse duplizieren und anpassen ("HistoryEntryRTF") oder so.....
Perfekt ist das wohl allerdings nicht...

[eknori]

schöne Arbeit  

kleiner Bug:

Wird ein Document erstellt und über die "Diskette" gespeichert und anschließend über Speichern und schließen verlassen, gibt es zwei Einträge über die Neuanlage