Wiederkehrende Abläufe können a) mit einem Namen belegt und b) in Details aufgeteilt werden. Beispiel
|
1 2 3 4 5 6 7 8 9 |
verbingeDenTag ( m vomTyp Mensch ) { aufstehen ( m ) fruehstuecken ( m ) arbeiten ( m ) macheMittag ( m ) arbeiten ( m ) feierabend ( m ) nachtruhe ( m ) } |
Das ist die Grundidee prozeduraler Programmierung. Problem: Es gibt “Eulen” und “Lerchen” und “Eulenlerchen” und “Lercheneulen” und und und. Die Prozedur verbingeDenTag ist nicht für alle Typen angemessen. Deshalb trumpft Objektorientierte Programmierung: Frühaufsteher sind Menschen und Spätzubettgeher sind Menschen und und und. Ihre Gemeinsamkeiten werden in der Klasse Mensch untergebracht. Ihre Besonderheiten in den erbenden Spezialklassen Frühaufsteher, Spätzubettgeher usw.
Mit der Objektorientierten Programmierung einher geht die Aufgabe, ein System zu analysieren, um es abbilden zu können. Analyse ist untrennbar verbunden mit dem Wissen um das zu analysierende Thema. Aber auch das umfassenste Wissen garantiert nicht, dass die Analyse treffend ist.
Tür auf …
Beispiel aus dem “echten Leben” sei das Thema “Tür”. Jeder von uns kennt Türen. Eine Tür kann geöffnet werden. Eine Klasse Tür wird also eine Methode öffnen bekommen. Oder? Eine Tür kann sich nicht selbst öffnen, das widerspricht den Gesetzen der Physik. Ausser Tür brauchen wir wohl auch eine Klasse TürÖffner? Ja. Aber nur dann, wenn der Türöffner eine Rolle spielt – sonst können wir den wegabstrahieren.
Tür zu …
Eine Klassenstruktur wird schnell kompliziert. Wohl dem, der es einfach hat. Für alle anderen gibt es Design Patterns. Das sind Muster, die erklären, wie Klassen zusammenarbeiten können, ohne dass der Programmierer schlaflose Nächte hat. Die immer wiederkehrenden Themen “lose Kopplung”, “innerer Zusammenhalt” usw.
Dritter sein.
Eine Grundidee von Objektorientierter Programmierung ist, dass Daten und ihre Verarbeitungsmethoden zusammengefasst sind. Aber das ist manchmal genauso unflexibel und unpassend wie das prozedurale Beispiel s.o.! Das Design Pattern “Delegation” hilft, Methoden austauschbar zu machen. Das Objekt weiss nicht, wie es etwas tun soll, aber es bekommt ein anderes Objekt, das den Job erledigen kann.
Stell’ Dir vor, Du hast kein KFZ. Du bekommst ein Taxi, um von A nach B zu kommen. Und Du bekommst einen 40-Tonner für den Umzug. Der eigene Wagen ist nicht so flexibel.
Von dieser Idee ausgehend fällt es mir leicht einzusehen, warum Service-Orientierte Architekturen und Komponenten-Frameworks eine a) brauchbare und b) flexible Sache sind. Die Plugin-Architektur hat diese Welten geöffnet. Ich bastel gerade an einer OSGi-Anwendung, die ich hier hoffentlich bald vorstellen kann.