Lotus Notes / Domino Sonstiges > Projekt Bereich

Gang Of Four (GoF) Design Patterns für LotusScript on OO nachprogrammieren?

<< < (4/10) > >>

Semeaphoros:

--- Zitat von: Marinero Atlántico am 20.12.04 - 10:03:10 ---Jens Augustiny (Semaphoros) hatte hier teilweise für mich Anzeichen einer Argumentationslinie, dass OO eigentlich ganz einfach und natürlich ist und das man es mit LotusScript Kenntnissen eigentlich schon "kann".

--- Ende Zitat ---

Da hast Du mich aber wirklich nicht verstanden. Meine Argumentation ist vor allem, das Nehmen von Angst gegenüber OO, welche ich bei vielen LS-Codern/Designern feststellen kann. Da Notes/Domino selber OOrientiert ist, ist dem LS-Gewandten die ganze Sache nicht fremd, und mit etwas Auseinandersetzung mit dem Domino Objekt Modell lässt sich sehr gut OO-Praktiken aus den Domino-Gegebenheiten ableiten. Sprich, der LS-Gewandte muss nicht bei Null anfangen, wenn man ihm den richtigen Weg zeigt. Mehr ist in meinen Aussagen nicht drin und meine diesbezüglichen Vorträgen (der nächste an der Lotusphere 2005 nächsten Januar) zielen genau darauf hin, dem LS-Programmierer hier Hilfestellung auf dem Weg zu OO zu geben. OO liegt nicht primär in LS, sondern im Produkt Notes/Domino, man muss den Leuten vor allem zeigen, wo sie das finden, und viel wichtiger: es ist ein Umstellen der Denkweise. Zentrale Aussage in meinem Vortrag nächsten Monat: ein OO-Projekt funktioniert nur, wenn man durchgängig von der Analyse bis zur Realisation in OO-Mustern denkt, dieses Denken muss her, die Grundlagen und Muster kann Domino/Notes selber liefern (das ist wohld as, was Du als "natürlich" interpretiert hast). IBM selber vergisst, die gegenwärtigen "treuen" Entwickler dort abzuholen, wo sie jetzt stehen und damit sehen all diese Sachen, in die sie die Lotus-Leute bewegen wollen, für diese wie völliges Neuland aus, kein Wunder, dass sich der durchschnittliche Lotus-Entwickler dagegen wehrt, alles Neue wird meistens erst einmal abgelehnt.

Marinero Atlántico:
Ist für meinen Geschmack zu "yellow".
Man braucht nur auf das "brilliant" Domino Objekt Modell zu schauen, einen "konsequenten" OO Analyse/Design-Prozess zu haben und alles wird gut...
Ich hab hier ein Projekt übernommen mit OO-in-LS-code, wo ich nur sagen kann, dass die brilliant geniuses, die das verzapft haben, deutlich zu wenig und nicht zu viel Angst vor OO haben.
Werde diesen GoF Thread weitermachen to teach you fear, angst and terror.  ;D
 

Semeaphoros:
Eben, Axel, wenn Du in meinem Post zwischen den Zeilen lesen würdest, genau so verliert man die Leute, wenn man sie nicht dort abholt, wo sie sind. Sprich, wenn die Leute gelb sind, dann musst Du sie gelb abholen und mit der Zeit dann halt umfärben. Sonst laufen sie davon.

Marinero Atlántico:
Das folgende ist keine Wahrheit, sondern ein Internet Thread. Für Wahrheiten, bitte Bücher kaufen.

