Zitat von
mschaefer:
Zitat von
Chewie:
kannst du mir mal ein beispiel für eine Objektorientierte Sprache geben, die keine prozeduralen Elemente enthält?
Tja dass wird er wohl kaum können
Dreh- und Angelpunkt Deiner Darstellung, mschaefer, ist die historische Betrachtung der Entwicklung. Mir wird Deine Folgerung leider nicht ganz klar, glaube aber zu erkennen, dass Du die Möglichkeit, Befehle gruppieren zu können, als Prozedural ansiehst und glaubst, dass Objektorientierung ähnlich realisiert werden
muss. Ich gehe weiterhin davon aus, dass Du bisher nicht mit Sprachen wir Smalltalk gearbeitet hast und daher hybrid-Sprachen wie Java oder C++ zum Vergleich heranziehst.
Aus meiner Sicht könnte diese Aussage mit der folgenden verglichen werden: "Jedes Flugzeug ist auch ein Auto". Historisch gesehen basieren beide (meistens) auf Motoren, die zuerst in Automobilen eingesetzt wurden. Außerdem besitzen Flugzeuge (meistens) auch Reifen, die denen eines Automobils nicht unähnlich sind.
Mit Sicherheit gibt es noch weitere Ähnlichkeiten zwischen Flugzeugen und Automobilen, der wesentliche Aspekt eines Flugzeugs ist jedoch die Fortbewegung in der Luft (die ein Automobil nur kurzzeitig zulässt) und nur zur Zweckerfüllung, dem Transport von Masse, ist es überhaupt notwendig, das solche Flugzeuge auf einer staßenähnlichen Fahrbahn landen oder starten.
Zur Objektorientierung: Keineswegs ist
i print lediglich eine spezielle Notation zur Vereinfachung. Auch sind dies keine typgebundenen Prozeduren, die in unterschiedlichen, überladenen Varianten zur Übersetzungszeit gewählt werden. Das Beispiel zeigt, wie einem beliebigen "Objekt" die
Nachricht "print" gesendet wird. Dazu muss zur Übersetzungszeit weder bekannt sein, ob
i diese Nachricht versteht noch muss "print" überhaupt implementiert sein.
Weil Methoden wie Klassen gleichfalls Objekte sind, können sie zusammen zur Laufzeit dynamisch erzeugt und an spezielle Klassen/Objekte gebunden werden. Sollte
i im Beispiel die Nachricht trotzdem nicht in Form einer vorliegenden Implementierung beantworten können, so wird in Smalltalk die Nachricht
MessageNotUnderstood gesendet, was schlussendlich vergleichbar mit einer
Exception ist. Der Clou jedoch: Weil auch Nachrichten selbst Objekte sind, kann die Implementierung von
MessageNotUnderstood so angepasst werden, dass aus den Daten der ursprünglichen Nachricht etwas sinnvolles abgeleitet wird. So ist es in Smalltalk relativ einfach möglich, einen generischen Proxy zu implementieren, der Nachrichten, die er selbst nicht beantworten kann, delegiert und Antworten, wieder verpackt, an den Klienten sendet. Das alles geschieht vollkommen transparent und mit Nachrichten, die zur Übersetzungszeit des Proxies gänzlich unbekannt waren...