Performancemythen?

Phoemuex

scrub schrieb:

Xin schrieb:

Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.

Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?

Ich habe diesen Thread jetzt 17 Seiten lang gelesen und langsam wird es mir zu blöd.

Man muss doch drei Dinge einsehen können.

Die Definition, die du für OOP benutzt, ist nicht die gängige. Du nimmst einen Teil dessen, was allgemein als OOP verstanden wird (virtuelle Methoden, bzw. Polymorphie, virtuelle Methoden sind ja praktisch nur ein Implementierungsdeteil, um Polymorphie zu erreichen) und definierst das als das einzig und allein von OOP bezeichnete. Das ist aber im üblichen Sprachgebrauch nicht so. Dort ist es nämlich so, dass der Begriff OOP sehr viele verschiedene Dinge wie Kapselung, Polymorphie, Typsicherheit und vor allem die Zusammenlegung von Daten und Funktionen zu einem Datentyp bezeichnet. D.h. es existieren nicht getrennt Daten und Funktionen, sondern man schreibt eine Klasse, die sowohl die Daten als auch die Methoden, d.h. die Funktionalität der Objekte der Klasse bestimmt.
Du reitest darauf herum, dass es OBJEKT-orientier heißt, und hälst anderen vor, dass bei allen Bestandteilen der OOP (nach meinem Verständnis) kein OBJEKT benutzt/gebraucht wird, weil der dynamische Typ nicht gebraucht wird. Was man aber sehen muss, ist das jedes Objekt auch einen STATISCHEN TYP hat. Und auf den kann man sich doch mit dem gleichen Recht wie auf den dynamischen beziehen und das ganze dann Objektorientiert nennen.
Warum dir keiner WIRKLICH widerspricht: Es ist halt (wie oben gesagt) so, dass OOP sehr unscharf definiert ist und deswegen kann man kein Zitat finden, dass dir explizit widerspricht (auch wenn ein paar Quellen ja in die Richtung gehen). Aber deine bisher gebrachten Zitate/Quellen untersützten deine Meinung auch nicht wirklich.

Um nur mal ein Beispiel zu bringen, ein Zitat aus Marc++us Buch, welche Konzepote alle unter OOP verstanden werden:

Objekte, Klassen, Vererbung, Polymorphie, Späte Bindung, Kapselung.

Das 2. Kapitel in genau dem Buch heißt übrigens "Wieso eigentlich nicht 'klassenorientierte Programmierung'". Eine wirkliche Antwort darauf wird allerdings auch nicht gegeben Es liegt halt daran, dass man das Verhalten von Objekten in der OOA analysiert, um daraus Klassen zu abstrahieren und nachher wieder mit OBJEKTEN dieser Klasse arbeitet. Ohne irgendwelche Instanzen nutzen die schönsten Klassen nichts (oder sind nicht mehr als namespaces)...

Wenn das jetzt auch nicht reicht, Pech gehabt... Irgendwann muss das hier doch mal ein Ende haben. Sonst wälze ich gleich auch noch den Struppi und suche ein vernünftiges Zitat, das die gängige Fassung belegt.

Mehr als diese Erklärung und die gängige Meinung + Belege dafür kann man wirklich nicht verlangen, um von der Haarspalterei um die OBJEKT anstatt Klassen orientierte Programmierung wegzukommen...

Um nochmal darauf hinzuweisen: Es geht hier eigentlich um "Performancemythen". Dazu steht auch etwas schönes in Marc++us Buch:

Haben Sie auch schon davon gehört, dass C++ langsam ist, weil man nie direkt auf die Variablen zugreift? Unsinn, lassen Sie sich davonkeine Angst machen. Der Zugriff mit einer kleinen kurzen get-Methode auf eine Variable wird von einem optimierenden Cimpiler so gut übersetzt, dass es nur einige Taktzyklen länger dauert, als direkt auf die Variable zuzugreifen. Es gibt keinen Grund, wegen der Rechenzeig hier einen Kompromiss einzugehen, dies ist am falschen Ende gespart.