Warum gibt es OO?
Hauptgrund ist wohl die leichtere Anpassung des codes an sich wandelnde Anforderungen. Bei sich ständig wandelnden Anforderungen ist es einfach zu zeitaufwendig, in mehr oder wenig gut funktional dekomponierten Funktionen mit Tonnen von if-thens nach der entscheidenden Stelle zu suchen, wo man was ändern muß.
Man glaubt deshalb, dass es übersichtlicher ist Programmlogik in sogenannte Klassen zu packen. Klassen sind Blaupausen für Objekte. Klassen haben Methoden und mehr oder weniger temporäre Variablen (die nennt man Eigenschaften).
Klassen behandeln am besten genau einen Aufgabenbereich der Programmlogik. Sie kappseln sozusagen diesen Aufgabenbereich. Wenn sich die Anforderungen an diesen Aufgabenbereich ändern, muß man nur die Klasse ändern und nicht tagelang im code nach den entsprechenden Stellen suchen. Es kann natürlich auch vorkommen, dass eine Änderung der Anforderung in mehreren Klassen code-Änderungen erfordert. Das läßt sich nicht immer vermeiden, ist aber nicht so gut.

In der Frühphase von OO (frühe 90er Jahre) gab es alle möglichen einfachen Argumente für OO, von denen aber viele nicht so toll sind.
Heute glaubt man, dass es irgendwie scheissendreck-kompliziert aber händelbar ist und Sinn macht. Und das man besser wird, je tiefer man sich mit dem Zeugs einlässt.
Wichtig sind v.a. die sogenannten GoF Design Patterns, die gute OO-Design-Praxis in vereinfachten Beispielen "verdichten".
Die Design Patterns sollen eine Hilfe sein, um die sogenannten OO-Prinzipien zu erfüllen.
Die OO-Prinzipien sind:
- Kappsele das, was sich ändern wird (um auf Änderungen in den Anforderungen an einer Stelle zu reagieren)
- Komposition ist total oft besser als Vererbung (was Komposition ist, wird später noch klar)
- Programmiere gegen Interfaces und nicht gegen Implementierungen (was das ist, wird später noch klar)
- strebe nach lose gekoppelten Designs zwischen interagierenden Objekten (was das ist, wird später noch klar) 
- Klassen sollten offen sein für Erweiterungen, aber geschlossen für Veränderungen (man sollte möglichst nicht in bestehenden code rumhacken. Um Funktionalität zu erweitern/ggbfls zu verändern sollte es möglich sein, einfach eine neue Klasse hinzuzufügen).
- Mach deine Klassen besser immer nur von Abstraktionen abhängig und nicht von konkreten Klassen (was das ist, wird später noch klar)
- Sprech nur zu deinen Freunden (also besser nicht barocke Gebilde der Art wie ship.getRoomNumber(room.getNumber()).getRenterId().getName(); )
- Don't call us, we'll call you. (wenn du deinen LotusScript Bob in sowas wie querySave ablässt, dann wird das ja auch nicht aus der Maske explizit aufgerufen, sondern der User speichert das Dokument und dann wird der code im QuerySave von Notes automatisch aufgerufen. So ungefähr, wird aber noch genauer erläutert).
- Eine Klasse soll nur einen Grund haben, um verändert werden zu müssen (geht wieder in die Richtung, dass möglichst wenig an bestehenden code geändert werden soll, wenn sich die Anforderungen ändern).

In der Folge sollen hier die sogenannten GoF Patterns als Lotus Script implementiert werden. Dabei soll gezeigt werden, inwieweit diese total berühmten GoF Patterns die oben genannten Anforderungen erfüllen und was an diesen eigentlich so toll ist.

Gruß Axel

Marinero Atlántico:
Kappseln, Kompisition, Interfaces, Implementierung, lose gekoppelt, interagierende Objekte, Abstraktionen, GoF Patterns.
Lots of confusing stuff  ???
Tonnen von Fremdwörtern  ;D

In der Folge versuche ich die garantiert sinnfreien Beispiel aus HF Design Patterns von Java nach Lotus Script zu portieren.
Ich versuche dann zu beschreiben, wie sich diese komischen Design Pattern mit den noch seltsameren OO Prinzipien (s.o.) in Verbindung stehen.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete