Hilfe bei Klassenmodell

[gstueb]

Hallo,

ich bin gerade dabei ein Wiedervorlage-System in Notes zu programmieren. Es soll unter anderem sehr flexible periodische Wiedervorlagen ermöglichen (täglich, wöchentlich, monatlich, alle x Wochen / Monate).

Bei klassischer prozeduraler Herangehensweise hätte ich da vermutlich auch wenig Fragen, ich möchte das ganze aber vor allem zu eigenen Lernzwecken mal objektorientiert aufziehen. Ich habe in Grundzügen zwar schon objektorientiert gearbeitet, aber z.B. noch nie mit einem richtigen Klassenmodell und vererbten Klassen.

Meine Grundidee ist nun, eine Klasse "Wiedervorlage" (WVL) zu erstellen

Code

dim w as new wvl(doc)

so dass ich über das Objekt w dann die Methoden und Eigenschaften auf-/abrufen kann. Eine klassische Eigenschaft wäre z.B. ob die WVL aktiv ist, eine klassische und wichtige Methode gerade für Wiederkehrende Termine wäre die Methode

Code

w.naechster(datumswert)

Die Methode soll "datumswert" auf den nächsten wiederkehrenden Termin ab "datumswert" setzen.

Meine einfachen und meine wiederkehrenden Wiedervorlagen (täglich, wöchentlich, monatlich, freie liste) haben ja nun viele Eigenschaften und Methoden gemeinsam, nur bestimmte Punkte (z.B. die Berechung des nächsten wiederkehrenden Termines) weichen voneinander ab. Deswegen war meine Idee, eine Basisklasse "WVL" zu erstellen und für die speziellen wiederkehrenden WVL Klassen zu erstellen, die von WVL erben:

Code

Class WVL (BASISKLASSE)
	Eigenschaften:
		Bearbeitugnsberechtigt
		Art der WVL
		Wiederholen alle
		Beginn am
		Ende Am
		Bestätigung
		Aktiv/Inaktiv
                etc.

	Methoden
		SetzeAktiv
		SetzeInaktiv
		SetzeErledigt
		naechster(Datum)


Class WVL_Einfach as WVL
	Methoden
		naechster(Datum)

Class WVL_Taeglich as WVL
	Methoden
		naechster(Datum)

Class WVL_Monatlich as WVL
	Methoden
		naechster(Datum)

Mein Problem betrifft nun die Deklaration der Objekte. Ich müsste nun ja einen Code einfügen

Code

select case doc.Art(0)
		case "e": dim t as new WVL_Einfach(doc)
		case "t": dim t as new WVL_Taeglich(doc)
		case "m": dim t as new WVL_Monatlich(doc)
end select

Aber ich möchte außerhalb des Objektes nicht auf irgendwelche Werte des übergebenen Notes-Dokumentes (doc.Art(0)) zugreifen. Eigentlich hätte ich gerne alles mit den Aufruf

Code

dim obWvl as new wvl(doc)

erledigt. Abhängig von der Art der Wiedervorlage soll das Objekt obWvl dann z.B. unterschiedliche rechnende Methoden "naechster" haben. Aber wie kann ich so etwas innerhalb einer Klasse dynamisch machen?

Ich hoffe ihr könnt mir bei meinem Problem halbwegs folgen.

Danke & Grüße,
Gregor

[Peter Klett]

Ich habe noch nie eine Klasse in Notes geschrieben, bin aber gerade dabei, mich in einer anderen Sprache in die objektorientierte Welt einzuarbeiten. Meine Antwort ließe sich in der Sprache so realisieren, wie ich das beschreibe und ich gehe davon aus, dass es in LotusScript auch so möglich ist.

Ich würde nicht mit mehreren Klassen arbeiten, denn schließlich ist Dein Objekt, mit dem Du später arbeiten willst, eine Wiedervorlage. Dein Unwohlsein, die Wahl der Klasse anhand der Art des Dokuments festzumachen, teile ich. Du könntest natürlich alle Arten von Wiedervorlagen in der Funktion Naechster abfackeln, dadurch wird die relativ lang. Wenn Du kompaktere Funktionen vorziehst, würde ich es sinngemäß so machen

Klasse WVL
    Eigenschaften
        ...

    Öffentliche Methoden
        ...
        Naechster

    Private Methoden
        NaechsterEinfach
        NaechsterWoechentlich
        NaechsterMonatlich
        ...

In der Funktion Naechster rufst Du mittels des von Dir genannten Select Case die privaten Methoden auf. Als Ergebnis hast Du dann eine Klasse, bei der du (neben den anderen öffentlichen Methoden) nur die Methode Naechster aufrufen kannst. Kommt eine neue Art dazu, nimmst Du eine neue private Funktion auf und erweiterst die öffentliche. Vererbung halte ich für solch einen Fall strukturell für übertrieben.

[eknori]

Ich würde es strukturell auch so aufbauen

Klasse WVL
    Eigenschaften
        ...

    Öffentliche Methoden
        ...
        Naechster

    Private Methoden
        NaechsterEinfach
        NaechsterWoechentlich
        NaechsterMonatlich
        ...

Welche der Naechster* methoden zur Anwendung kommt, würde ich über eine property festlegen. Ich denke, daß ist sauberer strukturiert, als wenn man im Constructor das dcoument übergibt und dann die properties innerhalb der Klasse ermittelt.