Dazu kommt natürlich auch noch inline + Optimierungen, sodass im besten Fall sogar gar keine Methode aufgerufen wird...

Endlich mal wieder Ontopic (obwohl die Ausschweifung mit der Komplexität und der O-Notation ja auch relativ on-topic war).

Vielleicht sollte mal wer ein Gesetz aufstellen, dass das auftreten eines Flamewars in Abhängigkeit der Benutzer eines Forums beschreibt. So was ähnliches wie Godwins Gesetz.

Felix

finix

minhen schrieb:

Damit entspricht Xins "provokante" Aussage, C++-Code wäre ohne virtual nicht objekt-orientiert, voll und ganz dem, was Stroustrup sagt und unter OOP versteht.

Jester

minhen schrieb:

Xin argumentiert zwar als einziger hier überzeugend

Mich wundert ehrlich gesagt was Du als überzeugend ansiehst. Er behauptet irgendwelche Dinge, geht auf keine Argumente ein. Standard-Definitionen bzw. Referenzen auf diese werden damit abgebügelt, dass man ja offensichtlich nicht in der Lage sei sich kritisch mit den Sachen auseinanderzusetzen. Das überzeugt mich zwar auch, aber von anderen Dingen als vom Autor vorgesehen.

Helium

Xin schrieb:

Beschreibe den Ablauf von 'dynamisch dispatched' mal ganz detailiert.

Meinst du den technischen Ablauf? Der ist doch von Sprache zu Sprache extrem verschieden. In statisch typisierten Sprachen habe ich ganz ander Optimierungsmöglichkeiten, z.B. mit virtuellen Methodentabellen, als z.B. in dynamisch typisierten Sprachen. Wenn ich Multimethoden unterstütze kann ich wieder anders vorgehen, jenachdem, wieviel Typinformation mir zur Compilezeit zur verfügung steht. ...

Xin schrieb:

Helium schrieb:

Klassen können also Objektorientiert sein.
Definiere dann möglichst genau, wann eine Klasse objektorientiert ist.

Sobald virtual enthalten ist und virtuelle Methoden in abgeleiteten Klassen überschrieben werden.

Was ist mit Sprachen, die nicht statisch typisiert sind? Keine Klasse muss von der anderen abgeleitet sein. Dennoch habe ich genau das Verhalten, das ich bei deinen virtuellen Methoden und abgeleiteten Klassen hätte. (Selbst statisch typisierte Sprachen unterstützen teilweise Ducktyping.)
Oder in prototypbasierten Sprachen. Ich klone ein Objekt, modifiziere die Methode des einen Objekts und schon habe ich auch das selbe Verhalten, ohne dass überhaupt eine Klasse vorgekommen ist.

minhen schrieb:

Damit entspricht Xins "provokante" Aussage, C++-Code wäre ohne virtual nicht objekt-orientiert, voll und ganz dem, was Stroustrup sagt und unter OOP versteht. Denn ohne Laufzeit-Polymorphie ist das Kriterium der Objekt-Orientierung eben nicht vollständig erfüllt.

Falsch. In dem verlinkten Text von Stroustrup redet dieser von der C++ Sprache und _nicht_ von C++-Code. Er definiert dort erstmal nur ab wann sich eine Programmiersprache als Objektorientiert bezeichnen darf.

Xin

minhen schrieb:

Xin argumentiert zwar als einziger hier überzeugend - aber vielleicht sollte man sich dennoch auch mal ansehen, wie Bjarne Stroustrup Objekt-Orientierung definiert. Schließlich beruft sich Xin auch auf ihn.

Guter Link, hätte ich mal nach suchen sollen. Thx.

Phoemuex Post ist mir jetzt zu lang, um da was zu quoten. Zumal ich nicht weiß, wogen er argumentiert.
Er antwortet auf scrup, schreibt "Du" und das 1. und 3. Argument scheint gegen mich zu gehen.
Zu Punkt zwei möchte ich anmerken, dass ich darauf rumreite, dass es objektORIENTIERT heißt.

Phoemuex schrieb:

