Performancemythen?

Jester

Mr. O schrieb:

nein es dauert länger. eigentlich habe ich um solchen wie dir vorzubeugen das "dauert gleich lang" in anführungszeichen gesetzt, weil der algorithmus immer noch (achtung anführungszeichen) "gleich lang dauert". auf meinem alten 386er läft der algorithmus genauso schnell. ebenso wie mit papier und stift. genau dafür gibt es ja die O notation...

Ehm ja... die O-Notation ist ein theoretisches Werkzeug. Und man kann damit toll Algorithmen vergleichen (sogar ohne sie konkret zu implementieren). Und dass man dabei die Konstanten plattklopfen kann ist echt praktisch. Aber gerade die Konstanten sind in der Realität eben doch von Bedeutung. Die kann man da nicht einfach unter den Tisch fallen lassen. Die O-Notation hilft nicht irgendwas schneller oder langsamer zu machen.

Xin

Jester schrieb:

Xin: was Du sagst mag ja alle stimmen (meinetwegen).

Meinetwegen?

Wenn nichts mehr drum herrum führt, dann geben wir ihm meinetwegen recht?

Jester schrieb:

Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet.

Stimmt, ich halte mich an Kernigham oder Stroustrup oder sonstige Leute, die davon keine Ahnung haben.

Jester schrieb:

Das ist so wie wenn jemand erzählt 2+2 sei fünf... und am Ende rückt er damit raus, dass er das was wir vier nennen einfach fünf nennt. Dann stimmt das auch. Aber es wird natürlich weder breit akzeptiert noch generell richtig im kontext der normalen Bedeutung.

Wenn "man" bestimmt, was die normale Bedeutung ist und nicht die Logik, dann gibt's bald 'ne "Bild der Entwickler".

Jester schrieb:

(Ich beziehe mich hier nur auf den OOP-Teil, dass Listen nicht schneller oder langsamer als Arrays sind hat MrN ja schon schön dargelegt).

Gute Nacht, Jester...

Jester schrieb:

Mr. O schrieb:

nein es dauert länger. eigentlich habe ich um solchen wie dir vorzubeugen das "dauert gleich lang" in anführungszeichen gesetzt, weil der algorithmus immer noch (achtung anführungszeichen) "gleich lang dauert". auf meinem alten 386er läft der algorithmus genauso schnell. ebenso wie mit papier und stift. genau dafür gibt es ja die O notation...

Ehm ja... die O-Notation ist ein theoretisches Werkzeug. Und man kann damit toll Algorithmen vergleichen (sogar ohne sie konkret zu implementieren). Und dass man dabei die Konstanten plattklopfen kann ist echt praktisch. Aber gerade die Konstanten sind in der Realität eben doch von Bedeutung. Die kann man da nicht einfach unter den Tisch fallen lassen. Die O-Notation hilft nicht irgendwas schneller oder langsamer zu machen.

das hab ich verstanden, nur michba offensichtlich DEvents beispiel.

otze

Mir kommt diese Diskussion mit Xin irgendwie bekannt vor....wo war das noch gleich...ach stimmt, im letzten oop definitionsflamewar.

hustbaer

@Xin: dein Verständnis von OOP deckt sich anscheinend nicht mit dem was die Masse unter OOP versteht. Abstraktion/virtuelle Aufrufe sind IMO eine Technik die man OOP zuordnen kann bzw. verwenden kann um OO Programme zu schreiben, aber nicht Voraussetzung damit irgendwas "OO" ist.

Mein Verständnis von prozedural vs. OO:

Prozedural: man hat bestimmte Funktionen/Prozeduren die man aufruft um bestimmte Dinge zu erledigen. Diesen gibt man bestimmte Parameter mit.
Als "Auswahlkriterium" welcher Code wirklich ausgeführt wird dient der Name der Prozedur und sonst nix (ggf. noch die Signatur, wenn man Features wie Overloading verwendet).

OO: man schickt eine Nachricht an ein Objekt. Diese Nachricht besteht aus einem "Verb" + ggf. zusätzlichen Parametern.
Als "Auswahlkriterium" welcher Code wirklich ausgeführt wird dient das "Verb" der Nachricht + das Objekt an welches man die Nachricht geschickt hat.

Wenn man diese Definition von OO(P) verwendet heisst das noch lange nicht dass man hier irgendwelche abstrakten Klassen, Polymorphie oder virtuelle Aufrufe braucht. Wenn ein Programm so entworfen ist dass "die Auswahl des auszuführenden Codes" immer zur Compile-Zeit erfolgen kann (ohne natürlich den "falschen" Code auszuwählen), dann ist das kein Grund warum das Programm nichtmehr "OO" wäre. Logischerweise kann man viele Dinge damit nicht machen, oder muss sie zumindest ganz anders machen als wenn man z.B. virtuelle Aufrufe verwenden würde.

