Hat der OOP-Hammer ausgedient?

Die Grundidee der objektorientierten Programmierung ist denkbar einfach: Man versucht, ein Programm in Teile zu zerlegen, die genauso leistungsfähig sind wie das Ganze. Daraus folgt, dass man Teile von Daten und Funktionen koppelt, die nur auf die betreffenden Daten angewendet werden. Daten und Funktionen, die sich innerhalb eines Objekts befinden, sind für die Außenwelt unsichtbar. Man kann mit dem Inhalt eines Objekts nur über Nachrichten interagieren, die typischerweise Getter- und Setter-Funktionen genannt werden.

Was nicht in der ursprünglichen Idee enthalten ist, aber heute als wesentlich für die objektorientierte Programmierung angesehen wird, sind Vererbung und Polymorphismus. Vererbung bedeutet im Grunde, dass Entwickler Unterklassen definieren können, die alle Eigenschaften der übergeordneten Klasse besitzen. Dies wurde in der objektorientierten Programmierung erst 1976 eingeführt, ein Jahrzehnt nach ihrer Entstehung.

Durch die Kapselung von Daten und Methoden machte die objektorientierte Programmierung die Softwareentwicklung menschenzentrierter. Es entspricht der menschlichen Intuition, dass die Methode drive() zu der Datengruppe car gehört, aber nicht zu der Gruppe teddybear.

Als die Vererbung aufkam, war das auch intuitiv. Es macht durchaus Sinn, dass Hyundai eine Untergruppe von Auto ist und die gleichen Eigenschaften teilt, aber PooTheBear nicht.

Das klingt nach einer mächtigen Maschinerie. Das Problem ist jedoch, dass Programmierer, die nur objektorientierten Code kennen, diese Denkweise allem aufzwingen, was sie tun. Das ist so, wie wenn Leute überall Nägel sehen, weil sie nur einen Hammer haben. Wie wir weiter unten sehen werden, kann das zu fatalen Problemen führen, wenn Ihr Werkzeugkasten nur einen Hammer enthält.

Insbesondere Anhänger der Funktionellen Programmierung folgern daraus, dass sich OOP überholt hat. Rhea Moutafis benennt in seinem englischsprachigen Artikel die fünf größten Probleme von OOP. Gemeinsam haben die fünf Probleme, dass sie Vererbung dort implementieren, wo sie nicht die beste Lösung ist. Da Vererbung nicht einmal in der ursprünglichen Form der objektorientierten Programmierung enthalten war, würde ich diese Probleme nicht als inhärent für die Objektorientierung bezeichnen. Sie sind nur Beispiele für ein zu weit gehendes Dogma.

Aber nicht nur die objektorientierte Programmierung kann übertrieben werden. In der rein funktionalen Programmierung ist es extrem schwierig, Benutzereingaben zu verarbeiten oder Meldungen auf einem Bildschirm auszugeben. Objektorientierte oder prozedurale Programmierung ist für diese Zwecke viel besser geeignet.

Trotzdem gibt es Entwickler, die versuchen, diese Dinge als reine Funktionen zu implementieren und ihren Code auf Dutzende von Zeilen aufblasen, die niemand verstehen kann. Mit einem anderen Paradigma hätten sie ihren Code leicht auf ein paar lesbare Zeilen reduzieren können.

Paradigmen sind ein bisschen wie Religionen. In Maßen sind sie gut - Jesus, Mohamed und Buddha haben wohl einige ziemlich coole Sachen gesagt. Aber wenn Sie ihnen bis ins kleinste Detail folgen, könnten Sie am Ende das Leben von sich selbst und von den Menschen um Sie herum ziemlich unglücklich machen.

Das Gleiche gilt für Programmierparadigmen. Es besteht kein Zweifel, dass die funktionale Programmierung auf dem Vormarsch ist, während die objektorientierte Programmierung in den letzten Jahren heftige Kritik auf sich gezogen hat.

Es ist sinnvoll, sich über neue Programmierparadigmen zu informieren und sie bei Bedarf einzusetzen. Wenn die objektorientierte Programmierung der Hammer ist, mit dem Entwickler überall Nägel sehen, ist das ein Grund, den Hammer aus dem Fenster zu werfen? Nein. Sie fügen Ihrem Werkzeugkasten einen Schraubenzieher hinzu, und vielleicht ein Messer oder eine Schere, und Sie wählen Ihr Werkzeug je nach dem anstehenden Problem. Funktionale und objektorientierte Programmierer sind Werkzeuge, und sie alle haben irgendwo ihren Nutzen. Was Sie verwenden, sollte nur davon abhängen, welche Probleme Sie lösen wollen.