Dazu kommt natürlich auch noch inline + Optimierungen, sodass im besten Fall sogar gar keine Methode aufgerufen wird...

Faktor 5-10. "Bestätigt", wie die Mythbuster so gerne sagen.

Jester schrieb:

minhen schrieb:

Xin argumentiert zwar als einziger hier überzeugend

Mich wundert ehrlich gesagt was Du als überzeugend ansiehst. Er behauptet irgendwelche Dinge, geht auf keine Argumente ein.

Argumente? Ich höre laufend "Ich finde..." und keinerlei Begründungen, warum diejenigen hier etwas verloren haben.

4 Leute schreiben Aussagen von mir ab, behaupten, dass sie das Gegenteil bedeuten von dem, was da steht und darauf soll ich eingehen?

Bring erstmal ein Argument, auf das ich eingehen kann.
Ich sagte ja bereits, wo ich meine Ansicht kippen lassen würde.
Seit 7 Seiten frage ich in jedem zweiten Posting, dass man nur die Frage an hustbaer sinnvoll beantworten müsse. Bisher hat's noch nichtmals einer versucht.

Phoemuex

Xin schrieb:

Phoemuex Post ist mir jetzt zu lang, um da was zu quoten. Zumal ich nicht weiß, wogen er argumentiert.
Er antwortet auf scrup, schreibt "Du" und das 1. und 3. Argument scheint gegen mich zu gehen.
Zu Punkt zwei möchte ich anmerken, dass ich darauf rumreite, dass es objektORIENTIERT heißt.

Ich stimmte scrup zu und widerspreche damit dir. War ein bisschen unklar...

Felix

Xin

Helium schrieb:

Xin schrieb:

Beschreibe den Ablauf von 'dynamisch dispatched' mal ganz detailiert.

Meinst du den technischen Ablauf? Der ist doch von Sprache zu Sprache extrem verschieden. In statisch typisierten Sprachen habe ich ganz ander Optimierungsmöglichkeiten, z.B. mit virtuellen Methodentabellen, als z.B. in dynamisch typisierten Sprachen. Wenn ich Multimethoden unterstütze kann ich wieder anders vorgehen, jenachdem, wieviel Typinformation mir zur Compilezeit zur verfügung steht. ...

Bei objektorientiertem Problemstellungen ist der Punkt ja eben, dass die exakte Typ-Information eben nicht zur Compilezeit zur Verfügung steht. Darum OOP, weil Multimethoden eben nicht reichen.

Helium schrieb:

Ich klone ein Objekt, modifiziere die Methode des einen Objekts und schon habe ich auch das selbe Verhalten, ohne dass überhaupt eine Klasse vorgekommen ist.

Wie ich schon geschrieben habe: Klassen sind keine Voraussetzung für OOP. Sie sind eine Möglichkeit.
OOP geht problemlos mit nicht typisierten Sprachen, die keine Klassen verwenden.

Ich mache jetzt C++-Forums-Feierband, heute sind keine Antworten mehr von mir zu erwarten.

Jester

Falls Du damit die Frage meinst warum OOP so heißt wie's heißt? Scrub hat's Dir schon gesagt. Aber Du wiederholst nur das was Du die ganze Zeit schon redest und vermutlich hat er ja auch noch bei Dir abgeschrieben.

Ich bestreite den Faktor 5-10. Her mit den Sourcen, dann schaun wir weiter.

.filmor

Das hier höchstvermutlich.

asc

Phoemuex schrieb:

...und definierst das als das einzig und allein von OOP bezeichnete. Das ist aber im üblichen Sprachgebrauch nicht so. Dort ist es nämlich so, dass der Begriff OOP sehr viele verschiedene Dinge wie Kapselung, Polymorphie, Typsicherheit und vor allem die Zusammenlegung von Daten und Funktionen zu einem Datentyp bezeichnet...

Ich würde garnicht erst versuchen mit Xin zu diskutieren, ich habe das einmal erlebt. Er hat seine Meinung und nur die gilt.
Nachtrag: Ein Hoch auf Bjarne Stroustrup, und seinen einfachen und kleinen Satz: "That said, object-oriented programming is a style of programming originating with Simula (about 40 years ago!) relying of encapsulation, inheritance, and polymorphism."

Wofür Xin aber wiederum durchaus nützlich ist, ist für Lektürenreferenzen. Ich kann zwar bislang keiner seiner Textinterpretationen zustimmen, aber Interessantes und Neues gibt es dort immer zu finden. Und als Leseratte lehne ich nie Lektüretips nie ab.

cu André

finix

Xin schrieb:

Bei objektorientiertem Problemstellungen ist der Punkt ja eben, dass die exakte Typ-Information eben nicht zur Compilezeit zur Verfügung steht. Darum OOP, weil Multimethoden eben nicht reichen.

Du missverstehst da was: bei Multimethoden wird in Abhängigkeit von allen Parametern, nicht nur von this/self, dispatched.

Undertaker

asc schrieb:

Nachtrag: Ein Hoch auf Bjarne Stroustrup, und seinen einfachen und kleinen Satz: "That said, object-oriented programming is a style of programming originating with Simula (about 40 years ago!) relying of encapsulation, inheritance, and polymorphism."

http://www.iam.unibe.ch/~denker/old/AlanKayQuotes.html
5te zeile

michba

DEvent schrieb:

Yo lassen wir das, ich geb mich geschlagen. Gibt halt 2 Typen von Programmiern, den einen ist das k egal, weil die schreiben lieber schneller Programme, die portabel sind und lassen das k den Compilerschreibern. Die zweite Sorte investiert Jahre der Forschung um das k gegen Null zu bekommen und wundert sich wieso keiner ihre Programme verwendet (es seih den sie sind zufaellig Compilerschreiber).

@DEvent:
Nur zu deiner Erinnerung: du hast meine Frage, ob es für dich keinen Unterschied macht, ob ein Programm 5s oder 50s läuft, immer noch nicht richtig beantwortet. Oder kann ich aus dem Zitat oben schließen, dass es egal ist, solange das Programm portabel und möglichst schnell entwickelt ist?

Die Fragen von Tim und Jester hast du übrigens auch noch nicht beantwortet.

hui schrieb:

Jester schrieb:

...sei doch ruhig wenn sich Diplominformatiker über Dinge unterhalten ...

Arroganz++

Obwohl es wahrscheinlich sowieso nichts bringt, darauf zu antworten: das ist für mich keine Arroganz von Jester, sondern nur die berechtigte Reaktion auf DEvents Arroganz:

DEvent schrieb:

Zu der Konstante: Es spielt keine Rolle ob ein Algorithmus k langsamer ist als ein anderer. Vielleicht vor 20 Jahren, aber doch nicht heute. Lernt man im ersten Semester bei Komplexistaetslehre (oder halt ein aehnliches Fach).

DEvent schrieb:

Bitte? Ob ein Algo also O(n) ist oder O(n^2) spielt also keine Rolle, aber hauptsache man vergisst die Konstanten nicht? Das sind diese typischen "ich hacke alles in Asm, weil da der Flaschenhals ist"-Leute die hier in RudP nach Hackertipps fragen.

DEvent schrieb:

Gibt halt 2 Typen von Programmiern, den einen ist das k egal, weil die schreiben lieber schneller Programme, die portabel sind und lassen das k den Compilerschreibern. Die zweite Sorte investiert Jahre der Forschung um das k gegen Null zu bekommen und wundert sich wieso keiner ihre Programme verwendet (es seih den sie sind zufaellig Compilerschreiber).

michba schrieb:

Die Fragen von Tim und Jester hast du übrigens auch noch nicht beantwortet.

Ich interpretiere die Nichtbeantwortung dieser fast-rhetorischen Fragen als Antwort auf eben jene

rüdiger

minhen schrieb:

rüdiger schrieb:

Code ist OOP und nicht eine Programmiersprache. Die Programmiersprache kann beim OOP höchstens helfen.

