Lotus Notes / Domino Sonstiges > Projekt Bereich
Gang Of Four (GoF) Design Patterns für LotusScript on OO nachprogrammieren?
animate:
--- Zitat von: Marinero Atlántico am 04.01.05 - 13:15:23 ---Welche konkreten weiteren Anforderungen können an diese Klassen gestellt werden (z.B. bei Wiederverwendung in einem konkreten anderen Kontext). Verbesserungsvorschläge?
--- Ende Zitat ---
Also nix konkretes und nix was du nicht wüsstest, aber evtl. musst du mal deine Konfiguration woanders herholen oder/und dein Log woanders hinschreiben.
Verbesserungsvorschlag? Da das hier ja auch etwas eine Lehrveranstaltung ist, denke ich dass sich die, die was lernen möchten, dazu Gedanken machen und die Gedanken veröffentlichen sollten. ;D
animate:
--- Zitat von: Marinero Atlántico am 04.01.05 - 13:15:23 ---Welche konkreten weiteren Anforderungen können an diese Klassen gestellt werden (z.B. bei Wiederverwendung in einem konkreten anderen Kontext). Verbesserungsvorschläge?
--- Ende Zitat ---
Hmm, vielleicht doch besser was konkretes. Der Benutzer soll in der Datenbank konfigurieren können, ob er in eine DB oder in ein Textfile loggen will. Außerdem sind in Zukunft noch weitere Log-Formate geplant.
TMC:
--- Zitat von: Marinero Atlántico am 04.01.05 - 13:15:23 ---Verbesserungsvorschläge?
--- Ende Zitat ---
OK, wir haben hier mehrere Enten, die nach und nach ein paar Dinge machen sollen wie eben quacken oder schwimmen.
Beim Blick auf den Code fällt auf, dass
[*]Set myRHDuck = New RedHeadDuck()
[*]Set myMDuck = New MallardDuck()
[/list]
jeweils über die ConfigDocWrapper - Klasse das Setup-Dok auslesen lässt.
Also View suchen, Dokument finden, Felder auslesen, etc.
Wenn man jetzt aber nun mit vielleicht 100 verschiedenen Enten zu tun hat, ist das performancemäßig wohl nicht das beste.
<Offtopic>
Im Code steht öfter If Bedingung Then Error 999.
Lt Help sollten sich user-defined Error in der Range zw. 1000 und 1999 befinden. Ist aber jetzt wirklich eine absolute Kleinigkeit, ist mir halt nur aufgefallen ;-)
</Offtopic>
Matthias
Marinero Atlántico:
Dies sind 2 sehr gute Punkte.
Thomas hat auf die coupling Problematik aufmerksam gemacht, auf die ich noch weiter eingehen werde. Jedes der Objekte kümmert sich um sein Spezialgebiet (Logging und Konfigurationsdokument auslesen) und - was Sinn macht - sie kooperieren miteinander.
Trotzdem ist diese Kooperation irgendwie zu fest verdrahtet. V.a. benötigt man für die Konfigurations-Klasse in der Datenbank zwingend eine Ansicht "Configuration", was auch eine ziemlich mutige Voraussetzung ist (vielleicht existiert in einer bestehenden Datenbank schon eine Ansicht mit diesem Namen).
Die Klassen aber flexibler zu machen, hat einen Preis. Nämlich, dass die Klassen in der Benutzung ein bischen komplizierter werden. Dazu später mehr. Es wird in moderner OO-Design Literatur immer wieder darauf hingewiesen, dass man nicht Flexibilität um ihrer selbst willen einfügen soll, nur weil man das programmieren kann. Die Flexibilität hat immer den Preis, dass die Klassen etwas schwerer zu benutzen sind. Das ist also ein Abwägen nach dem Gesichtspunkt, wo Wandel der Requirements zu erwarten ist. Dort ist es dann sinnvoll, Flexibilität für etwas mehr Komplexität "einzukaufen".
Mathias sein Punkt war nicht unbedingt zu erwarten und deshalb sehr gut. Ich hab das aber auch so gesehen, als ich die Klassen programmiert habe. In anderen Programmierumgebungen wie z.B. C# würde man solche für alle Enten wiederverwendbare Objekte (nicht Klassen) entweder in einer static-Variable halten oder über eine Singleton-Factory erstellen (wird noch erklärt und die braucht auch dieses static-feature). Ich mach mal ein Java Beispiel mit Lazy Static Initialisierung, damit es klar wird, wie static eigentlich funktioniert. Ich find das durch solche Vergleiche LS OO klarer und nicht unklarer wird.
Wie man Objekte shareable zwischen mehreren Client-Objekten (in diesem Fall Enten) macht, halte ich z.Zt. für ein Problem, dass irgendwie gelöst werden muss. Es ist in der Tat eine Ressourcenverschwendung, dort jedesmal ein Objekt mit den einzelnen Properties zu initialisieren!!!
Eine Herausgeberin des Buches, von dem dieser Thread inspiriert ist (Head First Design Patterns), wird übrigens heftig von Domino Bloggern gelobhudelt. Sie ist übrigens auch Mitbegründerin... :-X
http://hostit1.connectria.com/twduff/home.nsf/plinks/TDUF-68B2TR
Mark³:
1. super interessante Artikelliste (Thread), ich werde am Ball bleiben
2. Ich finde Design Pattern und echte OO-Programmierung sehr interessant, habe bisher aber noch keine Notesentwicklung gesehen, wo sich das wirklich auszahlt. Zumal Klassen im Notes-Designer grundsätzlich total unübersichtlich sind, da sie nicht übersichtlich dargestellt werden. Benutzt ihr im echten Leben auch sowas in LS oder ist das nur Spielkram, weil ihr aus der Java bzw. C++-Ecke stammt?
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln