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