Anders gesagt: OO(P) schreibt nicht vor *wie* genau irgendwas zu passieren hat, sondern nur was zu passieren hat. Wenn das *wie* z.B. in einem bestimmten C++ Programm bedeutet dass der Programmierer verflixt aufpassen muss nicht mit dem "falschen" statischen Typ irgendwelche Sachen zu machen, dann ist das zwar vielleicht unschön und fehleranfällig, aber dennoch OO.

Xin schrieb:

Jester schrieb:

Xin: was Du sagst mag ja alle stimmen (meinetwegen).

Meinetwegen?

Wenn nichts mehr drum herrum führt, dann geben wir ihm meinetwegen recht?

Jester schrieb:

Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet.

Stimmt, ich halte mich an Kernigham oder Stroustrup oder sonstige Leute, die davon keine Ahnung haben.

Jester schrieb:

Das ist so wie wenn jemand erzählt 2+2 sei fünf... und am Ende rückt er damit raus, dass er das was wir vier nennen einfach fünf nennt. Dann stimmt das auch. Aber es wird natürlich weder breit akzeptiert noch generell richtig im kontext der normalen Bedeutung.

Wenn "man" bestimmt, was die normale Bedeutung ist und nicht die Logik, dann gibt's bald 'ne "Bild der Entwickler".

Jester schrieb:

(Ich beziehe mich hier nur auf den OOP-Teil, dass Listen nicht schneller oder langsamer als Arrays sind hat MrN ja schon schön dargelegt).

Gute Nacht, Jester...

au weia Xin deine ignoranz und arroganz ist ja kaum zu übertreffen. musst jeden post auseinandernehmen und so hinbiegen dass er in dein weltbild passt? oder ist das deine standardvorgehensweise wenn du nichts mehr zu sagen weißt?

Jester

Xin schrieb:

Jester schrieb:

Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet.

Stimmt, ich halte mich an Kernigham oder Stroustrup oder sonstige Leute, die davon keine Ahnung haben.

Gib mal ne Quelle. Behaupten kann man vieles.

Xin schrieb:

Wenn "man" bestimmt, was die normale Bedeutung ist und nicht die Logik, dann gibt's bald 'ne "Bild der Entwickler".

Ehm ja, weil es natürlich kein Stück willkürlich ist 4 mit vier zu bezeichnen und nicht mit fünf... völlig logisch.

michba

Mr. O schrieb:

michba schrieb:

Mr. O schrieb:

sorry das ist blödsinn, offentsichtlich hast du das thema zeitkomplexität nicht verstanden.

Dann erklär mir doch bitte, was genau ich falsch gemacht habe, nachdem du meinen Post nochmal in Ruhe durchgelesen hast.

Wie DEvent erkannt hat löst sich die konstante "5 mal langsamer" wunderbar in das n auf. aus einem O(n) algorithmus wird deshalb eben kein "O für c++ = O(5*n)" algorithmus

Es ging hier aber in keiner Weise um Komplexität, sondern um konkrete Laufzeit: "Faktor 5-10 langsamer" macht aus 5s Laufzeit eben 25-50s Laufzeit.
Und dann kommt DEvent und behauptet, das wäre vollkommen bedeutungslos, indem er plötzlich Komplexität ins Spiel bringt.

Mr. O schrieb:

nein es dauert länger. eigentlich habe ich um solchen wie dir vorzubeugen das "dauert gleich lang" in anführungszeichen gesetzt, weil der algorithmus immer noch (achtung anführungszeichen) "gleich lang dauert". auf meinem alten 386er läft der algorithmus genauso schnell. ebenso wie mit papier und stift. genau dafür gibt es ja die O notation...

Warum benutzt du nicht einfach eindeutige Begriffe, statt dich mit Anführungszeichen herumzuschlagen?

Übrigens, wir haben es geschafft, innerhalb der OT-Diskussion nochmal OT zu werden.

Xin

Okay, bisher habe ich erklärt und der Rest stimmt nicht zu.
Vielleicht erklärt mir mal einer was.

hustbaer schrieb:

@Xin: dein Verständnis von OOP deckt sich anscheinend nicht mit dem was die Masse unter OOP versteht.

Stimmt. ^^

hustbaer schrieb:

Abstraktion/virtuelle Aufrufe sind IMO eine Technik die man OOP zuordnen kann bzw. verwenden kann um OO Programme zu schreiben, aber nicht Voraussetzung damit irgendwas "OO" ist.

Mein Verständnis von prozedural vs. OO:

