Performancemythen?

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.

otze

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:

de.wikipedia.org/wiki/Objekt

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.

Uiuiui, hab grade den Fehler gemacht, den von otze genannten Thread mal durchzulesen. Au Backe...

Auf Schreibfehlern anderer herumreiten, wo man doch selbst auf seiner HP und in seinen Beiträgen am laufenden Band Patzer reinbaut
Ständig nebenbei alle anderen abqualifizieren
Ständig das Böse aller anderen vorwegnehmen (-> Arroganz?)
"Weder Datenkapselung noch Klassen sind für OOP nicht erforderlich. Schau Dir mal die Implementierung von "virtual" und überlege Dir, warum OOP nicht "datengekapselte-Programming" oder "klassenbasierte Programming" oder "Datenvererbende Programming" heißt." Schwammiger kann man sich nicht ausdrücken, oder?

Mein Gott, Walter.

asc

minhen schrieb:

Eine Sprache ist also dann objektorientiert, wenn sie die drei Konzepte ... direkt unterstützt. Unterstützung bedeutet, dass entsprechende Hilfsmittel in der Sprache verfügbar sind... 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.

Also irgendwie wiedersprichst du dir hierbei. Wenn ich deinen ersten Abschnitt betrachte würde mir als logische Konsequenz nur bleiben zu sagen: Um OOP zu betreiben bedarf es einer OO-Sprache.

cu André

Simon2

Undertaker schrieb:

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

Die 3. steht aber noch davor und ist aber auch schön, oder ?

Undertaker

Simon2 schrieb:

Undertaker schrieb:

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

Die 3. steht aber noch davor und ist aber auch schön, oder ?

grrrr.....

TheTester

asc schrieb:

minhen schrieb:

Eine Sprache ist also dann objektorientiert, wenn sie die drei Konzepte ... direkt unterstützt. Unterstützung bedeutet, dass entsprechende Hilfsmittel in der Sprache verfügbar sind... 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.

Also irgendwie wiedersprichst du dir hierbei. Wenn ich deinen ersten Abschnitt betrachte würde mir als logische Konsequenz nur bleiben zu sagen: Um OOP zu betreiben bedarf es einer OO-Sprache.

cu André

Eben nicht, minhen unterscheidet zwischen dem Konzept der OOP und einer objekt-orientierten Sprache. Das Konezpt der OOP ist unabhängig von der Sprache, eine Sprache jedoch wird zur OOP Sprache wenn sie das Konzept der OOP auf irgendeine Art direkt implementiert. Das heisst jedoch nicht das man nicht in einer Nicht-OOP Sprache nicht auch OOP Konzepte verwenden kann, die Sprache unterstützt dich hierbei nur nicht.

tt

asc

TheTester schrieb:

Eben nicht, minhen unterscheidet zwischen dem Konzept der OOP und einer objekt-orientierten Sprache. Das Konezpt der OOP ist unabhängig von der Sprache, eine Sprache jedoch wird zur OOP Sprache wenn sie das Konzept der OOP auf irgendeine Art direkt implementiert. Das heisst jedoch nicht das man nicht in einer Nicht-OOP Sprache nicht auch OOP Konzepte verwenden kann, die Sprache unterstützt dich hierbei nur nicht.

Ich wiederspreche dem nicht, aber in der Konstellation wie er (minhen) es geschrieben hat, hätte ich nicht seinen logischen Schluß ziehen können.

cu André

Jester

minhen schrieb:

Darüber hinaus hat Xin sogar erklärt weshalb er "Standard-Referenzen" nicht einfach so akzeptiert - und zwar mit Grundregeln der Logik.

Das ist schlicht nicht wahr. Aber das kann ja jeder selbst nachlesen.

Ich weiß auch nicht was Dich an der Definition so begeistert. Klar okay, sie ist einfach. Ich würde sagen, sie ist sogar so stupide trivial, dass sie sich für garnichts eignet. Das ist natürlich prima und eine wichtige Voraussetzung für eine gute Defintion.

Aber was bringt mir diese Definition? Es geht doch darum eine ganze Menge von Techniken zu einer gemeinsamen Methodik zusammenzufassen. "Wenn virtual benutzt wird isses OOP, sonst nicht" ist zwar prima, wenn ich algorithmisch entscheiden möchte, ob ein gegebener Source OO ist. Aber das ist eigentlich nicht das was man sich von dieser Definition erhofft.

Abgesehen davon, dass er sich ja nicht am Objekt, sondern am Typen des Objekts orientiert. Müßte es da nicht streng genommen OTOP also Objekt-Typ orientierte Programmierung heißen?

Ich verrat's jetzt einfach mal: OOP heißt Objekt-orientierte Programmierung, weil man sich an Objekten orientiert: Sie stellen die zentrale Abstraktionsmöglichkeit bereit, Systeme werden dadurch beschrieben, welche Objekte es gibt, welches Verhalten diese modellieren und wie diese miteinander interagieren. Objekte tauchen gleichermaßen in der Modellierung wie in der Implementierung auf. Und weil sie eben bei dieser Methode so häufig vorkommen und so zentral sind heißt sie Objektorientiert.

Helium

Xin schrieb:

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.

Multimethoden dispatchen auch erst zur Laufzeit, da dort auch erst zur Laufzeit die Typ-Information vorhanden ist und nicht zur Compilezeit. Darum geht es doch gerade bei Multimethoden.

Beispiel:

(defmethod collide-with ((x asteroid) (y asteroid))
  ;; deal with asteroid hitting asteroid
)
(defmethod collide-with ((x asteroid) (y spaceship))
  ;; deal with asteroid hitting spaceship
)
(defmethod collide-with ((x spaceship) (y asteroid))
  ;; deal with spaceship hitting asteroid
)
(defmethod collide-with ((x spaceship) (y spaceship))
  ;; deal with spaceship hitting spaceship
)

Zur Compile-Zeit habe ich keine Typinformationen. Erst zur Laufzeit kann entschieden werden, welche der Methoden denn jetzt aufgerufen werden kann und zwar wird anhand beider Argumente dispatched.