Performancemythen?

Xin

Und nochmal ich: Folgendes sollte eigentlich vor otzes Posting stehen:

TheTester schrieb:

Xin schrieb:

Damit Objekte in einer Beziehung zueinander stehen muss keine Vererbungsbeziehung zwischen ihnen bestehen. Es gibt auch noch die einfache Assoziation, Aggregation und Komposition. Das die Sachen nicht das gleiche sind wird auch z.B. durch die Symbolik der UML deutlich.

Und haben diese Beziehungen etwas mit OOP zu tun?

Wenn Vererbung etwas mit OOP zu tun hat, ja dann haben sie auch etwas mit OOP zu tun. Nur mit Vererbung allein lassen sich nicht alle Beziehungen von Objekten untereinander charakterisieren. Ich bin mit mir etwas uneins ob sie jedoch neben Vererbung einen echten Beitrag zur Def. leisten.

Wenige Beleidigungen zuvor, schrieb "scrub_" noch dazu:

Scrub_ schrieb:

Hallo MacFly, jemand zuhause? [...]was das mit OOP zu tun hat?
Das war ein integraler Bestandteil "unserer" Definition.

Ich sehe den Beitrag nämlich jetzt auch nicht und aus Scrubs Beitrag lese ich grade auch nicht, wo er ihn sieht.
Darum fragte ich nach.

TheTester schrieb:

Sie haben wohl etwas mit OOP zu tun aber ich glaube eher derart das sie, betrachtet von der Abstraktionsebene, niedriger angesiedelt sind als OO und deshalb von OO schon "impliziert" werden.

Auf jeden Fall lassen sich mit ihr Beziehungen zu Objekten ausdrücken.
Jeder Mensch hat eine aggregative Beziehung zu seinem Herzen. Menschen verdauen, schlafen und pflanzen sich fort und Herzen pumpen. Obwohl eine aggregative Beziehung besteht, sehe ich hier keine sinnvolle Möglichkeit einen objektorientierten Algorithmus zu formulieren, der diese Beziehung ausnutzt.

Jeder Hand hat eine assoziative Beziehung zu seinen Menschen. Die Hände sind da. Sind die Hände weg, bleibt der Mensch trotzdem da. Ich wüßte jetzt nicht, wie ich das ausnutzen könnte.

Die interessante Beziehung für OO ist die "ist ein" Beziehung: die Vererbung. Ein Arbeitnehmener ist ein Mensch. Arbeitnehmer verdauen, schlafen und pflanzen sich fort, aber nur während Pausen und in der Freizeit.

TheTester schrieb:

Wenn man es denn arg streng betrachtet würde wohl das Klassenkonzept, Vererbung und Polymorphie OO zur OO machen, da das die wesentlichen "Neuerungen" in den Entwurfskonzepten sind und Dinge wie funktionale Abstraktion, Datenabstraktion, abstrakte Datentypen schon enthält.

Das Klassenkonzept ist nicht notwendig, lediglich die Klassifizierung, also eine Schnittstelle, damit Basis und Ableitung Basisdaten an identischer Stelle stehen haben, damit die Basisfunktionen (z.B. typeid()) die Basisinformationen auslesen können.

Undertaker schrieb:

vielleicht sollte mal jeder seine persönliche auffassung von OOP hier hinschreiben?
so...der nächste bitte

objektorientiert ist, wenn verschiedene objekte miteinander kummunizieren, d.h. nachrichten empfangen und versenden können. <- punkt

und xin, dein "diskussionstil" ist echt bissl ignor/arrogant

Xin

overtaker schrieb:

und xin, dein "diskussionstil" ist echt bissl ignor/arrogant

Inwiefern?
Weil ich meine Überzeugung nicht der Allgemeinheit anpasse? Wobei ich nicht weiß, wer hier jetzt die Allgemeinheitheit repräsentiert, man lässt mir ja genug Auswahl.
Sorry, wenn ich nicht überzeugt bin, kann ich meine Meinung nicht anpassen. Das ist nicht ignorant und auch nicht arrogant.

sowohl ignorant als auch arrogant ist z.b. dass du die hälfte der kritischen posts hier ignorierst weil du ihnen anscheinend nichts entgegenzusetzen hast und dann nur rumpflaumst

rüdiger

Xin schrieb:

Allerdings spiele ich hier seit 3 Tagen den Erklärbär für's Forum und gelegentlich möchte ich mich auch um andere Dinge kümmern. Was ist daran lächerlich?

Daran ist lächerlich, dass du glaubst du bist der Erklärbär. In der Sache gibt es eben kein ultimatives richtig. Genauso wie bei dem Thema warum die Farbe Blau "Blau" heißt. Du hast eben deine eigene Ansicht. Die sich aber einfach _nicht_ mit der Ansicht der Mehrheit deckt. Das ist ja auch vollkommen in Ordnung! Du kannst ja meinetwegen auch Grün zu Blau sagen. In beiden Fällen lohnt es sich imho nicht eine 30 Seiten Diskussion zu führen, bei denen mehrere Personen "ihre Hose runterlassen".

Komisch finde ich nur, dass der Graham Artikel hier vieles voraus gesehen hat...

btw. Bashar hat in einem älteren Thread mal eine ziemlich gute OOP-Definition geliefert. Die ging ungefähr in die Richtung: OO ist der Austausch von Nachrichten zwischen Objekten. Bin aber zu faul den Thread zu suchen. Das traf es aber ziemlich genau imho und deckte sich auch mit allen (mir bekannten) Objekt-Systemen.

rüdiger schrieb:

in die Richtung: OO ist der Austausch von Nachrichten zwischen Objekten.

steht doch da schon

overtaker schrieb:

objektorientiert ist, wenn verschiedene objekte miteinander kummunizieren, d.h. nachrichten empfangen und versenden können. <- punkt

!!!!!!!!!!!!!!11111111

rüdiger

wunderbar! Hatte wohl zu lange pause gemacht beim schreiben des Beitrags.

Aber die Definition trifft es imho am besten.

otze

ich zähle die argumente auf:
1.

Xin schrieb:

Dann zeig mir mal, wie Du einen String aufrufst, ohne einen Segmentation fault zu bekommen.

Wieso ist das denn anforderung, dass mans aufruft? mal davon ab, was für ein Aufruf sollte das sein? Was spricht gegen ein Objekt mit überladenem Operator()?
Wobei, eigentlich braucht man das nicht, denn es gibt viele OOP unterstützende Sprachen bei denen bei argumentlosen funktionen der operator() nicht verwendet werden muss/darf, die funktionen werden dann wie normale variablen verwendet. Sind in diesen Sprachen diese funktionen dann auch kein OO?

natürlich könntest du sagen: "Im ASM code muss ein funktionsaufruf zu finden sein", aber damit begiebst du dich auf dünnes eis. Manchmal kann der Compiler den funktionsaufruf rausoptierem, oder den code so schieben, dass inlining möglich ist. Natürlich kann der Compiler die ganze geschichte auch anders implementieren.

Muss man also den ASM output anschauen um zu wissen, ob eine bestimmte Stelle OO ist?

Meine Lösung ist kein gutes Beispiel, die Funktionszeiger sollten eigentlich statisch hinterlegt werden und nicht im Objekt auftauchen. Dann hat man virtual nachimplementiert.

Das ist compilerabhängig, was er draus macht. nebenbei sind deine beiden funktionen normalerweise auch statisch hinterlegt, namespaces sind syntaxzucker aber für den compiler in der codegenerationsphase absolut bedeutungslos.

//nachtrag
Und was ist eigentlich mit funktionsobjekten? ich kann hinter ihnen eine funktion aus deinem beispiel verstecken und bottom up übergeben. Das ist dann oop, weil der functor sich nur um die funktion kümmert. Andererseits könnte der functor auch einfach nur einen wert verwalten, und dann ist das wieder kein oop. verfahrene situation, oder?

Undertaker

Xin schrieb:

Frage: Definiere bitte das neu im Thread erschienene Wort "Komponente".
Ja, ich habe eine Vorstellung davon, aber das ist die Blackbox in Deiner Aussage. Deine Komponenten müssen objekt(-typ)orientiert sein, damit ich der Aussage (!=Definition) soweit zustimmen könnte.

