Inspiriert durch den letzten Beitrag von Ralf Westphal "Mehr vom Selben hilft nicht mehr", dachte ich mir, dass es durchaus sinnvoll sein kann, der Kernaussage noch mehr Ausdruck zu verleihen. Ganz im Sinne von "Spread the word!"
Längere Zeit vorher beschäftigte ich mich auch mal mit Konzepten, wie z.B. Funktionale Programmierung und Data Oriented Design.
Und ich sagte so zu mir: "Verdammt! Recht haben sie!"
Es geht seit der Erfindung des ersten Computers um Datenverarbeitung. Und das möglichst effizient und seiteneffektfrei!
Warum ist das aber in Vergessenheit geraten? Haben wir schon lange den Boden unter den Füßen verloren?
Das kann man wohl annehmen. Dank *hust* der Objektorientierten Programmierung (OOP) programmiert man nicht mehr, sondern modelliert nur noch. Es wird alles Erdenkliche in Klassen beschrieben und durch Objekte ins Leben gerufen. Ob das nun sinnvoll ist, oder nicht. Egal! "OOP ist ja sooo geil und überhaupt kann man damit viel besser die Welt beschreiben."
Ja, man kann damit wunderbar die Welt beschreiben und modellieren. Damit wirbt zumindest jedes mir bekannte OOP-Buch.
Gerade, um den Leser für Vererbung zu begeistern, werden wirklich immer diese trivialen Beispiele, wie z.B. die Tierklassen, Autoklassen, Baumklassen, etc. aufgeführt.
Aber ganz ehrlich: Derartigen trivialen Nonsens habe ich bisher noch nie in meinen Softwareprojekten vorgefunden. In der Software-Realität gibt es eher "Tierautos mit Blättern dran". Das liegt ganz einfach daran, dass man viele Dinge im Businessproblem nicht so einfach klassifizieren kann, wie es einen die OOP-Autoren gerne schmackhaft machen wollen. Objekte müssen miteinander interagieren und Daten austauschen, denn nur darum geht es letztlich wieder: um die Datenverarbeitung.
Aber auch dafür hat sich die OOP-Gemeinde einige Konstrukte ausgedacht, die sich Entwurfsmuster "schimpfen". Überhaupt wurde der Trend eingeleitet, man solle nicht mehr "ableiten" und "vererben", sondern "komponieren". Dies sei flexibler, sagt man. (Was ich auch nicht bestreiten will.)
Doch sehe ich die Entwurfsmuster eher als Krücke. Nach dem Motto: Not macht erfinderisch.
Und, dass diese Entwurfsmuster nur ein Notnagel sein können, sieht man z.B. am "Visitor Pattern" oder dem "State Pattern". Die mögen ja wunderbar funktionieren, aber den Quellcode darf man hinterher nicht verstehen, geschweige denn debuggen wollen.
Tja, das hat alles nicht mehr den Eindruck, als wolle man Daten verarbeiten, sondern als wolle man geschickt mit einem Netzwerk aus Objekten um die Daten herumtanzen, ohne diese direkt zu berühren.
Es denkt doch keiner mehr an den Prozessor und an den Speicher.
Die OOP widerspricht immer noch der Arbeitsweise der gegenwärtigen Rechner. Denn im Rechner sind noch immer die Daten vom Code getrennt. Der Prozessor kennt keine Klassen, Objekte und erst recht keine Entwurfsmuster. Das wäre ja alles kein Problem, wenn die Zugriffszeiten auf den Arbeitsspeicher nicht den Prozessor unnötig ausbremsen würden.
Ganz ehrlich: Ich würde kein Prozessor sein wollen, der ein OO Programm bewältigen muss. ;-)
Warum versucht man also die Welt - das Businessproblem - in ein OO-Schema zu pressen, welches der Compiler wieder halbwegs entfrickeln (Code von Daten trennen) muss, damit es der Prozessor dann mehr schlecht als optimal lösen "darf"?
Und wie man dem Beitrag von Ralf entnehmen kann, geben die OOP-Gurus zu verstehen, dass die Mehrheit nach so vielen Jahren noch immer nicht richtig OO programmieren kann.
Ja, da muss man wirklich fragen, wessen Problem das ist? Ich brauche diese "Religion" OOP nicht wirklich, um meine Business-Probleme auf Arbeit zu lösen. Das habe ich jedoch leider eher spät gemerkt, weil ich auch auf den OOP-Zug aufgesprungen bin, der sehr gut beworben wurde. Hinterher fand ich die Codebasis aber trotzdem nicht schön. Vielmehr war alles so aufgeblasen und ich verlor den Überblick.
Ich frage mich aber wirklich, warum die OOP-Gurus so hartnäckig an der Objektorientierung festhalten. Geht es dabei nur um das Modellieren der Welt?
Wäre es nicht sinnvoller, ein Paradigma zu wählen, welches dem Programmierer gleichermaßen entgegen kommt, wie der Hardware? Wenn man nicht mehr versuchen würde, die Business-Probleme 1:1 mit Objekten zu beschreiben, sondern die Probleme grundlegend abstrahieren würde, sodass diese einfacher zu fassen und für die Hardware optimal beherrschbar sind?
Vielleicht hat man damals die Idee - den Code von den Daten getrennt zu halten - zu schnell verworfen. Denn gerade die Rechnerarchitektur zeigt uns doch, wie die Daten am besten verarbeitet werden können. Und solange sich die Architektur nicht ändert, ist es IMHO keine gute Idee, weiterhin die Daten mit dem Code zu mischen.
Ich bin zumindest gespannt, wohin die Reise gehen wird. Spätestens mit den ersten Quantenrechnern dürfte sich noch so Einiges ändern. ;-)
Sehr guter Artikel. Die OOP ist doch nur eine Idee von Vielen ein Abbild des zu lösenden Problems in die technische Welt zu bekommen. Die OO ist kein Allheilmittel. Sie hat ja auch große Schwächen. So ist eine sinnvolle Massenverarbeitung von Daten eigentlich nicht machbar bzw. nur so wie es auch Funktionale oder andere "Religionen" auch nur machen. Wichtig ist doch für das jeweilige Problem die passende Religion zu nehmen. Das ist oft schwierig, da man in Projekten auf Sprachen und Environments festgelegt ist. Auch das miteinander der Softwareentwickler ist wichtig und da helfen natürlich eine gemeinsame "Sprache" und ähnliche Ansichten. Die OO versucht hier ein allgemeineres Verständnis aufzubauen. Aber Ein Werkzeug ist nur dann gut wenn es einfach zu bedienen ist und die OO ist nicht wirklich einfach.
AntwortenLöschen