Prozedural: man hat bestimmte Funktionen/Prozeduren die man aufruft um bestimmte Dinge zu erledigen. Diesen gibt man bestimmte Parameter mit.
Als "Auswahlkriterium" welcher Code wirklich ausgeführt wird dient der Name der Prozedur und sonst nix (ggf. noch die Signatur, wenn man Features wie Overloading verwendet).

OO: man schickt eine Nachricht an ein Objekt. Diese Nachricht besteht aus einem "Verb" + ggf. zusätzlichen Parametern.
Als "Auswahlkriterium" welcher Code wirklich ausgeführt wird dient das "Verb" der Nachricht + das Objekt an welches man die Nachricht geschickt hat.

Okay.

Die Idee mit den Nachrichten ist ja nicht schlecht. Ein prozedurales Programm kann ebenfalls über Nachrichten laufen, wie zum Beispiel in Rexx. Die Nachrichten sind also kein Kennzeichen für OOP und die Nachrichten werden in kompilierenden Sprachen mit Funktionsaufrufen geregelt.
Benutzt man kein virtual, wird die Nachricht nicht an das Objekt geschickt, sondern an die Klasse, die auf das Objekt zeigt.

class Tier * tier = new Katze()

Wie gehst Du damit in OOP um? Schließlich kümmert sich C++ (und um die Sprache geht es hier) dabei nicht um das Objekt. Wieso nennst du das dann Objektorientiert, wenn sich der Algorithmus sich überhaupt nicht am Objekt orientiert.

hustbaer schrieb:

Wenn man diese Definition von OO(P) verwendet heisst das noch lange nicht dass man hier irgendwelche abstrakten Klassen, Polymorphie oder virtuelle Aufrufe braucht. Wenn ein Programm so entworfen ist dass "die Auswahl des auszuführenden Codes" immer zur Compile-Zeit erfolgen kann (ohne natürlich den "falschen" Code auszuwählen), dann ist das kein Grund warum das Programm nichtmehr "OO" wäre.

Und welche Begründung gibt es, es "OO" zu nennen?
Nachrichten gibt's in rein prozeduralen Sprachen, in C++ wird es in Funktionsaufrufen gehandhabt.
Man könnte auch überall, was da in Wirklichkeit ja auch steht, die Funktion korrekt ausschreiben:

tier.Tier::Funktion( typ Parameter )

Das unterscheidet sich von

tier_Funktion( Tier * tier, typ Parameter )

nicht. Die Methode heißt Tier::Funktion( Tier *, typ ). Wo ist der Unterschied zu "tier_Funktion( Tier *, typ )?
Es passiert dasselbe und es wird auch dasselbe übersetzt. Es ist in der Implementierung identisch. Es ist semantisch identisch, beides kann als Nachricht übermittelt werden und beides wird in C++ als Funktionsaufruf umgesetzt.
Warum ist das eine für Dich "OO" und das andere nicht? Wo beschreibt die Masse einen Unterschied, der den Namen "objekt orientiert" rechtfertigt?

Zu den anderen:

Mr. O schrieb:

Xin schrieb:

Jester schrieb:

Xin: was Du sagst mag ja alle stimmen (meinetwegen).

Meinetwegen?
Wenn nichts mehr drum herrum führt, dann geben wir ihm meinetwegen recht?

au weia Xin deine ignoranz und arroganz ist ja kaum zu übertreffen. musst jeden post auseinandernehmen und so hinbiegen dass er in dein weltbild passt? oder ist das deine standardvorgehensweise wenn du nichts mehr zu sagen weißt?

Jester gibt mir recht und das passt nicht in mein Weltbild. Da weiß ich echt nichts mehr drauf zu sagen.

Jester schrieb:

Xin schrieb:

Jester schrieb:

Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet.

Stimmt, ich halte mich an Kernigham oder Stroustrup oder sonstige Leute, die davon keine Ahnung haben.

Gib mal ne Quelle. Behaupten kann man vieles.

Bei der Array/Listen Geschichte, die MrN so schön beschrieben hat (von mir abgeschrieben hat), hast Du schon gezeigt, dass Du die Postings nicht liest.
Quellen habe ich angegeben, teils sogar mit Seitenzahl.
Den Faktor 5-10 habe ich nochmal belegt, weil hier jeder meinte, dass das Blödsinn wäre und Du kommst mir noch mit 'Behaupten kann man vieles'?!
Vielleicht fangt ihr mal an, eure Vorstellungen auch mal in Frage zu stellen und nicht nur unbegründet Sprüche wie "Unfug", "Ich stimme nicht zu" und "Behaupten kann man vieles" zu bringen.

Jester schrieb:

Ehm ja, weil es natürlich kein Stück willkürlich ist 4 mit vier zu bezeichnen und nicht mit fünf... völlig logisch.

Ich habe ehrlich gesagt keine Ahnung, was Du da mit 2+2=5 rumrechnest, es hat nichts mit meinen bisherigen Aussagen zu tun. Lies sie mal.

