Domino 9 und frühere Versionen > Entwicklung

Wie kann ich eine Klasse sinnvoll aufbauen ?

<< < (30/41) > >>

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":


--- Zitat von: Thomas Völk am 26.06.04 - 16:57:15 ---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.
--- Ende Zitat ---


--- Zitat von: Thomas Völk am 26.06.04 - 19:58:56 ---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...)
--- Ende Zitat ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete