WARUM ARC NICHT BESONDERS OBJEKTORIENTIERT IST

January 2001

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

Mein eigenes Gefühl ist, dass objektorientierte Programmierung in einigen Fällen eine nützliche Technik ist, aber es ist nicht etwas, das jedes Programm durchdringen muss, 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 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 Zehnte Regel.)

Objektorientierte Programmierung ist in großen Unternehmen beliebt, weil sie zu der Art und Weise passt, wie sie Software schreiben. In großen Unternehmen wird Software in der Regel von großen (und häufig wechselnden) Teams von mittelmäßigen Programmierern geschrieben. Objektorientierte Programmierung erzwingt eine Disziplin bei diesen Programmierern, 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 kein zu hoher Preis für große Unternehmen, da ihre Software wahrscheinlich sowieso überladen und voller Duplikate sein wird.

Objektorientierte Programmierung erzeugt eine Menge dessen, was wie Arbeit aussieht. In den Tagen von Fanfold gab es eine Art von Programmierer, der nur fünf oder zehn Zeilen Code auf eine Seite setzte, vorangestellt von zwanzig Zeilen aufwendig formatierter Kommentare. Objektorientierte Programmierung ist wie Crack für diese Leute: Sie lässt Sie all diese Gerüste direkt in Ihren Quellcode integrieren. Etwas, das ein Lisp-Hacker möglicherweise durch Drücken eines Symbols auf eine Liste handhabt, wird zu einer ganzen Datei mit Klassen und Methoden. Es ist also ein gutes Werkzeug, wenn Sie sich selbst überzeugen wollen, oder jemand anderen, 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 noch besser, indem Sie die Unterkonzepte der objektorientierten Programmierung à la carte anbieten. Überladung, zum Beispiel, ist nicht intrinsisch an Klassen gebunden. Wir werden sehen.

Objektorientierte Abstraktionen lassen sich gut auf die Bereiche bestimmter Arten von Programmen abbilden, wie z. B. Simulationen und CAD- Systeme.

Ich persönlich habe objektorientierte Abstraktionen nie gebraucht. Common Lisp hat ein enorm leistungsstarkes Objektsystem und ich habe es noch nie benutzt. Ich habe viele Dinge getan (z. B. Hash-Tabellen voller Schließungen erstellen), die objektorientierte Techniken in schwächeren Sprachen erfordert hätten, aber ich musste CLOS nie verwenden.

Vielleicht bin ich einfach dumm oder habe an einem begrenzten Teilbereich von Anwendungen gearbeitet. Es besteht die Gefahr, eine Sprache zu entwerfen, die auf den eigenen Erfahrungen mit der Programmierung basiert. Aber es scheint gefährlicher, Dinge hineinzustecken, die man nie gebraucht hat, weil man sie für eine gute Idee hält.