Davon abgesehen, dass du eine Erklärung für deine Aussage schuldig bleibst, erzwingt sie geradezu ein Zitat aus dem Paper, welches Stroustrup bei der OOP-Definition verlinkt:

A language or technique is object-oriented if and only if it directly supports:
[1] Abstraction – providing some form of classes and objects.
[2] Inheritance – providing the ability to build new abstractions out of existing ones.
[3] Run-time polymorphism – providing some form of run-time binding.

Um dir eine Erklärung zu geben, musst du mir erst einmal sagen, was du unter einer objektorientierten Programmiersprache verstehst. Also damit meine ich _nicht_, welche Eigenschaften die Programmiersprache unterstützen muss, sondern das "wie" und das "was bringt es".

"Wie" muss eine Programmiersprache die Eigenschaften anbieten, damit sie als Objektorientiert gilt? Eingebaut in der Sprache? Als Library? Die Möglichkeit sich das alles selbst zu bauen? ...

"Was bringt es" so eine Programmiersprache zu nutzen? Ist der geschriebene Code danach Objektorientiert? Ist es leichter damit objektorientierten Code zu schreiben? ...

(Stroustrup ist zwar ein sehr intelligenter Mensch und hat sehr viel Ahnung von Programmiersprachen-Themen. Aber deshalb ist er nicht mein Vordenker. Einfach nur auf Stroustrup zu verweisen und das als "Gesetz" hinzustellen, erklärt mir auch zu wenig...)

asc

rüdiger schrieb:

Code ist OOP und nicht eine Programmiersprache. Die Programmiersprache kann beim OOP höchstens helfen.

Das würde ich nicht ganz unterschreiben, liegt aber vermutlich mehr an der Formulierung als an dem Inhalt. Ich würde es eher wie folgt sagen:

Code kann unabhängig von der Programmiersprache weitgehend objektorientiert aufgebaut sein. Abhängig von der Programmiersprache kann es aber unterschiedlich gut direkt unterstützt werden. Wenn Sprachen es nicht direkt unterstützen kann es aber sein das ein Teil der Sprachparadigmen nur umständlich oder durch Programmierdisziplin eingehalten werden kann.

Ich nehme mal die insgesamt 4 Begriffe aus der Stelle die ich zitiert habe und der Stelle die minhen zitiert hat:

Abstraktion
Vererbung
Polymorphie
Datenkapselung

rüdiger schrieb:

"Wie" muss eine Programmiersprache die Eigenschaften anbieten, damit sie als Objektorientiert gilt? Eingebaut in der Sprache? Als Library? Die Möglichkeit sich das alles selbst zu bauen? ...

Damit ich eine Sprache Objektorientiert nenne, muss sie die Prinzipien auf möglichst direkte Weise umsetzen, sprich: möglichst ein Sprachfeature sein. Andernfalls kann man vielleicht sagen das die Sprache eine OO-Erweiterung hat, sie selbst ist aber nicht OO.

rüdiger schrieb:

"Was bringt es" so eine Programmiersprache zu nutzen? Ist der geschriebene Code danach Objektorientiert? Ist es leichter damit objektorientierten Code zu schreiben? ...

Das kommt darauf an wie weit die Sprache OO als optionales oder als erzwingendes Feature einsetzt. Ja, man kann auch einen Backstein zu anderen Dingen missbrauchen als damit ein Haus zu bauen, ebenso wie man selbst dann, wenn eine Sprache OO zu erzwingen versucht, nicht zwangsweise OO-Programmiert. Es ist nur deutlich leichter.

Und ja, auch ich denke wenn ich OOP höre nicht als erstes an C++. C++ ist nicht rein OO, eher würde ich schon an sowas wie C# denken, was zumindest schon mehr OO zu erzwingen versucht.

Nur habe ich Schwierigkeiten mir z.B. ein C-Programm objektorientiert vorzustellen. Wo kann man dort bitte schön orientiert an einem Objekt programmieren und gleichzeitig die vier oben genannten Punkte erfüllen.
Ja, gehen tut das vielleicht, aber in Teilen nur dann, wenn der Programmierer bestimmte Dinge explizit berücksichtigt, die er bei anderen Sprachen direkt umsetzen kann (Datenkapselung nur als kleines Beispiel). Ein Objekt soll seine interen Statis nach außen verbergen können.

