Objektorientiertes Programmieren
Irgendwann hat man offenbar eingesehen, dass strukturiertes Programmieren alleine zu wenig ist. Man kann nicht alles in kleine Module aufteilen, die so in sich abgeschlossen wie mathematische Funktionen sind. Reale Anwendungen arbeiten mit einer mehr oder weniger großen Menge an Daten. Ich verstehe die objektorientierte Programmierweise als ein teilweises Aufheben des generellen Verbots von globalen Variablen: Funktionen, Prozeduren und deren Daten werden zu "Objekten" zusammengefasst, sodass alle Datenvariablen des Objekts für den gesamten Programmcode des Objekts "global" sind und unkompliziert verwendet werden können (man braucht nicht bei jedem Funktions- oder Prozeduraufruf alle Daten mitübergeben). Das halte ich für sehr sinnvoll!
Eigenschaften
- Objekte bilden einen Stammbaum: Jedes "Kind" ist ein Spezialfall oder eine Erweiterung seines Mutterobjekts. Parade-
Lehrbuchbeispiel sind die Objekte "Punkt", "Kreis" und "Ellipse". - Ein Programm, das mit einem Punkt-
Objekt arbeiten kann, kann automatisch auch mit einem Kreis- und Ellipse- Objekt arbeiten, denn jedes Kind kann alles, was seine Mutter kann (und ggf. noch mehr). Damit spart man Fallunterscheidungen und nachträgliche Anpassungen, wenn weitere Unter- Objekte hinzukommen.
Kritik
- Anfang der 1990er gab es einen Hype um objektorientiertes Programmieren. Man glaubte, alle Probleme der Softwareentwicklung damit lösen zu können. Tatsächlich hat es sich inbesondere nicht als Allheilmittel zum Schreiben von wiederverwendbaren Programmteilen erwiesen. Selbst wenn mir z. B. der Bildbetrachter IrfanView im Quelltext vorläge und wenn er objektorientiert wäre, könnte ich ihn nicht ohne Weiteres um eigene Funktionen erweitern.
- In der Praxis ist es relativ selten, dass man die Objekte, die man benötigt, zu Stammbäumen anordnen und das Konzept der "Vererbung" nutzen kann. – Alternative: innerhalb eines Objekts andere Objekte zu den "Daten" des Objekts hinzufügen und intern verwenden (Delegation).
- Objekt-
Stammbäume sind wacklig: Eine Änderung bei der Mutter kann beim Kind zu unvorhersehbaren Fehlern führen. – Vgl. Abschnitt "The Problem with Implementation Inheritance" in The Component Object Model: A Technical Overview - Auf die Daten eines Objekts sollte nicht direkt zugegriffen werden, damit die interne Datenstruktur später jederzeit geändert werden kann. Man braucht daher für jede Objekt-
Variable, die von außen sichtbar sein soll, eine Zugriffsfunktion und -prozedur. Das ist leider in den meisten Programmiersprachen ziemlich mühsam. Ich fände es besser, wenn der Zugriff von außen immer wie der direkte Zugriff aussieht, obwohl der Zugriff bei Bedarf unsichtbar über eine Zugriffsfunktion bzw. -prozedur geht. - Wenn man alles mit Objekten machen will, muss man dort, wo es in Wirklichkeit keine Objekte gibt, welche erfinden – umso mehr, wenn alle Objekte klein und übersichtlich sein sollen, denn reale Objekte (wie z. B. ein Telefon oder ein Wertpapier) sind oft komplex. Das Verstehen und Verwenden dieser vielen, zum Teil "künstlichen" Objekte ist dann meiner Meinung nach oft nicht mehr so einfach, also keine Verbesserung gegenüber herkömmlicher Programmierweise.
Vergleich
Du brauchst ein Messer. Daher öffnest du die Besteckschublade und nimmst eines raus. Das wäre normale Programmierung. Objektorientiert sieht es anders aus:
Du kommst nicht einmal mehr in deine eigene Wohnung, sondern der AnfrageManager fragt dich an der Wohnungstür, was du willst. Deinen Wunsch nach einem Messer gibt er an den AnfrageVerteiler weiter. Der weiß, welche Anfragen wo hingehören. In deinem Fall ist es der BesteckManager. Der wiederum kontaktiert den SpitzbesteckManager. "Spitzbesteck" sind alle spitzen Bestecke, also Gabeln und Messer. (Beim objektorientierten Programmieren trifft man oft auf neue, kreative Bezeichnungen.) Jetzt fordert der SpitzbesteckManager vom MesserFinder ein Messer an. Wenn er eines findet, geht es durch alle Hände zurück bis zu dir.
Anhänger des objektorientierten Programmierens gefallen solche Konzepte, wo jedes Objekt nur eine kleine, genau definierte Aufgabe hat und nicht viel von seinem restlichen Umfeld wissen muss. Aber wehe, du willst aufeinmal nicht nur ein Messer, sondern gleichzeitig auch wissen, wie viele Messer noch übrig sind. Dann müssen all die schönen, sauber getrennten Objekte geändert werden. Zugriffe auf die Informationen in entlegenen Objekten bedeuten beim objektorientierten Programmieren oft erheblichen Aufwand. Das ist der Preis für das Zerteilen der Wirklichkeit in kleine Objekte.
Alternativen
- Interfaces
- komponentenorientiertes Programmieren
