WARUM ARC NICHT BESONDERS OBJEKTORIENTIERT IST

Januar 2001

Es gibt derzeit eine Art Manie für objektorientierte Programmierung, aber einige der klügsten Programmierer, die ich kenne, sind am wenigsten begeistert davon.

Mein eigenes Gefühl ist, dass objektorientierte Programmierung in manchen Fällen eine nützliche Technik ist, aber es ist nichts, das jedes Programm, das Sie schreiben, durchdringen muss. Sie sollten in der Lage sein, neue Typen zu definieren, aber Sie müssen nicht jedes Programm als Definition neuer Typen ausdrücken.

Ich denke, es gibt fünf Gründe, warum die Leute objektorientierte Programmierung mögen, und dreieinhalb davon sind schlecht:

Objektorientierte Programmierung ist aufregend, wenn Sie eine statisch typisierte Sprache ohne lexikalische Schließungen oder Makros haben. Bis zu einem gewissen Grad bietet sie einen Weg, diese Einschränkungen zu umgehen. (Siehe Greenspuns Zehntes Gesetz.)

Objektorientierte Programmierung ist in großen Unternehmen beliebt, weil sie der Art und Weise entspricht, wie sie Software schreiben. In großen Unternehmen wird Software in der Regel von großen (und häufig wechselnden) Teams von durchschnittlichen Programmierern geschrieben. Objektorientierte Programmierung übt eine Disziplin auf diese Programmierer aus, die verhindert, dass einer von ihnen zu viel Schaden anrichtet. Der Preis ist, dass der resultierende Code aufgebläht ist mit Protokollen und voller Duplizierung. Das ist kein zu hoher Preis für große Unternehmen, da ihre Software ohnehin aufgebläht und voller Duplizierung sein wird.

Objektorientierte Programmierung erzeugt eine Menge von dem, was wie Arbeit aussieht. In den Zeiten des Endlospapiers gab es einen Typ von Programmierer, der nur fünf oder zehn Codezeilen pro Seite platzierte, gefolgt von zwanzig Zeilen aufwendig formatierter Kommentare. Objektorientierte Programmierung ist wie Crack für diese Leute: Sie lässt Sie diese ganze Gerüstarbeit direkt in Ihren Quellcode einbauen. Etwas, das ein Lisp-Hacker durch Pushen eines Symbols auf eine Liste erledigen würde, wird zu einer ganzen Datei voller Klassen und Methoden. Es ist also ein gutes Werkzeug, wenn Sie sich selbst oder jemand anderen davon überzeugen wollen, dass Sie viel Arbeit leisten.

Wenn eine Sprache selbst ein objektorientiertes Programm ist, kann sie von Benutzern erweitert werden. Nun, vielleicht. Oder vielleicht können Sie sogar noch besser abschneiden, indem Sie die Teilkonzepte der objektorientierten Programmierung à la carte anbieten. Überladen zum Beispiel ist nicht intrinsisch mit Klassen verbunden. Wir werden sehen.

Objektorientierte Abstraktionen passen gut zu den Domänen bestimmter spezifischer Arten von Programmen, wie Simulationen und CAD-Systeme.

Persönlich habe ich objektorientierte Abstraktionen nie gebraucht. Common Lisp hat ein enorm leistungsfähiges Objektsystem, das ich noch nie verwendet habe. Ich habe viele Dinge getan (z.B. Hashtabellen mit Schließungen füllen), die in schwächeren Sprachen objektorientierte Techniken erfordert hätten, aber ich habe CLOS nie benutzen müssen.

Vielleicht bin ich einfach dumm oder habe nur an einem begrenzten Teilbereich von Anwendungen gearbeitet. Es besteht die Gefahr, eine Sprache auf der Grundlage der eigenen Programmiererfahrung zu entwerfen. Aber es scheint gefährlicher, Dinge einzubauen, die man selbst nie gebraucht hat, nur weil man denkt, dass es eine gute Idee ist.