So um jetzt wieder auf das Thema zurückzukehren: Durch eine Objektorientierte Stuktur hat man IMHO in kleinen Projekten immer einen Performancenachteil, die Frage ist aber ob in der Gesamtheit die Strukturierung nicht mehr ausmacht.

Vom Prinzip ist C++ so geplant das es nur minimal langsamer als C ist (10%) und als das Exceptionhandling dazukam wurde hier auch nochmal ein Performancemalus eingeplant (weitere 10%). Ich glaube die Zahlen habe ich noch als Erinnerung aus dem Buch "Die C++ Programmiersprache". Was man natürlich berücksichtigen muss ist, das ein OO-Programm DURCH die OO-Paradigmen in der Regel nochmal etwas langsammer wird. Jetzt aber die Frage: Wenn ein Programm komplexer wird und schwerer zu überschauen ist, kann dann die C-Programmierung tatsächlich immer punkten oder kann hier die OO-Programmierung ggf. sogar Vorteile ausspielen.

Ja, wenn man beide optimiert ist das C-Programm wohl wieder schneller, ich sehe hier aber auch immer noch einen weiteren Faktor: Aufwand. In der Praxis ist meines Erachtens immer eine Balance zwischen den Extremen sinnvoll (Ausnahmen gibt es, z.B. Embedded Systems, Realtime Programming...).

cu André

rüdiger

asc schrieb:

Wenn Sprachen es nicht direkt unterstützen kann es aber sein das ein Teil der Sprachparadigmen nur umständlich oder durch Programmierdisziplin eingehalten werden kann.

"Disziplin"? Wenn ich dich richtig verstehe, braucht man das auch bei Sprachen, die OOP gut unterstützen. Man kann ja mit jeder Programmiersprache nicht OO-Code schreiben.

Damit ich eine Sprache Objektorientiert nenne, muss sie die Prinzipien auf möglichst direkte Weise umsetzen, sprich: möglichst ein Sprachfeature sein. Andernfalls kann man vielleicht sagen das die Sprache eine OO-Erweiterung hat, sie selbst ist aber nicht OO.

Warum "Erweiterung"? Die Möglichkeit ist doch in der Sprache vorhanden.

Das kommt darauf an wie weit die Sprache OO als optionales oder als erzwingendes Feature einsetzt. Ja, man kann auch einen Backstein zu anderen Dingen missbrauchen als damit ein Haus zu bauen, ebenso wie man selbst dann, wenn eine Sprache OO zu erzwingen versucht, nicht zwangsweise OO-Programmiert. Es ist nur deutlich leichter.

Also hilft die Sprache einem beim OOP?

Und ja, auch ich denke wenn ich OOP höre nicht als erstes an C++. C++ ist nicht rein OO, eher würde ich schon an sowas wie C# denken, was zumindest schon mehr OO zu erzwingen versucht.

Bei OOP denke ich eher an Ruby oder Smalltalk

Nur habe ich Schwierigkeiten mir z.B. ein C-Programm objektorientiert vorzustellen. Wo kann man dort bitte schön orientiert an einem Objekt programmieren und gleichzeitig die vier oben genannten Punkte erfüllen.
Ja, gehen tut das vielleicht, aber in Teilen nur dann, wenn der Programmierer bestimmte Dinge explizit berücksichtigt, die er bei anderen Sprachen direkt umsetzen kann (Datenkapselung nur als kleines Beispiel). Ein Objekt soll seine interen Statis nach außen verbergen können.

Gerade in C kann man das alles wunderbar emulieren. Vor ein paar Monaten habe ich mal in einer ähnlichen Diskussion ein C-Programm geschrieben, das sowohl Vererbung, Datenkapselung, Polymorphie und Abstraktion benutzte. Schau dir auch mal Objective C an. Das ist ja nur ein Preprozessor. Der spuckt einem ja OO-C-Code aus.