Jester

Xin schrieb:

Jester gibt mir recht und das passt nicht in mein Weltbild. Da weiß ich echt nichts mehr drauf zu sagen.

Okay, dann erklär ich mal was ich mit dem meinetwegen gemeint hab. Ich hatte keine Lust auf Deine "Schlussfolgerungen" einzugehen, weil ja bereits die Voraussetzungen nicht stimmen. Es mag also sein, dass alles was Du da so erzählst schlüssig ist, aber die Voraussetzungen stimmen einfach nicht. So oder so... ich stimme Dir da in den wenigsten Fällen zu.

Xin schrieb:

Jester schrieb:

Ehm ja, weil es natürlich kein Stück willkürlich ist 4 mit vier zu bezeichnen und nicht mit fünf... völlig logisch.

Ich habe ehrlich gesagt keine Ahnung, was Du da mit 2+2=5 rumrechnest, es hat nichts mit meinen bisherigen Aussagen zu tun.

Dass Du das nicht verstanden hast habe ich auch bemerkt.
Das ist ein Beispiel für eine Definition, die einfach ist wie sie ist. Das Ergebnis von 2+2 mit vier zu bezeichnen ist "genauso logisch" wie es mit fünf zu bezeichnen. Aber das eine ist nunmal Definition und die ändert sich nicht, bloß weil irgendjemand gerade findet, dass was anderes logischer ist. Und genau aus diesem Grund hat das was Du erzählst nix mit OOP zu tun bzw. ist bezogen auf die eigentliche Bedeutung von OOP falsch. Klar?

Xin

Jester schrieb:

Xin schrieb:

Jester gibt mir recht und das passt nicht in mein Weltbild. Da weiß ich echt nichts mehr drauf zu sagen.

Okay, dann erklär ich mal was ich mit dem meinetwegen gemeint hab. Ich hatte keine Lust auf Deine "Schlussfolgerungen" einzugehen, weil ja bereits die Voraussetzungen nicht stimmen. Es mag also sein, dass alles was Du da so erzählst schlüssig ist, aber die Voraussetzungen stimmen einfach nicht. So oder so... ich stimme Dir da in den wenigsten Fällen zu.

Okay, was ich erzähle "mag" schlüssig sein. Nehmen wir mal an, es ist schlüssig - nur eine Annahme.
Ich habe hustbaer einige Fragen gestellt, die mit "meiner" OOP-Definition ohne Probleme schlüssig zu erklären sind. Ich schreibe meiner in Anführungszeichen, da ich sie vielleicht alleine im Forum habe, aber definitiv nicht alleine auf dem Planeten,

Bisher hat aber niemand erklärt, warum er die "übliche" Definition verwendet, ich habe mehrfach danach gefragt. Die mag in Wikipedia stehen, die mag in manchen Büchern stehen. Weil andere sich auch an das "Übliche" halten. Aber niemand ist bisher darauf eingegangen, warum etwas "objektorientiert" genannt wird, wenn sich der Algorithmus sich nachweislich nicht am Objekt orientiert.

Wenn die "Übliche" Definition von OOP schlüssig ist, dann muss man darauf doch sofort eine schlüssige Antwort haben, die man sich nicht irgendwie aus den Fingern saugt. Wenigstens einer.

Wenn "nicht virtuell" + "referenztypbezogener Zugriff" = "objekt orientiert" ist, dann darf ich doch fragen, ob wirklich ich es bin, der hier 2+2=5 rechnet.

Ich biete eine Definition an, die ich bei Stroustrup gelesen und übernommen habe - ich schrieb ja bereits, dass ich früher Klassen usw. auch zu OOP gefasst habe. Ich habe in "Design und Entwicklung von C++" sehr detailiert gelesen, was eine Klasse ist und auch, was eine Klasse nicht ist und darauf "meine" Verständnis von Klassen und OOP und vielen anderen Techniken, die sich in C++ finden, verfeinert und wie Du sagst, "mag" es schlüssig sein.

Vielleicht ist es nicht nur schlüssig, sondern bedeutet eben auch, dass man "OOP" nicht weiträumig verstehen muss oder als schwammigen Begriff versteht, sondern als ganz eindeutig definierte Technik. Diese Technik macht in Kombination mit anderen Techniken, wie DataHiding, wie Klassen, wie Überladen oder Überschreiben von nicht virtuellen Methoden, Templates usw. die Sprache C++ aus, die wir als ein großes Konzept wahrnehmen. Hier greifen Techniken ineinander.

