WARUM ARC NICHT BESONDERS OBJEKTORIENTIERT IST

Januar 2001

Es gibt momentan eine Art Manie für objektorientierte Programmierung, aber einige der intelligentesten Programmierer, die ich kenne, sind die am wenigsten begeisterten darüber.

Mein eigenes Gefühl ist, dass objektorientierte Programmierung in einigen Fällen eine nützliche Technik ist, aber es ist nichts, was jedes Programm, das du schreibst, durchdringen muss. Du solltest in der Lage sein, neue Typen zu definieren, aber du solltest nicht jedes Programm als die Definition neuer Typen ausdrücken müssen.

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

Objektorientierte Programmierung ist aufregend, wenn du eine statisch typisierte Sprache ohne lexikalische Closures oder Makros hast. Bis zu einem gewissen Grad bietet sie einen Weg, um diese Einschränkungen zu umgehen. (Siehe Greenspun's 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 tendenziell von großen (und häufig wechselnden) Teams mittelmäßiger Programmierer geschrieben. Objektorientierte Programmierung auferlegt diesen Programmierern eine Disziplin, die verhindert, dass einer von ihnen zu viel Schaden anrichtet. Der Preis ist, dass der resultierende Code mit Protokollen überladen und voller Duplikate ist. Dies ist für große Unternehmen kein zu hoher Preis, da ihre Software wahrscheinlich sowieso überladen und voller Duplikate sein wird.

Objektorientierte Programmierung erzeugt viel, was wie Arbeit aussieht. In den Zeiten von Fanfold gab es eine Art Programmierer, die nur fünf oder zehn Zeilen Code auf eine Seite schrieben, gefolgt von zwanzig Zeilen aufwendig formatierter Kommentare. Objektorientierte Programmierung ist wie Crack für diese Leute: Sie ermöglicht es dir, all dieses Gerüst direkt in deinen Quellcode zu integrieren. Etwas, das ein Lisp-Hacker möglicherweise durch das Hinzufügen eines Symbols zu einer Liste handhaben würde, wird zu einer ganzen Datei von Klassen und Methoden. Es ist also ein gutes Werkzeug, wenn du dich selbst oder jemand anderen überzeugen möchtest, dass du viel Arbeit machst.

Wenn eine Sprache selbst ein objektorientiertes Programm ist, kann sie von Benutzern erweitert werden. Nun, vielleicht. Oder vielleicht kannst du es sogar besser machen, indem du die Unterkonzepte der objektorientierten Programmierung à la carte anbietest. Überladung zum Beispiel ist nicht intrinsisch an Klassen gebunden. Wir werden sehen.

Objektorientierte Abstraktionen passen gut zu den Bereichen bestimmter spezifischer Arten von Programmen, wie Simulationen und CAD-Systemen.

Ich persönlich habe nie objektorientierte Abstraktionen benötigt. Common Lisp hat ein enorm leistungsfähiges Objektsystem und ich habe es nie einmal verwendet. Ich habe viele Dinge getan (z. B. Hash-Tabellen voller Closures erstellt), die in schwächeren Sprachen objektorientierte Techniken erfordert hätten, aber ich musste CLOS nie verwenden.

Vielleicht bin ich einfach dumm oder habe an einem begrenzten Teil von Anwendungen gearbeitet. Es besteht die Gefahr, eine Sprache basierend auf der eigenen Programmiererfahrung zu entwerfen. Aber es scheint gefährlicher zu sein, Dinge einzufügen, die du nie benötigt hast, nur weil man denkt, dass es eine gute Idee ist.