Objekt Orientierung

Objekt Orientierung stellt den Gipfel einer Fehlentwicklung dar, welche die Informatik als Ganzes in ihrer Weiterentwicklung blockiert und die früher oder später ausgeräumt werden muss.

Objekt Orientierung schränkt die strukturelle Freiheit des Lösungsraums auf eine drastische Weise ein. Es werden für Lösungen nur noch Strukturen einer ganz bestimmten Art zugelassen.

Mit welchem Recht?

Wer will den Beweis führen, dass gerade diese Art von Lösungsstrukturen wirklich die Bessere ist?

Hinter dieser Einschränkung steht die Angst vor kreativer Freiheit – einer Freiheit, die man sich selbst nicht zutraut. Diese Art des Vorgehens ist eine Beleidigung für den menschlichen Geist mit seinen unendlichen Möglichkeiten und gleichzeitig eine krasse Art von Bevormundung von Softwareentwicklern durch die Schöpfer solcher Methoden. Das erinnert mich sehr an meine Kindheit in der DDR, als auch nur bestimmte Arten des Denkens zugelassen waren.

Objekt Orientierung ist ungefähr so, als würde man einem Maler sagen, „Du darfst in deinen Bildern nur noch Kreise als Grundelemente verwenden. Striche, Quadrate, Rechtecke oder Kleckse sind verboten.“ Damit malt der Maler vielleicht zwei oder drei nette Bildchen, aber dann fängt es an, ihn anzuöden.

Warum bemerken Softwareentwickler nicht, welcher Möglichkeiten sie sich durch Objekt Orientierung berauben?

Weil sie ihren Job nicht als kreatives, schöpferisches Werk sehen, sondern als Produktionsprozess, der immer mehr reglementiert und automatisiert werden muss.

Wie weit muss diese Entwicklung eigentlich noch gehen, damit eine signifikante Anzahl von Softwareentwicklern merkt, welche Umwege da gegangen werden?

Für mich ist es ein absolutes Rätsel, warum nicht mehr Entwickler innerlich spüren können, welchen unsäglichen Zwang sie ihrem Geist antun, wenn sie auf diese Weise entwickeln.