Dazu kommt die verbale Ungenauigkeit "ist kein [class] Object" von Java, einer Sprache, die diese verbale Ungenauigkeit seit 10 Jahren verbreitet und von der man in den letzten Jahren an jeder Ecke hörte. Viele können Java oder unterhalten sich über OOP mit Java-Programmieren.
Das Ableiten von class Object in Java entspricht dem Einfügen der VTable in C++, was der C++-Compiler automatisch macht, sobald man "virtual" zum ersten Mal verwendet. Viele hier haben vor 10 Jahren noch nicht programmiert, haben ihre OOP Kenntnisse also in einer Zeit erlangt, in der viel über Java gesprochen wurde.

Besteht die Möglichkeit, dass hier eventuell Begriffe, wie "class Object" und Objekt-Techniken durcheinander geworfen werden, ohne dass man es selbst überhaupt merkt oder jemals in Frage gestellt hat?

EDIT: Nochwas zu Java. Vor 7 Jahren hatte ich ähnliche Diskussionen. Da hatte ich die lächerliche Auffassung, dass Fehler zur Compilierzeit zu finden besser wäre als Fehler zur Runtime-Zeit zu erhalten. Zu der Zeit fand man auf der SUN-Website die Informationen, dass Laufzeitfehler besser sind als Compiler-Warnungen. Die Diskussion musste ich schon lange nicht mehr führen.
Sehr häufig musste ich die Diskussion führen, ob es in Java Zeiger gibt, gelegentlich noch heute. Ich sage, es gibt Zeiger und man zeigte mir Marketing Unterlagen zu Java, die belegten(!), dass Java ohne Zeiger funktionierte. Mein Argument, die Null-Pointer-Exception, hat noch keiner widerlegt. Es reicht nicht, Zeiger als Referenzen zu bezeichnen.
Ich sehe diese Diskussion ähnlich, ich bezweifle dass jemand eine nachvollziehbare Begründung finden wird, warum ein Algorithmus, der sich eben nicht am Objekt orientiert, weil virtual fehlt, als objektorientiert zu bezeichnen wäre.

scrub

Xin schrieb:

Ich sehe diese Diskussion ähnlich, ich bezweifle dass jemand eine nachvollziehbare Begründung finden wird, warum ein Algorithmus, der sich eben nicht am Objekt orientiert, weil virtual fehlt, als objektorientiert zu bezeichnen wäre.

So, zuerst meinte ich, Deine Definition sei merkwürdig und ich hätte sie noch nie gehört.

Jetzt sag ich Dir mal, was ich zuallermeist gehört habe und was (nicht deshalb!) sich auch logisch anhört:
Objektorientiert ist, wenn man statt einem Haufen Daten und einem anderen Haufen Funktionen ganz klar bestimmten Daten(-typen) bestimmte Funktionen zuordnet, man also bereits im Quelltext genau sehen kann, daß miau() zur Katzenklasse und wau() zur Hundeklasse gehört- statt sich jedesmal selbst die passende Funktion rauszuschen, die man gerade braucht.
Die Begrifflichkeiten virtueller Funktionen und der restliche Krempel, dies alles kam in diesem Erklärungen des Themas OO _nie_ vor, kein einziges Mal. Ich lese davon in Deinen Beiträgen zum ersten Mal.
Und bevor Du jetzt wieder lospapmpst: Ich habe nicht behauptet, daß Du Unfug redest. Aber Deine Argumentationsbasis ist aus meiner Sicht relativ schmal.

Xin

scrub schrieb:

Jetzt sag ich Dir mal, was ich zuallermeist gehört habe und was (nicht deshalb!) sich auch logisch anhört:
Objektorientiert ist, wenn man statt einem Haufen Daten und einem anderen Haufen Funktionen ganz klar bestimmten Daten(-typen) bestimmte Funktionen zuordnet, man also bereits im Quelltext genau sehen kann, daß miau() zur Katzenklasse und wau() zur Hundeklasse gehört- statt sich jedesmal selbst die passende Funktion rauszuschen, die man gerade braucht.

Ich bemühe mich nicht "loszupampen"... :->

Für wau() und miau() braucht man kein OOP. Abstrahiert man das Problem, hat es allerdings Sinn eine abstrakte Form von wau() und miau() virtuell zu gestalten:

class Tier
{
  public:
    virtual void GibLaut() { std::cout << "Hallo!"; }
};

class Katze : public Tier
{
  public:
    virtual void GibLaut() { std::cout << "Miau"; }
}

Läßt Du das virtual weg, verzichtest Du auf OOP, dein Programm orientiert sich nicht am Objekt, sondern am Typ:

class Tier * tier = new Katze();
tier->GibLaut();  // Ignoriert, dass das Objekt eine Katze ist und gibt "Hallo" aus, weil Tiere sagen nunmal "Hallo".

Laut "eurer" Definition ist das Ignorieren des Objekts trotzdem objektorientiert. Das verstehe ich nicht und niemand erklärte es mir bisher.

scrub schrieb:

Die Begrifflichkeiten virtueller Funktionen und der restliche Krempel, dies alles kam in diesem Erklärungen des Themas OO _nie_ vor, kein einziges Mal. Ich lese davon in Deinen Beiträgen zum ersten Mal.

Hast Du Dir OOP speziell bezogen auf C++ angelesen und zwar in einem SEHR detailierten Buch, oder zum Beispiel an Java oder C# gelernt?

In Java benötigst Du 'virtual' nicht, weil Java viele Dinge implizit regelt. Du kannst Objekte nicht einbetten, weil Klassen grundsätzlich Referencetypes sind und Methoden sind grundsätzlich "virtual", solange Du sie nicht als "final" (also "nicht virtual" und damit in Java als nicht überschreibbar) erklärst. In C++ musst Du Objektorientierung explizit anfordern, während Du sie in Java oder C# implizit erhälst.
C++ nimmt die schnellste Methode, Java die flexiblere. Dafür zahlt Java allerdings auch nochmal in der Laufzeit, weil auch wirklich jede kleine Funktion über OOP dereferenziert werden muss.

Wenn Du OOP aus allgemeinen Beschreibungen lernst oder eben mit Java gelernt hast, halte ich es nicht verwunderlich, dass in den Beschreibungen der Sonderfall C++ mit explizitem "virtual" nicht auftaucht.
OOP ist deswegen in Java nichts anderes als in C++. Die Sprachen sind ähnlich, aber eben nicht identisch: Man muss seine Wünsche etwas anders formulieren.

scrub schrieb:

Objektorientiert ist, wenn man statt einem Haufen Daten und einem anderen Haufen Funktionen ganz klar bestimmten Daten(-typen) bestimmte Funktionen zuordnet, man also bereits im Quelltext genau sehen kann, daß miau() zur Katzenklasse und wau() zur Hundeklasse gehört - statt sich jedesmal selbst die passende Funktion rauszuschen, die man gerade braucht.

Genau so habe ich Programmieren gelernt. Allerdings gab es zur der Zeit den Begriff "OOP" noch nicht. Seltsam. Aber egal.

scrub

Xin schrieb:

Für wau() und miau() braucht man kein OOP. Abstrahiert man das Problem, hat es allerdings Sinn eine abstrakte Form von wau() und miau() virtuell zu gestalten.

Bereits an dem Punkt scheiden sich beide Erklärungsvarianten: Gemäß den mir bekannten Definitionen ist es bereits objektorientiert, wenn ich eine Klasse "Katze" schreibe, der ich bestimmte Eigenschaften (Rasse, Geschlecht) und Funktionen (Fell abziehen, toasten) zuordne. Es ist hingegen nicht erforderlich, "Katze" von "Tier" abzuleiten oder ähnliches.
Ein ähnlicher Gedankengang, prinzipiell gesehen, steckt übrigens hinter Entgegnungen anderer wie "schon die Voraussetzungen sind falsch".

Shade Of Mine

Xin schrieb:

Ich sehe diese Diskussion ähnlich, ich bezweifle dass jemand eine nachvollziehbare Begründung finden wird, warum ein Algorithmus, der sich eben nicht am Objekt orientiert, weil virtual fehlt, als objektorientiert zu bezeichnen wäre.

Erklär mir mal kurz ob du folgendes System als OO betrachtest - es ist teil einer Ajax Library die ich verwende.

Es gibt Objekte vom Typ "XHR" diese beinhaltet grundlegende Fähigkeiten um mit anderen Servern über HTTP zu kommunizieren. Darunter die funktion "call" um eine Remote Funktion aufzurufen.

Dann gibt es Objekte vom Typ "FooXHR" der die gleichen Methoden beinhaltet wie "XHR". Darunter auch eine "call" Funktion die aber etwas komplexer ist und Daten per JSON codiert und decodiert um komplexe Funktionsaufrufe zu ermöglichen - die Signatur von FooXHR::call und XHR::call ist gleich.

Es gibt auch Objekte vom Typ BarXHR, wo die call Funktion die Daten mit etwas komplett anderen codiert. Und wenn ich will kann ich weitere Objekte erstellen die wieder die Daten komplett anders codieren.

Ich denke das würde man als OO Design ansehen, oder?

Das lustige dabei ist aber: es ist in JavaScript geschrieben: keine Klassen, kein Virtual.

Ein anderes Beispiel sind C++ Templates. Statische Polymorphie

Wenn du sagst OOP ist eine Technik die mit anderen Techniken verknüpft werden kann - was genau ist dann OOP? Datahiding kein Bestandteil der OOP? Polymorphie aber schon? Schwer zu trennen das ganze.

Ich persönlich mag folgende Definition am liebsten:
Objektorientierung ist, sich an Objekten zu orientieren.

Es gibt einfach kein Feature dass ich unbedingt zur OO zählen muss. Datahiding - ich finde zB FILE* in C objektorientiert. Da ist 0 Datahiding. Polymorphie? Klassen? Ich schreibe OO Code in Javascript.

Xin

scrub schrieb:

Xin schrieb:

Für wau() und miau() braucht man kein OOP. Abstrahiert man das Problem, hat es allerdings Sinn eine abstrakte Form von wau() und miau() virtuell zu gestalten.

Bereits an dem Punkt scheiden sich beide Erklärungsvarianten: Gemäß den mir bekannten Definitionen ist es bereits objektorientiert, wenn ich eine Klasse "Katze" schreibe, der ich bestimmte Eigenschaften (Rasse, Geschlecht) und Funktionen (Fell abziehen, toasten) zuordne.

Das ist exakt die Frage, die ich hustbaer gestellt habe.
Wenn Du eine Klasse als Namespace nutzt, kannst Du eigentlich auch die ungarische Notation verwenden und gleich C verwenden:

katze_miau( struct Katze * );

Du gewinnst nichts. Es ist wahrscheinlich, dass das Programm in der C-Variante sogar schneller wird.

scrub schrieb:

Es ist hingegen nicht erforderlich, "Katze" von "Tier" abzuleiten oder ähnliches.
Ein ähnlicher Gedankengang, prinzipiell gesehen, steckt übrigens hinter Entgegnungen anderer wie "schon die Voraussetzungen sind falsch".

Ich stimme ich, dass hier ein ähnlicher Gedankengang vorliegt und ich hoffe, das auch Jesper Deine Argumentation über die Deine letzten Postings liest und kommentiert.

Wo liegt für Dich denn der Sinn objektorientiert zu arbeiten, wenn es das Programm dadurch eventuell langsamer wird und Du nur einen einzigen Datentyp hast, an dem Du Dich orientieren kannst?

Weiterhin haben schon einige Leute nach meinem Reply auf hustbaers Posting geschrieben, aber keiner hat bisher meine Frage zu eurer Vorstellung beantwortet.

scrub

Xin schrieb:

tier.Tier::Funktion( typ Parameter )
Das unterscheidet sich von
tier_Funktion( Tier * tier, typ Parameter )
nicht. Die Methode heißt Tier::Funktion( Tier *, typ ). Wo ist der Unterschied zu "tier_Funktion( Tier *, typ )?

Der Unterschied ist ganz einfach, und genau das habe ich doch schon (implizit) gesagt: Die erste Funktion ist ganz eindeutig mit dem Objekt verbunden. Im zweiten Fall gibt es jedoch "irgendwo" "irgendeine" Funktion, die man selbst, ohne, daß man es im Quelltext vorher sieht, mit dem Tier in Verbindung bringen muß.
Und um das nochmal ganz klar zu sagen: Bereits diese Zuordnung ("mit Objekten der Klasse 'Katze' kann die Funktion 'Fell abziehen' durchgeführt werden") ist Objektorientierung. Im Sinne der Definitionen ... und so weiter.
Desweiteren würde ich mich im Fall 1 einfach darauf verlassen (dürfen), daß die Funktion des Tiers keinen Unfug anstellt. In Fall 2 mag die Funktion möglicherweise durch ihren Namen andeuten, was sie machen soll- aber darauf verlassen würde ich mich nicht.

Im Übrigen kann ich weder Java noch C#.

Xin

Shade Of Mine schrieb:

Xin schrieb:

Ich sehe diese Diskussion ähnlich, ich bezweifle dass jemand eine nachvollziehbare Begründung finden wird, warum ein Algorithmus, der sich eben nicht am Objekt orientiert, weil virtual fehlt, als objektorientiert zu bezeichnen wäre.

Erklär mir mal kurz ob du folgendes System als OO betrachtest - es ist teil einer Ajax Library die ich verwende.

Es gibt Objekte vom Typ "XHR" diese beinhaltet grundlegende Fähigkeiten um mit anderen Servern über HTTP zu kommunizieren. Darunter die funktion "call" um eine Remote Funktion aufzurufen.

Dann gibt es Objekte vom Typ "FooXHR" der die gleichen Methoden beinhaltet wie "XHR". Darunter auch eine "call" Funktion die aber etwas komplexer ist und Daten per JSON codiert und decodiert um komplexe Funktionsaufrufe zu ermöglichen - die Signatur von FooXHR::call und XHR::call ist gleich.

Es gibt auch Objekte vom Typ BarXHR, wo die call Funktion die Daten mit etwas komplett anderen codiert. Und wenn ich will kann ich weitere Objekte erstellen die wieder die Daten komplett anders codieren.

Ich denke das würde man als OO Design ansehen, oder?

Das kommt drauf an, ob die Objekte von einander abhängig sind. Wenn sie von einander abhängig sind und über eine standardisierte Schnittstellenklasse verfügen, über die man die Funktionen erreichen kann, spricht das für OOP, da die Schnittstelle ja abhängig vom Objekttyp die Funktionen aufruf:
Wenn bla vom Typ "Schnittstelle XHR" ist und bla.Snafu() die Funktion FooXHR.Snafu() aufruft, weil das Objekt auf das bla referenziert ein FooXHR-Objekt ist, dann ist das OOP.

Wenn es nur drei unabhängige Datentypen sind, die zufälligerweise die gleichen Funktionsnamen haben und die dadurch austauschbar werden, dann hat das nichts mit OOP zu tun. Das geht eher in Richtung Template, womit nicht das C++-Template gleichzusetzen ist.

Shade Of Mine schrieb:

Das lustige dabei ist aber: es ist in JavaScript geschrieben: keine Klassen, kein Virtual.

Das ist schade, ich würde es in OOP umschreiben, es wäre prädestiniert dafür.

Shade Of Mine schrieb:

Ein anderes Beispiel sind C++ Templates. Statische Polymorphie

Beispiel wofür?

Shade Of Mine schrieb:

Wenn du sagst OOP ist eine Technik die mit anderen Techniken verknüpft werden kann - was genau ist dann OOP? Datahiding kein Bestandteil der OOP? Polymorphie aber schon? Schwer zu trennen das ganze.

Eigentlich nicht. Das Überschreiben von virtuellen Funktionen ist erforderlich, sonst könnte man nicht objektabhängig unterschiedliche Funktionen rufen. Objektorientierte Abläufe sind ist ja genau der Hintergrund, weshalb man virtuelle Funktionen überschreibt.
Das Überschreiben von statischen Funktionen oder das Überladen beliebiger Methoden ist dafür nicht erforderlich.

Shade Of Mine schrieb:

Ich persönlich mag folgende Definition am liebsten:
Objektorientierung ist, sich an Objekten zu orientieren.

*lach* Die Definition ist auf den ersten Blick gar nicht mal übel.

Sie macht aber bei genauerem Hinsehen keinen Sinn, weil alles, was nicht void ist, ein Objekt ist. Würde man sich nicht an irgendwelchen Daten orientieren, bräuchte man auch man auch keine Programme zu schreiben.

Xin

scrub schrieb:

Xin schrieb:
tier.Tier::Funktion( typ Parameter )
Das unterscheidet sich von
tier_Funktion( Tier * tier, typ Parameter )
nicht. Die Methode heißt Tier::Funktion( Tier *, typ ). Wo ist der Unterschied zu "tier_Funktion( Tier *, typ )?
Der Unterschied ist ganz einfach, und genau das habe ich doch schon (implizit) gesagt: Die erste Funktion ist ganz eindeutig mit dem Objekt verbunden. Im zweiten Fall gibt es jedoch "irgendwo" "irgendeine" Funktion, die man selbst, ohne, daß man es im Quelltext vorher sieht, mit dem Tier in Verbindung bringen muß.
Und um das nochmal ganz klar zu sagen: Bereits diese Zuordnung ("mit Objekten der Klasse 'Katze' kann die Funktion 'Fell abziehen' durchgeführt werden") ist Objektorientierung. Im Sinne der Definitionen ... und so weiter.

katze_fellabziehen( Katze * ) - hier ist die Zuordnung zur Katze eindeutig.
Weiterhin ist das exakt die Signatur, die Katze::FellAbziehen( void ) im Objektfile erhalten wird.
Es ändert sich nichts, unabhängig davon, was Du persönlich für Dich als vertrauenswürdiger oder übersichtlicher empfindest, verwurstet der Compiler beides identisch.

scrub schrieb:

Desweiteren würde ich mich im Fall 1 einfach darauf verlassen (dürfen), daß die Funktion des Tiers keinen Unfug anstellt. In Fall 2 mag die Funktion möglicherweise durch ihren Namen andeuten, was sie machen soll- aber darauf verlassen würde ich mich nicht.

Darauf kannst Du Dich ebenso verlassen, wie bei bei einer Methode.
Solange Du es nicht selbst geschrieben hast, musst Du Dich darauf verlassen, dass die Funktion ihrer Dokumentation entsprichst. Das gilt ebenso für Methoden.
Wenn Du die Zuordnung selbst machst, musst Du Dich darauf verlassen, dass Du weißt, was Du tust und wie Du Dein Programm aufbaust - unabhängig ob Funktion oder Methode.

So, reicht langsam für heute - ich geh ins Bett.