naja, die 'komponenten' sind die passenden bausteine, aus denen man sich das OO-programm zusammenbasteln kann. sie selbst müssen nicht unbedingt nach OO-prinzipien gebaut worden sein, d.h. der nutzer kann sie atomar betrachten. wenn man sich ein z-b- virtuelles fahrrad zusammencodet, benutzt man die rad, pedal, sattel, rahmen, usw. -komponenten dafür und 'programmiert' die beziehungen. das, finde ich, ist OOP.

otze

Ich hab mir mal ein paar Fälle überlegt, die deine Definition mit ihren eigenen Waffen schlägt:

1. Fall:
Du bekommst eine Lib aus dem Internet, das sind header und die compilierte lib datei zum statischen dazulinken.

//header
class TierImpl;
class Tier
{
        TierImpl* foo;
    public:
        Tier(TierImpl* foo);

        void gibLaut();
};

Tier* erstelleEinTier(string laut);

//main

int main()
{
    Tier* tier=erstelleEinTier("Miau");
    tier->gibLaut();
}

OOP oder nicht? Du kennst die implementation nicht, alle details sind hinter TierImpl verborgen. Vielleicht werden im Hintergrund funktionszeiger rumgereicht und getestet zu welchem Tier der laut gehört, vielleicht wird auch nur "Miau" an TierImpl übergeben. Du weist es nicht. Ist das nun OOP oder nicht?

2.Fall

class Tier
{
    private:
        string laut;
    public:
        Tier():laut("Hallo"){}
        Tier(const string& laut):laut(laut){}

        virtual void gibLaut(){std::cout<<laut<<"\n";}
};
class Katze: public Tier
{
    public:
        Katze():Tier("Miau"){}
};

Tier* erstelleEinTier()
{
    return new Katze;
    //oder eine Stufe schwerer, code ändert sich ja auch gerne mal
    //return new Tier("Miau");
}

int main()
{
    Tier* tier=erstelleEinTier();
    tier->gibLaut();
}

Den Fall finde ich sehr interessant. reicht ein "virtual" um den Code nach deiner definition oop zu machen? Katze ist genau gleich wie vorher, nur das virtual in gibLaut ist neu. Nicht die Klasse bestimmt das Verhalten, sondern der Wert. Ist das nun trotzdem OOP? Was ist, wenn der Compiler erkennt, dass es kein Tier gibt, dass die methode überschreibt und deshalb den vcall herausoptimiert? immernoch oop? Oder wenn du erstelleEinTier anschaust. da wird vielleicht keine katze zurückgegeben sondern einfach ein Tier, und nun?

//nachtrag
Nach deiner definition ist zumindest der 1. Fall äußerst unklar. Wie sinnvoll ist die definition, wenn sie nicht entscheiden kann, ob tier->gibLaut() oop ist?
Wiederspricht es nicht der OOP, wenn man alle implementationsdetails kennen muss? lebt sie nicht eher davon zu verbergen, stichwort Kapselung?

Shade Of Mine

Xin, deine Definition was OOP ist, ist widersprüchlich.

Wo ist der Unterschied zwischen:

class Triangle {
  function draw() {}
}
class Circle {
  function draw() {}
}

function foo($s) {
  $s->draw();
}

und

struct Shape {
  void (*draw)();
};

struct Triangle {
  void (*draw)();
};

struct Circle {
  void (*draw)();
};

void foo(void* s) {
  ((Shape*)s)->draw();
}

und

function Triangle() {
  this.draw=function(){}
}
function Circle() {
  this.draw=function(){}
}
function foo(s) {
  s.draw();
}

und

class Triangle {
}
class Circle {
}

show(Tirangle s) {}
show(Circle s) {}

Der letzte Code ist Nice und show ist ne multimethod.

Ich sehe da leider keinen Unterschied - warum ist der C Code OO und der andere Code nicht? Es ergibt keinen Sinn - ich habe nirgends vererbung. ich habe manchmal nicht mal klassen. und dennoch ist jeder code so dynamisch dass ich ihm jedes objekt dass einen gewissen vertrag einhält zuwerfen kann und er wird funktionieren.

Auch der Template Code in C++ gehört da eigentlich dazu, aber du bist scheinbar noch nicht soweit zu erkennen dass man heutzutage alles zur Runtime machen kann.