So um jetzt wieder auf das Thema zurückzukehren

Ich glaube nicht das OOP allgemein einen Performance-Nachteil hat. Die bereits angesprochenen "Kosten" von virtuellen-Funktionen hat man ja auch auf irgend eine Art und Weise, wenn man sie mit anderen Mitteln nachstellt. Nicht-Virtuelle Vererbung und Objekte kosten ja (in C++) nichts. Aber virtuelle-Vererbung ist in C++ ja ohnehin out.

hustbaer

@Xin:
Ich möchte hier genau auf eines antworten, nämlich hierraus (sonst wird mir das zu langwierig):

Xin schrieb:

Benutzt man kein virtual, wird die Nachricht nicht an das Objekt geschickt, sondern an die Klasse, die auf das Objekt zeigt.

Wo ist der Unterschied ob ich an einer bestimmten Stelle in einem Programm eine Nachricht an ein Objekt schickt oder "an seine Klasse", wenn die Klasse an der Stelle garantiert genau bekannt ist?

Einen Unterschied kann es IMO nur dann geben wenn man ganz auf Klassen verzichtet (denn dann KANN die Klasse des Objektes ja nicht bekannt sein, da es sie ja garnicht gibt). Das hat zugegebenermassen einige Vorteile, u.A. kann man dann quasi genau das was man braucht "dynamisch zusammenbasteln", aber ich kenne eigentlich niemanden von dem ich wüsste dass er den Begriff "OOP" so auslegt.

minhen

Mr. N schrieb:

minhen schrieb:

Xin argumentiert zwar als einziger hier überzeugend

Schön, dass du den ganzen Thread gelesen hast.

Freut mich, dass du es schön findest.

loks schrieb:

Falsch. In dem verlinkten Text von Stroustrup redet dieser von der C++ Sprache und _nicht_ von C++-Code. Er definiert dort erstmal nur ab wann sich eine Programmiersprache als Objektorientiert bezeichnen darf.

Das ist doch lächerlich. Du hast den verlinkten Text doch überhaupt nicht gelesen sondern nur das, was ich unten zitiert hatte. Und das stammte nicht aus dem verlinkten Text sondern aus einem Paper, welches dort angegeben ist. Was dagegen im verlinkten Text steht ist:

That said, object-oriented programming is a style of programming (...) relying of encapsulation, inheritance, and polymorphism. In the context of C++ (...), it means programming using class hierarchies and virtual functions (...)

Im verlinkten FAQ-Eintrag redet er also vom Programmieren - OOP - und nicht von Spracheigenschaften.

Wenn du meinst etwas kommentieren zu müssen, speziell wenn du dir einbildest widersprechen zu müssen, ist es wohl wirklich das Mindeste den Kram auch durchgelesen zu haben.

Jester schrieb:

Mich wundert ehrlich gesagt was Du als überzeugend ansiehst. Er behauptet irgendwelche Dinge, geht auf keine Argumente ein. Standard-Definitionen bzw. Referenzen auf diese werden damit abgebügelt, dass man ja offensichtlich nicht in der Lage sei sich kritisch mit den Sachen auseinanderzusetzen. Das überzeugt mich zwar auch, aber von anderen Dingen als vom Autor vorgesehen.

