Objektorientierung als Behaviorismus der Softwareentwicklung [OOP 2010]

Die Objektorientierung steht uns im Weg zu evolvierbareren Programmen. Ja, das glaube ich immer mehr. Nicht, dass ich Objekte missen möchte – sie sind nützliche und wichtige Strukturierungsmittel für Software.  Ich will natürlich Funktionseinheiten mit eigenem Zustand definieren können. Aber die Sprache der Objektorientierung wie sie C++, Java, C# und auch VB vorgeben, ist einfach nicht für Flexibilität und Evolvierbarkeit gedacht gewesen. Und da Sprache unser Denken bestimmt, kommen bei der Benutzung objektorientierter Sprachen eben nicht einfach flexible und evolvierbare Programme heraus.

Objektorientierung ist sozusagen die Brille der Programmier-Behavioristen. Wer durch sie blickt, vereinfacht die Welt extrem – manchmal bis zur Unkenntlichkeit. Wo die Welt der Behavioristen durch Reiz-Reaktion determiniert ist, da ist sie für “die Objektorientierten” durch Zustand und Synchronizität geprägt.

Und so wie Behaviorismus bei der Dressur eines Tanzbären funktionieren mag, so funktioniert Objektorientierung auch bei einem simplen Malprogramm. Ok, sie “funktioniert” auch bei viel größeren Anwendungen – doch ich meine mit “funktionieren” nicht, dass objektorientierter Code am Ende läuft, sondern ob mit den Mitteln der Objektorientierung etwas heraus kommt, was sich auch weiterentwickeln lässt. Denn das ist ein wesentliches und trotzdem oft unterschätztes Qualitätsmerkmal von Software. Beim Tanzbären ist das hingegen nicht wichtig. Wenn der keine neuen Tricks mehr lernt, nimmt man einen neuen.

Wer hingegen mehr als einen Tanzbären dirigieren will, z.B. ein ganzes Unternehmen, der ist mit Behaviorismus schlecht bedient. Unternehmensführung funktioniert schlecht mit Zuckerbrot und Peitsche als Mittel, um Reize auszulösen und Reaktionen zu provozieren, die eine vielköpfige Belegschaft verlässlich zum Erfolg führen.

Dito die Objektorientierung in nicht mehr einfach überschaubaren Szenarien. Direkte, streng typisierte und synchrone Kopplung ist das falsche Denkmuster für evolvierbare Software. Solche Kopplung ist aber der Default der Objektorientierung. Nur mit Mühe und Disziplin kann man sich von ihm lösen. Das mag dann zwar das Expertentum von Softwareentwicklern ausmachen – doch wie in Panik die Moral schnell verdampft, so verflüchtigen sich unter Projektdruck auch solche programmierzivilisatorischen Errungenschaften. Was dann nicht durch die Sprache quasi erzwungen wird, das findet nicht statt.

Deshalb bin ich für möglichst hart verdrahtete neue Defaults – wenn schon nicht neue Sprachen, die die Evolvierbarkeit begünstigen. Ein solcher Default ist die echte Komponentenorientierung, bei der Komponentenimplementationen physisch alleingestellt in Komponentenwerkbänken stattfinden und Komponenten einander nicht mehr direkt referenzieren. Deshalb bin ich für Flows als ersten groben Implementationsansatz für jede Realisierung eines Features; denn in Flows gibt es keine Kopplung mehr zwischen den Schritten, so dass die Evolvierbarkeit sehr hoch ist. Deshalb bin ich für die Nutzung eines in-proc Bussystems, d.h. selbst wenn die Kommunikation noch lokal und synchron ist. Ein solcher Bus entkoppelt noch mehr als ein DI Container.

Komponentenorientierung begrenzt die OO-Defaults lokal auf die Implementation einer überschaubaren Komponente. Und DI Container, Flows sowie Busse sind neue Defaults für die Kopplung von Strukturen, wenn es unüberschaubar wird – was immer schneller passiert, als wir uns vorstellen.

Wie wäre es, damit einmal im neuen Jahr zu experimentieren? Der überkommene Programmierbehaviorismus würde einem differenzierteren Verständnis von Software weichen.