Dim wvl as new WVL();
wvl.setDocument(doc)
wvl.setTypeNext(doc.WhateverItemIsInvolved)
wvl.setNext()

[flaite]

Es kann sein, dass ich hier etwas föllig valsch verstehe... und es wär nicht das erste Mal, aber:

Mein Problem betrifft nun die Deklaration der Objekte. Ich müsste nun ja einen Code einfügen

Code

select case doc.Art(0)
		case "e": dim t as new WVL_Einfach(doc)
		case "t": dim t as new WVL_Taeglich(doc)
		case "m": dim t as new WVL_Monatlich(doc)
end select

Ich würd sagen, das Problem betrifft eher die Initialisierung des richtigen Objekts in Abhängigkeit von den 3 cases in den Code nicht die Deklaration, oder?

In LotusScript fehlen static Methoden, die es etwa in Java oder C# gibt.

Da könnte man in der abstrakten Oberklasse WVL - kein guter Name, nenn die besser Wiedervorlage - sowas schreiben wie

Code

public static Wiedervorlage getInstance(char kuerzel, Document doc) {
  switch (kuerzel) {
  case 'e' : return new Wiedervorlage_Einfach(doc); 
  case 't' : return new Wiedervorlage_Taeglich(doc);
  case 'm' : return new Wiedervorlage_Monatlich(doc); 
  default : throw new UnsuportedOperationException("Dieser Parameter ist hier nicht vorgesehen."); 
}
}

Weiss nicht mal, ob das so kompiliert.  
Aber so die Art.

Man könnte vermutlich mühsam in LotusScript statische Methoden nachprogrammieren. Machs besser nicht. Hier übrigens ein Versuch für statische Variablen.    

http://opendom.blogspot.de/2007/03/static-properties-methods-in.html

Viel bringt das übrigens auch nicht. Die Vorteile von OO gegenüber guter strukturierter Programmierung sind für so Einzelfälle am Ende auch nicht so gewaltig. Die Summe machts halt. Und es ist auch sehr einfach über OO auf falsche Fährten gelockt zu werden.

Peter Klett verzichtet auf Vererbung. Gefällt mir gut. So wird die Frage welche Methode denn nun aufgerufen wird in der Klasse gekapselt und darum gehts letztlich. Den Code ausserhalb der Klasse von der in der Klasse abgefrühstückten Business-Logik freizuhalten. Du MUSST ja nicht jedes Feature von OO einsetzen sondern Du schreibst eine Anwendung!
Ulrichs Vorschlag ist eine Variante, die je nach Anwendungsfall besser, genausogut oder schlechter ist. Da ist der Entscheiungsparameter, welche Logik nun aufgerufen ein Property der Klasse und kein an die Methode naechste übergebener Parameter. Wenn es mehrere Methoden mit Fallunterscheidungen nach Einfach, Woechentlich, Monatlich gibt, ist das vielleicht die bessere Lösung. Kommt aber auf den Kontext drauf an.

Eine unterhaltsame und aus meiner Sicht auch realistische Art sich über OO zu informieren sind aus meiner Sicht die Filme von Robert Martin:
http://www.cleancoders.com/

[eknori]

Also kann man im Prinzip sagen: Mach es so, wie du denkst, daß es richtig ist. Es gibt nicht den einen, und nur diesen einen Weg.
Hauptsache, es funktioniert und ist halbwegs übersichtlich; auch für einen Dritten, der über den Code stolpert

[flaite]

- OO nicht zu ernst nehmen
- fest an die Beschränktheit von anderen und Dir selber glauben.
- code zwischendurch immer kritisch hinterfragen, gerade wenn man für einen neue OO-Features einbaut.

[gstueb]

Erstmal vielen Dank für die ganzen Tipps.

Tatsächlich war ich die ganze Zeit so auf "Vererbung" fixiert, dass ich die von Peter vorgeschlagene Lösung mit den privaten Methoden gar nicht mehr gedacht hat. Wie war das mit dem Wald und den Bäumen?

Ich habe nicht vor, meine Wiedervorlage-Klasse in anderen Anwendungen zu verwenden, die ist zu speziell. Insofern gefällt mir die Lösung von Peter in diesem Fall besser als die von Ulrich, denn dann habe ich mit den Items nur innerhalb meiner Klasse zu tun und nicht auch noch außerhalb.

Bei einer Klasse, die ich in anderen Anwendungen wieder verwenden wollte, würde ich hingegen Ulrichs Lösung bevorzugen (und innerhalb der Klasse dann natürlich gar keine Items ansprechen).

Ich denke ich werde meine Klasse "WiedervorlageDoc" nennen, dann wird das auch klarer.

Ansonsten habt ihr schon recht: Hauptsache der Code funktioniert und er ist übersichtlich. Ich bin aber in der komfortablen Situation, dass ich keinerlei Zeitdruck habe. Diese Wiedervorlage ist keine Auftragsarbeit, sie wäre nur ein "nice to have" in unserem Unternehmen. Ob die jetzt in 3 Wochen oder in 3 Monaten fertig wird, spielt keine Rolle. Insofern nehme ich mir da gerne Zeit und teste auch mal neue Wege.

@Pitiyankee: Ja, ich meinte natürlich die Initialisierung der Objekte, nicht die Deklaration. Danke auch für die Links, ich schau mir das mal an.