Lotus Notes / Domino Sonstiges > Tipps und Tricks

Lesbare Bedingungen in LotusScript

<< < (2/3) > >>

Marinero Atlántico:
Halte das auch für eine gute Idee.
Lange verschachtelte ifs sind ein Problem.

am Rande:
Ein ziemlich großer Teil der GoF Design Pattern in OO vermeiden gerade das.
Für jeden Fall gibt es eine eigene Klasse. Diese Klassen haben ein gemeinsames Interface (in Java: gemeinsame abstrakte Klasse oder Java-Interface).
Gibt es allen Klassen gemeinsame Aktionen tut man die eben in die abstrakte Klasse. 
Strategy-Pattern, Command Pattern oder Template method.
Benutzt man Reflection braucht man gar kein if-then mehr.

Könntest du hier auch mit LotusScript benutzen, wobei es da leider keine abstrakten Klassen gibt.

koehlerbv:
Die Vereinfachung von verschachtelten Abfragen halte ich auch für ein extrem wichtiges Thema. Neben der Nachvollziehbarkeit des Codes sind dessen Wartbarkeit und Fehlersicherheit entscheidende Faktoren.

Ich setze dabei folgende Verfahren ein:
- Vereinfachung der Lesbarkeit, wie hier schön von Christian beschrieben (DANKE im Namen der Forumsnutzer !)
- Aufgliederung der Abfragen - insofern diese auf sehr wenige Zustände zurückzuführen sind, dann wird das Ergebnis immer in einer Zielvariablen geführt (ganz einfaches Beispiel: Ermittlung "muss gespeichert werden ?" Ergebnis kann nur "ja" oder "nein" sein. Nur das "jo, speichern !" wird fortgeschrieben).
- M.E. nur scheinbar üble Konstrukte wie GOTOs oder END-statements, bevor es ganz unübersichtlich wird.

Eine interessante Debatte  ;)

Bernhard

Semeaphoros:
Ja, Axel, Du führst noch ein wenig weiter, was ich oben schon angedacht habe. Das Fehlen von abstrakten Klassen in LS ist schade, aber nicht wirklich ein Showstopper, unbedingt nötig sind die nicht (nur ein Hilfsmittel für die eigene Ordnung :) )

Marinero Atlántico:

--- Zitat von: cgorni am 08.03.05 - 13:01:16 ---In dem Projekt werden Design Elemente mit verschiendenen Sprachen über DXL in Datenbanken importiert/aktiviert/kontrolliert:

--- Ende Zitat ---
noch ein Dribbling an der Außenlinie:
Wir haben in einem Projekt, wo ich nicht beteiligt bin, auch so einen Fall wo ein komplexerer xml-Baum z.Zt. pro node verarbeitet wird.
Das kann sehr komplex werden, auch wenn man das relativ smart organisiert. 
Ich glaube ja persönlich, dass XMLDataBinding in vielen Fällen definitiv Sinn macht (http://www.rpbourret.com/xml/XMLDataBinding.htm).
Ist hoch auf meiner research, prey & self-exploitation agenda.  ;D 

@Jens: Vorteil von abstrakten Klassen:
- klare Kommunikation, v.a. wenn andere die Klasse nutzen (Übersicht ist wichtig). Man weiss direkt, welche Methoden gemeinsam sind und welche überschrieben_werden_müssen. Btw. werde ich langsam zum Freund des intensiven Einsatzes des Schlüsselwortes final. d.h. Methoden sind i.m.m.e.r. entweder abstract (müssen überschrieben werden) oder final (dürfen nicht überschrieben werden).

- IDEs generieren bei einer Vererbung von einer abstrakten Klasse automatisch stubs der abstrakten Methoden, so dass der Entwickler direkt weiss, welche Methoden überschrieben werden sollen.

In meiner Praxis sind abstrakte Klassen überaus wichtig.

Semeaphoros:
Axel, völlig einverstanden, dass das praktisch ist, allerdings bringt uns die LS-IDE leider schon die Basisunterstützung nicht, also bekommen wir auch keine Stubs von abstrakten Methoden ...... :( ..... leider

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete