Spätere (ignorante ;) Generationen von Programmierern haben sich dann den Begriff jeweils so hindefiniert wie sie dachten, es passt schon.
Kays Überlegungen lassen sich in "the Early History of Smalltalk" (erschienen in HOPL II meine ich) nachlesen. Das ist aber alles grenzwertig philosophisch. Einfacher zu lesen ist Dan Ingalls "Design Principles Behind Smalltalk". Dort wird das Denkmuster (Paradigma) explorativen und iterativen Entwicklung mittels Objekten vorgestellt.
Dies sind die Grundfesten der Objektorientierung:
- Einheitlichkeit: Alles ist ein Objekt, alles funktioniert gleich
- Kommunikation: Objekte tauschen Nachrichten aus
Die reinste objektorientiere Sprache ist IMHO Self, ein Smalltalk-Dialekt, der neben für so unbekannten Sprachen wie Newton-Script (dieser von Jobbs ungeliebte Apple-PDA, der zu früh für die Welt kam) Vorbild für JavaScript war und dessen Erbe auch in der Sprache Io zu finden ist.
Actor, neben Smalltalk eine Insprationsquellle für Erlang, war eine weitere objektorientierte Sprache. Smalltalk selbst muss es per definitionem sein, ebenso Objective-C und Ruby als semantische Klone von Smalltalk.
Danach wird's aber dann dünn :) Flavors (frühes Lisp-OO-System) und eine reine weiterer Systeme haben versucht, Ideen der objektorientierten Programmierung mit funktionalen Konzepten zu verknüpfen, was schließlich zum Meta-Objekt-Protokoll und CLOS führte, das in abgemilderter Form dann in Dylan (damit wollte Apple mal zukünftige Mac-OS-Systeme bauen, ist aber nix geworden) realisiert wurde und sogar in Python 3 in Form generischer Funktionen schwappen könnte (den Klassenlinearisierungsalgoritmus von Dylan benutzt Python ja schon). C++ basiert eher auf Simula als auf Smalltalk und teilt sich damit den Vorfahr, aber nicht die eigentlichen Konzepte. Simula war ein Algol mit Klassen - mehr nicht.
Geblieben (und IMHO auch wichtiger) ist die Objektorientierung als Entwurfsmethode für Software - OOA und OOD sind hier zwei wichtige Begriffe neben OOP, wobei ich mich immer schwer tue, dies zu trennen und lieber nach Jacobsen (dem Erfinder der Usecases) von Entwurf und Realisierung als zwei Phasen rede.
Objekte sind hier (ich glaube, das basiert auf der Definition von Booch, es ist ewig her, das ich all diese Bücher gelesen habe als OO noch neu und shiny war und jeder der späteren Amigos ein Buch zu dem Thema schrieb) Dinge oder Konzepte die sich durch drei Eigenschaften auszeichnen:
- Identität: Sie sind von anderen Objekten unterscheidbar
- Zustand: Sie speichern Informationen
- Verhalten: Sie handeln und agieren
Alle OOA/OOD-Methoden (viele haben nicht überlebt bzw. sind verschmolzen, aber es gab mal Coad/Jordan, OMT, Booch, UC, OBA) sagen jetzt, man soll Objekte identifizieren (häufig klassifiziert man sie dann oder findet gleich die Klassen - an diesem Abstraktionsschritt stolpern aber viele) und ihr Verhalten definieren. Ich mag den Ansatz von CRC-Cards (von Nancy Wilkinson IIRC) wobei CRC für Class, Resposibility und Collaboration steht. Oder DDD (von Evans) was für Domain Driven Design steht. Dazu kommen noch TDD (Kent Beck) oder BDD (Dave Astels?), was aber eher für die eigentliche Implementierung gut ist und nicht so sehr für die Analyse des Problems.
Also: Objektorientierung heißt, Lösungen zu finden, indem man das Problem solange konzeptionell derart in untereinander kommunizierende Dingheiten (Objekte eben) zerlegt, bis man genug gelernt hat, es verstanden hat und eine Lösung in der gewählten Programmiersprache gefunden hat.
Stefan