Xin hat eine präzise Definition vorgebracht und diese schlüssig begründet. Seine Definition ist minimal und damit sehr aussagekräftig. Damit erfüllt sie bereits eines der wichtigsten Brauchbarkeits-Kriterien. Das können andere Vorschläge hier bereits nicht mehr von sich behaupten. Die Schwammigkeit der anderen Vorschläge ist sogar deren Verfechtern hier, wie sie sogar selbst sagen, völlig klar. Schwammigkeit aber ist mit großem Abstand mit das Schlimmste, was einer Definition überhaupt passieren kann. Insofern ist Xins Definition diesen bereits von einem rein formalen Standpunkt aus überlegen.
Dazu kommt, dass er darlegt was ein Objekt ist und weshalb es in seiner Definition der zentrale Bestandteil ist, was wiederum die Begründung für den Begriff objekt-orientiert liefert. Dadurch ist die Definition nicht nur formal brauchbar sondern auch inhaltlich schlüssig (ohne schwammig zu werden) und dadurch überzeugend.
Xins Kritik an anderen Definitionen basiert ebenfalls auf den positiven Aspekten seiner eigenen Definition. So sind seine Angriffspunkte immer mangelnde Präzision (also Schwammigkeit) und mangelnde Aussagekraft (praktisch alles wäre OO).
Eine überzeugende Argumentation eben. Das wird vielleicht deutlicher wenn man sich die Angriffe der Gegenseite ansieht. Denn diese basieren dann doch zu einem großen Teil auf "Ich sage XYZ ist objektorientiert und das wäre es mit deiner Definition nicht. Folglich ist deine Definition schlecht." Ich hoffe es ist sofort einsichtig, warum Argumentationen die sich auf ein derartiges Schema bringen lassen, wenig überzeugend wirken. Die von dir angeführten "Standard-Referenzen" wiederum verleihen zwar Gewicht - machen aber nicht überzeugender. Oder warum gibst du dich nach dem Verweis auf eine Größe wie Bjarne Stroustrup nicht geschlagen? Eben. Darüber hinaus hat Xin sogar erklärt weshalb er "Standard-Referenzen" nicht einfach so akzeptiert - und zwar mit Grundregeln der Logik.

rüdiger schrieb:

"Wie" muss eine Programmiersprache die Eigenschaften anbieten, damit sie als Objektorientiert gilt? Eingebaut in der Sprache? Als Library? Die Möglichkeit sich das alles selbst zu bauen? ...

Auf die Sprachen selbst bezogen sagt er dazu im Paper:

A language or technique is object-oriented if and only if it directly supports:
[1] Abstraction – providing some form of classes and objects.
[2] Inheritance – providing the ability to build new abstractions out of existing ones.
[3] Run-time polymorphism – providing some form of run-time binding.

Eine Sprache ist also dann objektorientiert, wenn sie die drei Konzepte (Kapselung, Vererbung, Laufzeit-Polymorphie) direkt unterstützt. Unterstützung bedeutet, dass entsprechende Hilfsmittel in der Sprache verfügbar sind. Man muss sie sich also nicht selbst bauen. Direkt kann nur bedeuten, dass diese Hilfsmittel unmittelbarer Bestandteil der Sprache sein müssen. Folglich macht weder die Möglichkeit Objekt-Orientierung selbst zu bauen noch eine externe, objektorientierte Library eine Sprache objektorientiert.

Die logische Konsequenz ist, dass man keine objekt-orientierte Sprache benötigt um objekt-orientiert zu programmieren.

"Was bringt es" so eine Programmiersprache zu nutzen? Ist der geschriebene Code danach Objektorientiert? Ist es leichter damit objektorientierten Code zu schreiben? ...

Dazu sagt Stroustrup im verlinkten Paper, dass eine objekt-orientierte Sprache OOP einfacher und effizienter nutzbar macht. Und diese Vorteile von OOP beschreibt er in der FAQ wie folgt:

... to allow manipulation of objects of a variety of types through well-defined interfaces and to allow a program to be extended incrementally through derivation.

Der Vorteil von OOP ist es also verschiedene Objekte mit definierten Schnittstellen ansprechen zu können, sowie die Möglichkeit Programme bequem inkrementell erweitern zu können. Wichtig ist, dass hier kein Wort davon fällt, bestehenden Code ändern zu müssen. Damit ist auch klar weshalb Polymorphie ein unentbehrlicher Bestandteil von OOP ist.

Nebenbei verweist er auch darauf, dass manchmal u.a. auch im objekt-orientierten C++ Programmierung mit "plain classes" für ein Problem besser ist. Das, sowieo was er sonst noch so sagt, legt nahe, dass er der vernünftigen Auffassung ist, dass die Verwendung einer objekt-orientierten Programmiersprache noch lange nicht per se objekt-orientierte Programmierung bedeutet.