Performancemythen?
-
Shade Of Mine schrieb:
Eine Klasse kann ein Objekt sein - sie muss aber nicht.
doch ist ein Object schrieb:
Undertaker schrieb:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html :p
tja, da seht ihr's....
-
Xin schrieb:
1. Nicht dazuerfunden. Der implizite Parameter ist nicht erfunden, er wird in der Regel mit "this" bezeichnet.
Ich sagte nicht, dass Du den Parameter dazuerfunden hättest, sondern dass Du dazuerfunden hast, dass dieser bei mir eine wichtige Rolle spielt. Ich berufe mich nicht auf den ersten Parameter. Das ist Deine eigene Erfindung bzw. Einbildung.
edit: achso, er hat's aufgegeben oder eingesehen... na dann. auch gut!
-
this->that schrieb:
Gabs die letzten 40 Seiten irgend ne brauchbare Erkenntnis?
Es gab sicher ein paar nette Informationen, die aber leider in der Trollerei von Xin untergegangen sind.
-
Das erstaunt mich immer wieder, dass in diesem Forum so endlos lange über total banale und überflüssige Dinge diskutiert wird, wobei am Ende eh nichts rauskommt^^
-
this->that schrieb:
Das erstaunt mich immer wieder, dass in diesem Forum so endlos lange über total banale und überflüssige Dinge diskutiert wird, wobei am Ende eh nichts rauskommt^^
solange alle beteiligen ihren spass dran haben, ist es doch okay...
-
Ich bezweifle stark, dass alle wirklich Spaß daran haben.
-
Das Problem mit der Performance ist, dass sehr viele Leute auf verdacht optimieren. Der am besten optimierte Code bringt nix, wenn er nur 1% der Laufzeit ausmacht.
-
Bin jetzt auf Seite 37:
Shade Of Mine schrieb:
Beide Codes machen exakt dies. Für Leute wie dich, die nur Java/C++ kennen ist die Idee kein Interface zu haben erschreckend. Für Leute die nur JavaScript kennen ist die Idee ein Interface Energiequelle zu haben erschreckend.
Das stimme aber nicht.
Shade Of Mine schrieb:
Ich kann in JavaScript garkeine "Klasse" Energiequelle einbauen - die Sprache würde es nicht unterstützen - ich müsste hacks verwenden damit das halbwegs gut läuft.
Was bei diesem Code aber viel wichtiger ist, ist nicht die Implementierung - denn die Implementierung hängt sowieso komplett von der Plattform ab. Mehr dazu weiter unten.
Das wichtige ist die Idee und die Aussage des Codes. Beide lösen ein Problem:
Ich habe eine Lampe und habe unendlich viele Energiequellen die ich beliebig kombinieren will.In JS und bei der Template Programmierung hast du eine Lampe und die kannst du mit allem kombinieren, nicht nur mit Energiequellen.
Genauso an otze, wo ist den die Beziehung Klasse2 ist eine Klasse1 bei dem Templates?
Seite 38
Jester schrieb:
Hm, das muß ich bis jetzt überlesen haben. Wo definiert er, was ein Objekt ist? Soweit ich das überblicke verwendet er diesen Begriff als Blackbox. Im Gegenzug haben hier einige schon erklärt was ein Objekt sein soll und das Konzept OOP dann dadurch beschrieben, dass Objekte verwendet werden. Zudem unterscheiden wir uns in der Auslegung des Begriffs "Beziehung zwischen Objekten". Für Xin muß diese Beziehung (warum auch immer) Vererbung bedeuten. Andere wollen da auch Komposition und Aggregation dazuzählen. Was ist daran nun unpräzise und mystisch?
Tolle Definition. OOP ist also wenn man irgendwas mit Objekten macht. Was macht man den damit? Wieso macht man es mit ihnen? Und welche Techniken werden dabei verwendet?
Wieso sollte ein Objekt keine "Blackbox" sein? Ein Object ist sogar eine "Blackbox", weil ich die interne Implementierung nicht sehen kann.
Edit: Grad gelesen das Xin den Thread aufgibt. Dann schaffen wir die 50 Seiten wohl nicht mehr...
-
DEvent schrieb:
Bin jetzt auf Seite 37:
Shade Of Mine schrieb:
Beide Codes machen exakt dies. Für Leute wie dich, die nur Java/C++ kennen ist die Idee kein Interface zu haben erschreckend. Für Leute die nur JavaScript kennen ist die Idee ein Interface Energiequelle zu haben erschreckend.
Das stimme aber nicht.
Dann erklär mir den Unterschied.
In JS und bei der Template Programmierung hast du eine Lampe und die kannst du mit allem kombinieren, nicht nur mit Energiequellen.
Genauso an otze, wo ist den die Beziehung Klasse2 ist eine Klasse1 bei dem Templates?
Ich sehe da das Problem nicht. Warum ist es falsch zu sagen "alles was sich wie eine Energiequelle verhält, ist eine Energiequelle". Warum soll das falsch sein?
-
Was macht man den damit? Wieso macht man es mit ihnen? Und welche Techniken werden dabei verwendet?
1. man macht das, was das objekt an funktionalität anbietet.
2. Wieso schreibt man programme?
3. Welche Techniken benutzt ein Künstler?Genauso an otze, wo ist den die Beziehung Klasse2 ist eine Klasse1 bei dem Templates?
Diese beziehung hab ich garnicht im UML diagramm dargestellt und bei der version mit abstraktet basisklasse gibts das auch nicht.
Was wolltest du nochmal trollen?
Wieso sollte ein Objekt keine "Blackbox" sein? Ein Object ist sogar eine "Blackbox", weil ich die interne Implementierung nicht sehen kann.
genau das sagen wir doch auch. Stichwort Kapselung. Wenn du das auf den member in meinem beispiel beziehst: Die implementation ist ja völlig unabhängig davon, aber wenn eine Klasse im Konstruktor ein objekt übernimmt um es später nutzen zu können, dann muss es logischerweise auch gespeichert werden. Wie es das am Ende tut ist völlig egal, in den beiden Codeschnipseln wars ja auch einmal ein Objekt, einmal ein Zeiger. Das Objekt muss nichtmal intern als member existieren, es wird nur verdeutlicht, dass der Zustand des Objektes in dieser Form erhalten bleiben muss.
-
otze schrieb:
Diese beziehung hab ich garnicht im UML diagramm dargestellt...
weil wir gerade bei UML sind: es gibt da so ein nettes tool --> http://modeling.telelogic.com/products/rhapsody/software/index.cfm
das kann aus UML diagrammen (object, state chart, class und so'n zeug) C code erzeugen, den man dann durch einen compiler jagen kann (wohlgemerkt, ich meine C, nicht C++). wenn man sowas benutzt, ist das dann OOP oder nicht?
@Xin: was meinst du?
-
DEvent schrieb:
Was macht man den damit? Wieso macht man es mit ihnen? Und welche Techniken werden dabei verwendet?
LOL willst du nun Xins Position übernehmen?
Seit wann sind die von dir genannten Punkte Bestandteil einer Definition?
-
Definition heisst Abgrenzung. Ohne solche Fragen kommt sowas raus :
Wer auch immer schrieb:
... erklärt was ein Objekt sein soll und das Konzept OOP dann dadurch beschrieben, dass Objekte verwendet werden.
Andere wollen da auch Komposition und Aggregation dazuzählen.
OOP ist also wenn man irgendwas mit Objekten macht.
Da wird es schwer eine Grenze zur "Strukturierten Programmierung" oder zu was sich sonst noch alles ausgedacht wurde (wird) zu finden.
-
DEvent schrieb:
Seite 38
Jester schrieb:
Hm, das muß ich bis jetzt überlesen haben. Wo definiert er, was ein Objekt ist? Soweit ich das überblicke verwendet er diesen Begriff als Blackbox. Im Gegenzug haben hier einige schon erklärt was ein Objekt sein soll und das Konzept OOP dann dadurch beschrieben, dass Objekte verwendet werden. Zudem unterscheiden wir uns in der Auslegung des Begriffs "Beziehung zwischen Objekten". Für Xin muß diese Beziehung (warum auch immer) Vererbung bedeuten. Andere wollen da auch Komposition und Aggregation dazuzählen. Was ist daran nun unpräzise und mystisch?
Tolle Definition. OOP ist also wenn man irgendwas mit Objekten macht. Was macht man den damit? Wieso macht man es mit ihnen? Und welche Techniken werden dabei verwendet?
Wieso sollte ein Objekt keine "Blackbox" sein? Ein Object ist sogar eine "Blackbox", weil ich die interne Implementierung nicht sehen kann.
Devent, lass es... es sind die richtigen Fragen, aber die falschen Adressaten. Nimm sie mit und finde selbst logische Antworten.
Jemand sagte mir vorhin, dass dies hier eine religiöse Frage ist und derjenige hat recht. Selbiges wäre passiert, wenn Du als Windowsuser in ein Linux-Forum gehst und verkündest, dass es für Windows mehr Software gibt. Wo es mehr Software gibt spielt dort keine Rolle, gekreuzigt wirst Du sowieso.
Ein Ergebnis in diesem Thread interessiert mich genausowenig wie die Freundlichkeiten, die mir zur Zeit noch nachgereicht werden. Wenn man nicht mehr mitmacht, liest er sich sogar ganz amüsant.
Mich hätte hier lediglich Marc++us Definition noch interessiert. Ich gehe nicht davon aus, dass er mir zustimmt, weil meine Definition braucht man nicht zu binden, da tun es auch ein, zwei Blätter. Ich gehe aber davon aus, dass wenn er schon ein Buch schreibt, er sich ebenfalls intensiver mit dem Thema beschäftigt hat und entsprechend schärfere Definitionen benutzt.
-
hurra ich hab gewonnen, xin verloren
rüdiger schrieb:
Du bist wirklich Arrogant und eingebildet
und diesmal ist sogar rüdiger der gleichen meinung wie ich
ps: xin warum hast du nicht direkt gesagt du kommst von der FH das hatte so einigen glaub ich auch gut zeit gespart
-
@DEvent: schau dir mal eine dynamisch typisierte sprache wie eben javascript oder so an dann sollte sich dein missverstehen zu shades posts wohl klären
-
Nur weil man die innere Struktur eines Objekts als "Blackbox" betrachtet, folgt daraus noch keine Undefiniertheit, sofern man angibt wie das Objekt von außen aussieht.
Xin schrieb:
Mich hätte hier lediglich Marc++us Definition noch interessiert. Ich gehe nicht davon aus, dass er mir zustimmt, weil meine Definition braucht man nicht zu binden, da tun es auch ein, zwei Blätter. Ich gehe aber davon aus, dass wenn er schon ein Buch schreibt, er sich ebenfalls intensiver mit dem Thema beschäftigt hat und entsprechend schärfere Definitionen benutzt.
Marcus bezeichnet (Laufzeit-)Polymorphie in seinem Buch als "wesentliches Merkmal der objektorientierten Programmierung". Laufzeit-Polymorphie macht also das Wesen von OOP aus. Genauer wird er nicht - und OOP definiert er schon gleich gar nicht konkret. Aber man kann bei Sätzen wie "Das ist zwar schon schön C++, weil es Klassen verwendet. Aber es ist nicht objektorientiert" schon etwas vermuten. Zumal ein Abschnitt "Streiche switch, setze virtual" mit einem Merksatz "Nicht überall, wo Klasse draufsteht, ist auch Objektorientierung drin" endet. Die Lösung, um aus nicht objektorientiertem Code eben objektorientierten zu machen, lautet in dem Abschnitt nämlich: virtual.
-
Overtaker schrieb:
hurra ich hab gewonnen, xin verloren
So schnell wird aus "unserer Definition" ein "ich habe gewonnen".
Geschichten schreiben Sieger. Wer einen Phyrrussieg erringt hat die Schlacht gewonnen, war aber doch unterlegen.
Ich gratuliere zu Deinem ganz persönlichem Erfolg.Overtaker schrieb:
rüdiger schrieb:
Du bist wirklich Arrogant und eingebildet
und diesmal ist sogar rüdiger der gleichen meinung wie ich
Hehehe, ihr sollten den Thread mal lesen.
Wenn Jester loszieht und behauptet, Menschen die nicht seiner Meinung sind, sollten sich raushalten wenn Dipl.Infs sich unterhalten, ist das nicht arrogant.Overtaker schrieb:
ps: xin warum hast du nicht direkt gesagt du kommst von der FH das hatte so einigen glaub ich auch gut zeit gespart
Hehehe und Du findest mich arrogant?
Lies mal nach, was arrogant bedeutet.Und wieder einmal sei darauf hingewiesen, dass Du nur lesen braucht, was ich schreibe. Ich habe aus dem (FH) kein Geheimnis gemacht. Da einige hierzu nicht in der Lage sind, habe ich den Thread verlassen.
minhin schrieb:
Xin schrieb:
Mich hätte hier lediglich Marc++us Definition noch interessiert. Ich gehe nicht davon aus, dass er mir zustimmt, weil meine Definition braucht man nicht zu binden, da tun es auch ein, zwei Blätter. Ich gehe aber davon aus, dass wenn er schon ein Buch schreibt, er sich ebenfalls intensiver mit dem Thema beschäftigt hat und entsprechend schärfere Definitionen benutzt.
Marcus bezeichnet (Laufzeit-)Polymorphie in seinem Buch als "wesentliches Merkmal der objektorientierten Programmierung". Laufzeit-Polymorphie macht also das Wesen von OOP aus.
Was in C++ durch virtuelle Funktionen erreicht wird...
minhin schrieb:
Genauer wird er nicht - und OOP definiert er schon gleich gar nicht konkret. Aber man kann bei Sätzen wie "Das ist zwar schon schön C++, weil es Klassen verwendet. Aber es ist nicht objektorientiert" schon etwas vermuten. Zumal ein Abschnitt "Streiche switch, setze virtual" mit einem Merksatz "Nicht überall, wo Klasse draufsteht, ist auch Objektorientierung drin" endet. Die Lösung, um aus nicht objektorientiertem Code eben objektorientierten zu machen, lautet in dem Abschnitt nämlich: virtual.
Ich denke, dass das es im Bezug auf C++ kaum genauer geht.
Danke für die Ausschnitte, ich habe das Buch leider noch nicht, aber es ist meiner To-Buy-Queue (schon vor dem Thread)
-
Xin schrieb:
Overtaker schrieb:
rüdiger schrieb:
Du bist wirklich Arrogant und eingebildet
und diesmal ist sogar rüdiger der gleichen meinung wie ich
Hehehe, ihr sollten den Thread mal lesen.
Wenn Jester loszieht und behauptet, Menschen die nicht seiner Meinung sind, sollten sich raushalten wenn Dipl.Infs sich unterhalten, ist das nicht arrogant.Niemand hat behauptet, dass Jester nicht arrogant wäre. Das ändert doch nichts für dich.
-
Xin schrieb:
Was in C++ durch virtuelle Funktionen erreicht wird...
... was jedem hier wohl klar ist.
Ich denke, dass das es im Bezug auf C++ kaum genauer geht.
Der Punkt ist, dass er weder explizit OOP definiert noch explizit sagt, dass es in C++ dieses und jenes bedeutet. Es folgt nur implizit aus dem, was er sagt und wie er vorgeht.
Schön ist zum Beispiel auch, wie er in einem Kapitel OOP in C zeigt. Denn das macht er indem er zunächst Klassen, dann Vererbung und schließlich Laufzeit-Polymorphie in C nachprogrammiert. Und dann ist das Kapitel zu Ende. Das war OOP in C.
Das Vorgehen hier entspricht also exakt der OOP-Definition von Stroustrup (1. Kapselung 2. Vererbung 3. Laufzeit-Polymorphie). Aber dennoch nennt er diese Definition nie explizit. Das heißt man kann es sich zwar denken, aber er sagt es nicht explizit.
