Performancemythen?
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
-
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é
-
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.
-
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
-
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
-
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...)
-
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é
-
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.
-
@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.
-
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.
-
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).Nun musst du aber auch anerkennen, dass die Gegenseite ausserhalb dem Verweis auf Standarddefinition einen schlechten Stand hat. Unsere Definition ist die eines Objektes aus dem normalen Sprachgebrauch und das Übertragen dieser Objekte und ihren abhängigkeiten auf die Ebene des Programmcodes ist nunmal nicht formal eindeutig definierbar. Das fängt schon damit an, dass der Begriff "Objekt" im allgemeinen Sprachgebrauch nicht eindeutig definiert ist:
Objekt bezeichnet:* allgemein etwas unspezifiziertes, siehe Sache, Gegenstand, Ding* im Sinne der Dialektik das, worauf ein Subjekt seine beobachtende, sinnliche, empirische und praktisch-verändernde Aktivität richtet
Brockhaus:
- allg: Gegenstand, mit dem etwas geschieht oder geschehen soll
- Philosophie:[...] In der modernen Sprachphilosophie und in der Logik wird all das als Objekt genannt, was sprachlich unterschieden werden kann
Im Sinne dieser Objekt definition zählt nur das denken in Objekten und das Übertragen dieser Denkweise in den Code. Das bedeutet aber nicht, dass jeder Code direkt OOP ist, denn es besteht einen unterschied zwischen: "Objekt a ruft methode foo von Objekt b auf" und "erst wird foo aufgerufen, dann bar und wenn x=5 gilt dann wird noch fubar aufgerufen". Wie das am Ende im Code umgesetzt wird, ist absolut Sprachabhängig. kennt die Sprache keine methoden, dann müssen normale Funktionen dafür herhalten(bei File:"Ich öffne das DateiObjekt mit open").
Ich hoffe, nun wurde klar, wieso Xins argumentation für mathematiker/logiker besser wirken muss, seine Definition hat die Problemstellung so eingeschränkt, dass der letzte gültige Teilaspekt, oh wunder, eindeutig definierbar ist.
Und der Gegenseite bleibt nur zu sagen: Dies schließt aber extrem viele Fälle aus. Nur, wie soll man weiter gegen irgendwas argumentieren was teil der eigenen definition ist? es ist nunmal nicht wegdiskutieren, dass Polymorphie ein Teil der OOP ist. Uns bleibt nur, rein wissenschaftlich argumentativ, die Fälle aufzuzeigen, die nach unserer Definition OOP sind(völlig begründet, aber darauf geht Xin nicht ein, auch typisch wissenschaftlich), aber von Xins Definition nicht eingeschlossen werden. Solange er aber auf diese Fälle nicht eingeht, zb warum statische Polymorphie kein OOP ist, können wir auch nicht weiter argumentieren.btw: zum von .filmor geposteten link. Also wenn das der Code ist, mit dem du getestet hast, dann wundert mich das nicht wirklich.
1. im C-Code wird ne hash-map genutzt, im C++ Code ein RB-Baum. Also am Ende O(1) vs O(log N)
2. sprintf vs C++ streams. Da sind die streams deutlich langsamer, weil sie eine andere Philosophie haben. Damit sind die beiden Sachen kein analogon.
3. Die Deque im C++ teil kommt mir Spanisch vor, muss aber auch gestehen, dass ich bei diesen Variablennamen und der nicht vorhandenen Dokumentation nicht 100% genau verstehe, was der author da vor hat zu machen, zumal der testlauf des C++ Codes nur wieder das ausgegeben hat, was ich zuerst eingegeben habe.
-
Xin legt einfach willkürlich fest, daß es "der Algorithmus" zu sein habe, der "sich am Objekt" orientiert.
Übersetzt man OOP wörtlich, steht da aber als letztes "Programmierung", nicht "Algorithmus". Die ganze Programmierung muß sich also an Objekten orientieren. Und jetzt definier mal, was "sich an etwas orientieren" exakt bedeutet, darauf bin ich sehr gespannt.