• Objekt Orientierung wird unter dem Nimbus von Wissenschaftlichkeit mit lauter unbewiesenen Behauptungen gepusht (Wiederverwendbarkeit und blablabla), die praktisch gar nicht erzielt werden, die auch gar nicht gebraucht werden und die aber gut und richtig klingen
• Objekt Orientierung hat sämtliche Merkmale einer Ideologie weil es sich über eine Art Massendruck verbreitet. "Wer nicht von gestern ist und sämtliche Entwicklungen verschlafen hat, der entwickelt eben Objekt orientiert, das weiß man ja wohl."
• Mir selbst ging es lange so, dass ich dachte, ich sei zu dumm für das Thema. Um das nicht zugeben zu müssen, tat ich immer schön so, als sei mir alles klar und machte weiter mit.
• Und man kann in Objekt Orientierung niemals wirklich durchblicken. Denn im Gegensatz zum Prinzip geistiger Entkopplung, das zu immer mehr Einfachheit und Klarheit führen würde, arbeitet Objekt Orientierung mit Verknüpfungen und Vermischungen. (die verschiedenen Objekt-Ebenen, Daten- und Programmstruktur und und und) Die Folge ist ein Gebilde, das immer komplizierter wird, je mehr man sich damit beschäftigt.
• Dass eine derart starke Verbreitung von Objekt Orientierung überhaupt möglich war liegt daran, dass es nicht Teil unserer Kultur ist, innere Erfahrung auszuwerten und rückzukoppeln. An Dingen, die allgemeiner Ansicht nach wahr sind, hält man einfach immer weiter fest, selbst wenn Projekte in Komplexität ersticken, keiner außer ein paar Beratern, die das behaupten, richtig durchsieht und Entwicklung schon seit Jahren keinen wirklichen Spaß mehr gemacht hat.
• Die wesentliche Grundlage der Methode ist eine unzulässige Verallgemeinerung lokal und begrenzt gültiger Strukturprinzipien: Nur weil mal ein Analyseobjekt gut auch ins Design gepasst hat, heißt das noch lange nicht, dass man das mit allen Analyseobjekten oder auch nur mit vielen machen könnte. Nur weil mal eine Komponente als Objekt erschien, kann man noch lange nicht alle Komponenten zu Objekten machen. Und nur weil mal eine Programmbibliothek objektorientiert gut zu entwickeln war, heißt das noch lange nicht, dass nun alle Softwareprogramme objekt-orientiert entwickelt werden müssten.
• Im Objektbegriff werden 3 Ebenen vermischt: Objekte aus der Welt der Anforderungen (z.B. Anwender), Objekte als Programmkomponenten (z.B. Datenbank) und das Objekt als Sprachelement einer Programmiersprache. Diese äußerst verwirrende Vermischung ist aber gleichzeitig Teil der Methode, weil Zusammenhänge zwischen diesen völlig verschiedenen Begriffsdimensionen suggeriert werden sollen.
• Die begriffliche Vermischung, die ein direktes Mapping von Anforderungselementen auf Lösungselemente herbeiführen soll, stellt natürlich den Versuch dar, die kreative Lücke zu schließen und einen möglichst konstruktiven Übergang von den Anforderungen zur Lösung zu finden. Gerade die kreative Lücke zwischen Anforderungen und Lösung ist aber der Spielplatz, auf dem sich die besonders kreativen Teile des Geistes austoben wollen. Wird die kreative Lücke konstruktiv geschlossen, werden die schöpferischsten Teile des menschlichen Geistes ausgeschlossen.
• Zudem ist das Mapping von Anforderungsobjekten auf Komponentenobjekte vollkommen daneben, weil die Anforderungsobjekte nahezu immer eine reine Datenaffinität haben. Das heißt sie finden sich als Datenbanktabelle wieder und das wars. Das auch noch in die Programmstruktur hineinzutragen, ist mehr als überflüssig.
• Vor der Objekt Orientierung war es üblich Daten und Quellcode getrennt zu strukturieren bzw. jedem Teil eine eigene Struktur zu erlauben. Das ist auch trotz Objekt Orientierung für fast alle Anwendungen immer noch die bessere Alternative. Plötzlich behauptet jemand: "Wir stülpen jetzt eine Struktur über Daten und Programmcode und verstecken die Daten" Und alle glauben es einfach. Absolut unglaublich!
• Dabei ist aber die Objekt-Struktur, die nun auch dem Programmcode übergestülpt wird, eine statische, der Datenwelt zuzuordnende Struktur. Software ist aber eine dynamische Angelegenheit. Es sind Folgen von Aktionen, die sich zu Transaktionen formieren und nicht zu Objekten. Der Datenanteil in Software ist in der absoluten Minderheit und auch im Aufwand mit einem Bruchteil des Gesamtaufwandes abgehakt.
• Das Übertragen von Anforderungsobjekten auf das Design führt haufenweise zu Trivialfunktionen. Das Erzwingen einer Objektstruktur erschafft haufenweise Kunstobjekte.
• Objekte können sinnvoll sein, wo sie auf Programmkomponentenebene auftauchen: Datenbank, Programmfenster, Datei. Dabei geht es dann meistens um sogenannte Ressourcen, deren Datenanteil irgendwelche betriebssystemspezifischen Zeiger sind, die man tatsächlich besser verbirgt. Insofern sind Programmbibliotheken vielleicht noch die am ehesten sinnvollen Anwendungsbereiche für die Design- und Implementierungsebene von Objekt Orientierung.
• In der Analyse allerdings hat Objekt-Orientierung gar nichts zu suchen, weil sie dort sowieso nur zu Trivialergebnissen führt, während Modelle, die etwas bringen würden, nicht in Betracht gezogen werden.

Für einfache Gemüter wie mich wäre es auch äußerst hilfreich, zu einer einfacheren Namensgebung zurückzukehren und die Dinge wieder ganz einfach so zu benennen wie sie sind: Datei, Datenbanktabelle usw. Denn schon bevor Objekt Orientierung begann, das vollends auf die Spitze zu treiben, hatte mit Begriffen wie "Modul" eine Entwicklung eingesetzt, bei der ich nie ganz sicher war: Was steckt nun eigentlich genau dahinter? Bei einer Datei weiß ich: Kann ich aufmachen und Programmzeilen drin finden. Ein Programm wird – wenns groß ist – auf mehrere Dateien aufgeteilt. Und dann gibt es eben noch eine Datenbank mit Datenbanktabellen. Viel mehr Begriffe brauche ich nicht und kann ich mir auch nicht merken. Na gut, vielleicht noch Funktion, Variable und Datentyp. Aber dann muss Schluss sein!

Die allgemeine Ansicht, Software sei etwas Kompliziertes führt dazu, dass man nicht merkt, dass erst die Objekt-Orientierung die Kompliziertheit erzeugt.

Es ist natürlich keine böse Absicht hinter Objekt Orientierung. Sie ist die logische Reaktion einer isolierten Ratio auf totale Überforderung angesichts einer Aufgabe, die eben nur in Zusammenarbeit mit dem schöpferischen Unterbewusstsein vernünftig gelöst werden kann. Und sie ist das Produkt von Theoretikern, die glauben, anderen Methoden entwickeln zu können, ohne dabei den Druck zu erfahren, laufende Anwendungen zack zack liefern zu müssen. Jene Anderen sind aber auch selbst schuld, weil sie ihre eigene Kompetenz in Softwareengineering, die sich aus Praxis völlig selbstverständlich ergibt, leichtfertig abgetreten haben.