Ich habe mittlerweile echte Probleme zu verstehen was du unter OOP verstehst und was nicht. Anfangs dachte ich du meinst virtuelle Funktionen definieren OOP. Keiner meiner Codes hat virtuelle Funktionen beinhaltet. Dann dachte ich du meinst runtime polymorphie - aber alle meine Codes ermöglichen Runtime Polymorphie. Jetzt bin ich verwirrt.

Ist es eigentlich möglich in JavaScript ein OO Programm zu schreiben? Was du als "memcpy" abtust - nämlich Object Cloning - ist etwa das pedant zur Vererbung in Java. Man kann vererbung ein bisschen simulieren wie in C - aber dann hat man JS nicht verstanden. Man hat einfach keine virtuellen Funktionen, Vererbung auch nicht. Der Shape-Code ist OO JavaScript. Mehr OO wird nicht gehen. Selbst wenn Shape nicht abstrakt ist, sondern sagen wir eine final Funktion getId() hat, sieht der Code in JS nicht viel anders aus:

function Shape() {
  this.getId=function(){}
}
function Triangle() {
  this = new Shape();
  this.draw = function(){}
}
function Circle() {
  this = new Shape();
  this.draw = function(){}
}

Es findet hier keine Vererbung statt, sondern Object Cloning. Und da es keine virtuellen Funktionen gibt, macht es auch keinen Sinn ein draw() in Shape reinzupacken.

Oder Vererbung in PHP - das ist nichts anderes als Code Reuse - das Interface definiert das Objekt. zB wo man in Java ein Interface Showable mit der abstrakten funktion show() nehmen würde, würde ich in PHP einfach keine Vererbung verwenden.

Das interessante dabei ist:

class Triangle {
  function show();
}
class Circle {
  function show();
}
function foo($s) {
  $s->show();
}

ist ziemlich genau 1:1 die Umsetzung von folgendem Java Code:

interface Showable {
  abstract void show();
}

class Triangle implements Showable {
  public void show(){}
}

class Circle implements Showable {
  public void show(){}
}

Jetzt ist plötzlich einer dieser Codes OO und der andere nicht?

PHP hat ein schwaches typ system - ich brauche interfaces nicht. Java hat ein starkes typsystem ich brauche die interfaces dort. C++ bietet beides: starkes typsystem über Showable und auch starkes (was sich aber manchmal wie schwaches anfühlt) über Templates.

Und genau da beisst sich deine Definition. Deine OOP Definition (die ich wirklich nicht mehr nachvollziehen kann) basiert auf Java. Ich würde soweit gehen und sagen dass sie auf Java ziemlich genau zutrifft. Aber allein PHP - und PHP hat nun wirklich keine kreativen Ideen wie man an die OOP rangehen kann - widerspricht deiner Definition.

Von Sprachen wie Lisp, Nice, Self,... mal garnicht zu reden.

Also bitte, definiere OOP nochmaleimal ganz genau. Dann widerlegen wir dir das und wir können alle diesen Thread ruhen lassen. Es hat schon seinen Grund warum man nirgendwo eine vernünftige feste Definition von OOP liest - denn OOP ist eben eine Denkweise und die lässt sich schwer definieren.

rüdiger

Hier mal ein Beispiel mit Common Lisp (CLOS)

(defclass Tier () ())

(defclass Hund (Tier) ()) ; <-- Hund erbt von Tier

(defmethod laut ((a Tier))
  (print "dunno"))

(defmethod laut ((a Hund))
  (print "wuff wuff"))

(defclass Katze () ()) ; <-- Katze erbt nicht

(defmethod laut ((a Katze))
  (print "miau miau"))

