WARUM ARC NICHT BESONDERS OBJEKTORIENTIERT IST

Januar 2001

Momentan herrscht eine Art Manie hinsichtlich der objektorientierten Programmierung, aber einige der intelligentesten Programmierer, die ich kenne, zählen zu den Leuten, die davon am wenigsten begeistert sind.

Ich persönlich bin der Meinung, dass objektorientierte Programmierung in manchen Fällen eine nützliche Technik ist, aber sie muss nicht in jedem Programm vorhanden sein, das Sie schreiben. Sie sollten in der Lage sein, neue Typen zu definieren, aber Sie sollten nicht jedes Programm als Definition neuer Typen ausdrücken müssen.

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

Objektorientierte Programmierung ist spannend, wenn Sie eine statisch typisierte Sprache ohne lexikalische Abschlüsse oder Makros haben. Bis zu einem gewissen Grad bietet sie eine Möglichkeit, diese Einschränkungen zu umgehen. (Siehe Greenspuns zehnte Regel .)

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 mittelmäßiger Programmierer geschrieben. Objektorientierte Programmierung erlegt diesen Programmierern eine Disziplin auf, die verhindert, dass einer von ihnen zu großen Schaden anrichtet. Der Preis dafür ist, dass der resultierende Code mit Protokollen aufgebläht und voller Duplikate ist. Für große Unternehmen ist dies kein zu hoher Preis, da ihre Software wahrscheinlich sowieso aufgebläht und voller Duplikate sein wird.

Objektorientierte Programmierung erzeugt eine Menge von Dingen, die wie Arbeit aussehen. Damals, als es noch Fanfolds gab, gab es einen Programmierertyp, der nur fünf oder zehn Zeilen Code auf eine Seite schrieb, denen zwanzig Zeilen aufwendig formatierter Kommentare vorangestellt waren. Objektorientierte Programmierung ist für diese Leute wie Crack: Sie können all diese Gerüste direkt in Ihren Quellcode integrieren. Etwas, das ein Lisp-Hacker vielleicht durch das Einfügen eines Symbols in eine Liste erledigen könnte, wird zu einer ganzen Datei mit Klassen und Methoden. Es ist also ein gutes Werkzeug, wenn Sie sich selbst oder jemand anderen davon überzeugen möchten, dass Sie viel Arbeit leisten.

Wenn eine Sprache selbst ein objektorientiertes Programm ist, kann sie von Benutzern erweitert werden. Nun ja, vielleicht. Oder vielleicht kann man es sogar noch besser machen, indem man die Unterkonzepte der objektorientierten Programmierung à la carte anbietet. Überladung zum Beispiel ist nicht untrennbar mit Klassen verbunden. Wir werden sehen.

Objektorientierte Abstraktionen lassen sich gut auf die Domänen bestimmter Programmtypen abbilden, beispielsweise Simulationen und CAD-Systeme.

Ich persönlich habe objektorientierte Abstraktionen nie gebraucht. Common Lisp hat ein enorm leistungsfähiges Objektsystem und ich habe es nie ein einziges Mal benutzt. Ich habe viele Dinge getan (z. B. Hash-Tabellen voller Closures erstellt), für die in schwächeren Sprachen objektorientierte Techniken erforderlich gewesen wären, aber ich musste CLOS nie verwenden.

Vielleicht bin ich einfach nur dumm oder habe nur an einer begrenzten Anzahl von Anwendungen gearbeitet. Es ist gefährlich, eine Sprache auf Grundlage der eigenen Programmiererfahrung zu entwickeln. Aber es scheint gefährlicher, Dinge einzubauen, die man nie gebraucht hat, nur weil man denkt, es sei eine gute Idee.