(defun laut-mit-eingabe ()
  (laut (let ((what (read)))
              (case what
                ('Hund  (make-instance 'Hund))
                ('Katze (make-instance 'Katze))
                (otherwise (make-instance 'Tier))))))

Hab extra ein read eingebaut um zu zeigen, dass die Auswertung dynamisch ist.

CL-USER> (laut-mit-eingabe)
Hund

"wuff wuff" 
"wuff wuff"
CL-USER> (laut-mit-eingabe)
STH

"dunno" 
"dunno"
CL-USER> (laut-mit-eingabe)
Katze

"miau miau" 
"miau miau"

Xin

Ob ich Posts ignoriere, ignoriere ich jetzt mal. Damit können sich die Leute im Recht fühlen, keine Lust hier noch eine weitere Diskussion im Thread zu führen.

otze schrieb:

ich zähle die argumente auf:
1.

Xin schrieb:

Dann zeig mir mal, wie Du einen String aufrufst, ohne einen Segmentation fault zu bekommen.

Wieso ist das denn anforderung, dass mans aufruft?

Es ist die Verzweigung, wo der Objekt den Unterschied macht, wohin verzweigt wird.

otze schrieb:

natürlich könntest du sagen: "Im ASM code muss ein funktionsaufruf zu finden sein", aber damit begiebst du dich auf dünnes eis. Manchmal kann der Compiler den funktionsaufruf rausoptierem, oder den code so schieben, dass inlining möglich ist.

Den Part hatte ich schon mit MrN. Er war der erste, der mich abschrieb in genau dem Punkt.

Es muss ein Funktionsaufruf in Asm zu finden sein, außer der Compiler kann sicherstellen, dass es keine Ableitungen der Basisklasse gibt, die diese Funktion überschreibt.

otze schrieb:

Muss man also den ASM output anschauen um zu wissen, ob eine bestimmte Stelle OO ist?

Nein. Statt gegen mich zu argumentieren, kannst Du meine Postings lesen und gezielte Fragen stellen.

otze schrieb:

Meine Lösung ist kein gutes Beispiel, die Funktionszeiger sollten eigentlich statisch hinterlegt werden und nicht im Objekt auftauchen. Dann hat man virtual nachimplementiert.

Das ist compilerabhängig, was er draus macht.

Das ist korrekt, es ist compilerabhängig. Eine VTable ist die schnellste Methode, entsprechend wirst Du wenige Compiler finden, die das anders lösen.

otze schrieb:

nebenbei sind deine beiden funktionen normalerweise auch statisch hinterlegt, namespaces sind syntaxzucker aber für den compiler in der codegenerationsphase absolut bedeutungslos.

Alle Funktionen sind statisch hinterlegt, auch wenn da kein static vorsteht. Auch virtuelle Funktionen sind statisch im Programm. Im Objekttyp ist ein Zeiger dafür hinterlegt, der dereferenziert werden muss.
Also was genau stört dich jetzt daran?

otze schrieb:

Und was ist eigentlich mit funktionsobjekten? ich kann hinter ihnen eine funktion aus deinem beispiel verstecken und bottom up übergeben. Das ist dann oop, weil der functor sich nur um die funktion kümmert. Andererseits könnte der functor auch einfach nur einen wert verwalten, und dann ist das wieder kein oop. verfahrene situation, oder?

Gib mir ein Beispiel.

otze schrieb:

Ich hab mir mal ein paar Fälle überlegt, die deine Definition mit ihren eigenen Waffen schlägt:

1. Fall:
Du bekommst eine Lib aus dem Internet, das sind header und die compilierte lib datei zum statischen dazulinken.

- Klassendefinition -

OOP oder nicht? Du kennst die implementation nicht, alle details sind hinter TierImpl verborgen. Vielleicht werden im Hintergrund funktionszeiger rumgereicht und getestet zu welchem Tier der laut gehört, vielleicht wird auch nur "Miau" an TierImpl übergeben. Du weist es nicht. Ist das nun OOP oder nicht?

Was ist das denn für eine Frage? Du zeigst mir nichts und ich soll sagen, was das ist?
Hab ich 'ne Kristallkugel? Ich weiß ja nicht, was der Code da macht.
Nur weil da Miau rauskommt, weiß ich doch nicht, ob der Entwickler per OOP gelöst hat oder nicht.

Du hast zuvor eine Lösung ohne OOP vorgestellt und ich zwei mit OOP. "Miau" kann man auf viele Variabten ausgeben.

otze schrieb:

2.Fall

class Tier
{
    private:
        string laut;
    public:
        Tier():laut("Hallo"){}
        Tier(const string& laut):laut(laut){}
     
        virtual void gibLaut(){std::cout<<laut<<"\n";}
};
class Katze: public Tier
{
    public:
        Katze():Tier("Miau"){}
};

Tier* erstelleEinTier()
{
    return new Katze;
    //oder eine Stufe schwerer, code ändert sich ja auch gerne mal
    //return new Tier("Miau");
}

int main()
{
    Tier* tier=erstelleEinTier();
    tier->gibLaut();
}

Den Fall finde ich sehr interessant. reicht ein "virtual" um den Code nach deiner definition oop zu machen? Katze ist genau gleich wie vorher, nur das virtual in gibLaut ist neu.

Richtig, Tier agiert jetzt Objektorientiert.
Da Du für Katze die Funktion nicht überladen hast, aber eine für Tier angelegt hast, zeigt der Objekttyp "Katze" auf die gleiche Funktion wie der Objekttyp "Tier".
Das ist OOP, ein Hund darf schließlich woanders hinzeigen. Ohne Hund ist es idiotisch hier OOP zu verwenden und das man OOP nach Möglichkeit vermeiden sollte, schrieb ich auch schon. Das ist ein Fall, den man vermeiden sollte.

otze schrieb:

Nicht die Klasse bestimmt das Verhalten, sondern der Wert. Ist das nun trotzdem OOP?

Der Wert bestimmt hier kein Verhalten, der Wert wird ausgeben. Es ist OOP, aber nicht weil ein Wert ausgegeben wird.
Du löst hier ein vollkommen anderes Problem. Wie gesagt - es gibt viele Möglichkeiten um "Miao" auszugeben, aber das bedeutet nicht, dass alle Möglichkeiten "Miau" auszugeben identisch sind.

otze schrieb:

Was ist, wenn der Compiler erkennt, dass es kein Tier gibt, dass die methode überschreibt und deshalb den vcall herausoptimiert? immernoch oop?

OOP vom Entwickler gewünscht, vom kleveren Compiler rausoptimiert.
Sourcecode OOP, Executable kein OOP.

otze schrieb:

Oder wenn du erstelleEinTier anschaust. da wird vielleicht keine katze zurückgegeben sondern einfach ein Tier, und nun?

Was nun? Dann wird ein Tier zurückgegeben - wo ist das Problem?

otze schrieb:

Nach deiner definition ist zumindest der 1. Fall äußerst unklar.

Der Fall hat nichts mit einer Definition zu tun. Wenn Du keine Informationen hast, ist alles unklar.

otze schrieb:

Wie sinnvoll ist die definition, wenn sie nicht entscheiden kann, ob tier->gibLaut() oop ist?

Wie sinnvoll ist eine Frage an Xin, wenn otze die Antwort nach belieben verändern kann, da er sich nie mit einem Sourcecode festgelegt hat?

otze schrieb:

Wiederspricht es nicht der OOP, wenn man alle implementationsdetails kennen muss? lebt sie nicht eher davon zu verbergen, stichwort Kapselung?

Nein. Kapslung bedeutet, dass ich ein Ergebnis bekomme und ich keine Ahnung habe, wie der Entwickler dazu gekommen ist. Ob der dafür OOP verwendet oder nicht, interessiert mich überhaupt - ich bekomme das Ergebnis und gut.

Xin

Undertaker schrieb:

Xin schrieb:

Frage: Definiere bitte das neu im Thread erschienene Wort "Komponente".
Ja, ich habe eine Vorstellung davon, aber das ist die Blackbox in Deiner Aussage. Deine Komponenten müssen objekt(-typ)orientiert sein, damit ich der Aussage (!=Definition) soweit zustimmen könnte.

naja, die 'komponenten' sind die passenden bausteine, aus denen man sich das OO-programm zusammenbasteln kann. sie selbst müssen nicht unbedingt nach OO-prinzipien gebaut worden sein, d.h. der nutzer kann sie atomar betrachten. wenn man sich ein z-b- virtuelles fahrrad zusammencodet, benutzt man die rad, pedal, sattel, rahmen, usw. -komponenten dafür und 'programmiert' die beziehungen. das, finde ich, ist OOP.

Das sind doch nur "plain classes" => kein OOP.

OOP kommt dann rein, wenn Lampe zum Beispiel nicht mit Dynamo kombiniert wird, sondern von Energiequelle.
Energiequelle könnte Dynamo sein oder Akku.
Energiequelle::GetVoltage() wäre eine virtuelle Funktion, die beim Dynamo von der Drehzahl abhängt und beim Akku von der Ladung der Zellen.

Aprollo

Undertaker schrieb:

sie selbst müssen nicht unbedingt nach OO-prinzipien gebaut worden sein

Xin schrieb:

Das sind doch nur "plain classes" => kein OOP.

dv_

"Sourcecode OOP, Executable kein OOP."

Damit hast du dich komplett disqualifiziert, Xin.

dv_ schrieb:

"Sourcecode OOP, Executable kein OOP."

Wie kommst Du jetzt darauf ? Wo steht denn das ?

Xin

Shade Of Mine schrieb:

Wo ist der Unterschied zwischen:

class Triangle {
  function draw() {}
}
class Circle {
  function draw() {}
}

function foo($s) {
  $s->draw();
}

und

struct Shape {
  void (*draw)();
};

struct Triangle {
  void (*draw)();
};

struct Circle {
  void (*draw)();
};

void foo(void* s) {
  ((Shape*)s)->draw();
}

und

function Triangle() {
  this.draw=function(){}
}
function Circle() {
  this.draw=function(){}
}
function foo(s) {
  s.draw();
}

JS und PHP haben für alle Objekte eine gemeinsame Basis: den Objekttyp. Am Objekttyp kann sich die Sprache orientieren, um die richtige Funktion zu rufen.
In C++ wird der Objekttyp erst in die Klasse eingefügt, wenn eine virtuelle Funktion existiert.

Probiere folgendes aus:

class OOP
{
  int Daten;
  virtual ~OOP() {}; 
};

class NonOOP
{
  int Daten;
  ~NonOOP() {}
}

int main( void )
{
  printf( "OOP: %d - NonOOP: %d\n,", sizeof( OOP ), sizeof( NonOOP ) );
  return 0;
}

Du wirst sehen, dass die OOP Variante größer ist, obwohl beide nur 4 Byte Daten enthalten, das ist die Typ-Kennzeichnung für das Objekt, an dem sich Algorithmen orientieren.

Wenn Du Dein C++ Beispiel kompilierst, wirst Du weiterhin feststellen, dass Du ohne virtual feststellst, dass immer Shape::Draw aufgerufen wird. Darum ist der C++-Code nicht objektorientiert.

Ich rate dringend dazu, wenn Du virtual nutzt, also C++-Unterstützung nutzt, OOP-Klassen zu verwenden, denn ich garantiere nicht dafür, dass der Hack mit virtual funktioniert.

Shade Of Mine schrieb:

class Triangle {
}
class Circle {
}

show(Tirangle s) {}
show(Circle s) {}
Der letzte Code ist Nice und show ist ne multimethod.

Ah... das mit der Multimethod habe ich eben nicht kapiert.

Um Multimethoden zu realisieren, muss das Objekt einen Objekttyp besitzen. "Plain Classes" kannst Du nicht unterscheiden, weil der Objekttyp fehlt.
Sobald Du Multimethoden nutzen möchtest, musst Du also den Objekttyp zwangsläufig haben und sobald Objekte den Objekttyp haben, besitzen sie eine gemeinsame Basis.
Das wird in Java ja durch die implizite Ableitung von "class Object" ausgedrückt.

Shade Of Mine schrieb:

Auch der Template Code in C++ gehört da eigentlich dazu, aber du bist scheinbar noch nicht soweit zu erkennen dass man heutzutage alles zur Runtime machen kann.

Ich weiß grade nicht, welcher Code gemeint ist und die Freundlichkeit überhöre ich mal.

Shade Of Mine schrieb:

Ich habe mittlerweile echte Probleme zu verstehen was du unter OOP verstehst und was nicht. Anfangs dachte ich du meinst virtuelle Funktionen definieren OOP. Keiner meiner Codes hat virtuelle Funktionen beinhaltet. Dann dachte ich du meinst runtime polymorphie - aber alle meine Codes ermöglichen Runtime Polymorphie. Jetzt bin ich verwirrt.

Ich hoffe, ich konnte es etwas aufklären.

Shade Of Mine schrieb:

Ist es eigentlich möglich in JavaScript ein OO Programm zu schreiben? Was du als "memcpy" abtust - nämlich Object Cloning - ist etwa das pedant zur Vererbung in Java. Man kann vererbung ein bisschen simulieren wie in C - aber dann hat man JS nicht verstanden. Man hat einfach keine virtuellen Funktionen, Vererbung auch nicht.

Beides ist ja auch nicht benötigt. Und wenn man in C++ OOP betreibt, wie in C, hat man C++ auch nicht verstanden. Trotzdem ist es OOP.

Shade Of Mine schrieb:

Der Shape-Code ist OO JavaScript. Mehr OO wird nicht gehen. Selbst wenn Shape nicht abstrakt ist, sondern sagen wir eine final Funktion getId() hat, sieht der Code in JS nicht viel anders aus:
function Shape() {
  this.getId=function(){}
}
function Triangle() {
  this = new Shape();
  this.draw = function(){}
}
function Circle() {
  this = new Shape();
  this.draw = function(){}
}
Es findet hier keine Vererbung statt, sondern Object Cloning. Und da es keine virtuellen Funktionen gibt, macht es auch keinen Sinn ein draw() in Shape reinzupacken.

Stimmt, Du musst in JS ja auch nicht angeben, welchen Typ Du einer Funktion übergibst.
Du Benennung als virtual in der Basisklasse ist notwendig, um das Interface statisch kompilierbar zu machen.
In JS ist überhaupt nichts statisch kompiliert.

Shade Of Mine schrieb:

Oder Vererbung in PHP - das ist nichts anderes als Code Reuse - das Interface definiert das Objekt. zB wo man in Java ein Interface Showable mit der abstrakten funktion show() nehmen würde, würde ich in PHP einfach keine Vererbung verwenden.

Das interessante dabei ist:
class Triangle {
  function show();
}
class Circle {
  function show();
}
function foo($s) {
  $s->show();
}
ist ziemlich genau 1:1 die Umsetzung von folgendem Java Code:
interface Showable {
  abstract void show();
}

class Triangle implements Showable {
  public void show(){}
}

class Circle implements Showable {
  public void show(){}
}
Jetzt ist plötzlich einer dieser Codes OO und der andere nicht?

Beide sind OO und beide besitzen implizit die Objekttyp-Information, die in C++ nicht existieren würde, wenn man virtual wegläßt.

Warum benutzt Du in Java abstract, lehnst aber in C++ "virtual ...=0" ab?

Shade Of Mine schrieb:

PHP hat ein schwaches typ system - ich brauche interfaces nicht. Java hat ein starkes typsystem ich brauche die interfaces dort. C++ bietet beides: starkes typsystem über Showable und auch starkes (was sich aber manchmal wie schwaches anfühlt) über Templates.

Und genau da beisst sich deine Definition. Deine OOP Definition (die ich wirklich nicht mehr nachvollziehen kann) basiert auf Java. Ich würde soweit gehen und sagen dass sie auf Java ziemlich genau zutrifft. Aber allein PHP - und PHP hat nun wirklich keine kreativen Ideen wie man an die OOP rangehen kann - widerspricht deiner Definition.

Wo ist der Widerspruch? Wo beißt sich etwas, ich verstehe nicht, welchen Punkt Du mir als Widerspruch vorlegen willst!?

Shade Of Mine schrieb:

Also bitte, definiere OOP nochmaleimal ganz genau. Dann widerlegen wir dir das und wir können alle diesen Thread ruhen lassen. Es hat schon seinen Grund warum man nirgendwo eine vernünftige feste Definition von OOP liest - denn OOP ist eben eine Denkweise und die lässt sich schwer definieren.

Ich arbeite dran. Es ist nicht ganz so einfach, eine möglichst interpretationsfreie Definition zu liefern und zwischendurch muss ich auch mal andere Dinge erledigen als nur diesen Thread.

Es ist aber schön, dass ich mir die Mühe nur mache, um widerlegt zu werden. Die Chance, dass die Zusammenfassung so verständlich wird, dass sie überzeugt, steht nicht zur Diskussion?