Performancemythen?

DEvent

interface Collide
{
    boolean isCollide(Object b);
}

abstract class FliegendesObjekt implements Collide
{
    public boolean isCollide(Object b)
    {
        return this.collideUnknow(b);
    }

    protected boolean collideUnknow(Object unknow)
    {
        return unknow.isCollide(this);
    }
}

// Raumschiff ist ein Quader.
class Raumschiff extends FliegendesObjekt
{
    public boolean isCollide(Object b)
    {
        if ( b instanceof Raumschiff )
        {
            Raumschiff right = (Raumschiff)b;
            // vergleiche this mit right
        }
        else if ( b instanceof Rocket )
        {
            Rocket right = (Rocket)b;
            // vergleiche this mit right
        }
        else return super.isCollide(b);
    }
}

// Rocket ist ein Strich.
class Rocket extends FliegendesObjekt
{
    public boolean isCollide(Object b)
    {
        if ( b instanceof Rocket )
        {
            Rocket right = (Rocket)b;
            // vergleiche this mit right
        }
        else if ( b instanceof Raumschiff )
        {
            Raumschiff right = (Raumschiff)b;
            // vergleiche this mit right
        }
        else return super.isCollide(b);
    }
}

// in 50 Jahren
abstract class NeuesFliegendesObjekt extends FliegendesObjekt
{
    protected boolean collideUnknow(Object unknow)
    {
        throw new UnsupportedException();
    }
}

// EnterpriseSchiff ist eine Kugel
class EnterpriseSchiff extends NeuesFliegendesObjekt
{
    public boolean isCollide(Object b)
    {
        if ( b instanceof Rocket )
        {
            Rocket right = (Rocket)b;
            // vergleiche this mit right
        }
        else if ( b instanceof Raumschiff )
        {
            Raumschiff right = (Raumschiff)b;
            // vergleiche this mit right
        }
        else if ( b instanceof EnterpriseSchiff )
        {
            EnterpriseSchiff right = (EnterpriseSchiff)b;
            // vergleiche this mit right
        }
        else return super.isCollide(b);
    }
}

Wie waehrs damit? Es haette den Vorteil, dass ich weitere Objekt hinzufuegen kann, ohne den ebstehenden Code aendern zu muessen.

DEvent

Jester schrieb:

DEvent schrieb:

hmm also wenn der Programmierer an OOP gedacht hatte, waehrend er ein Algorithmus geschriebene hat, dann ist dieser automatisch OOP. Cool.

Ja, war doch garnicht so schwierig. Wobei es natürlich nicht um Algorithmen ging, und der Benutzer nicht an OOP denkt, sondern in Objekten (sie also als primäres Strukturierungsmittel einsetzt). Natürlich denkt man auch nicht nur daran, sondern verwendet sie tatsächlich so, so dass sich diese Denkweise auch im resultierenden Code niederschlägt.

Ja wie nun? Dankt man nur daran, oder macht man es auch so?

minhen

otze schrieb:

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:

Ja, eure Definition basiert auf einem undefiniertem Begriff. Aber das ist schlecht. Sehr schlecht sogar. Denn von einem wissenschaftstheoretischen Standpunkt aus ist sie damit völlig unwissenschaftlich und völlig nutzlos, da völlig beliebig und völlig willkürlich. Du bezeichnest deine Argumentation als wissenschaftlich. Doch legt man wissenschaftliche Standards an ist eure Defintion wie auch manche Argumentation hier die reinste Katastrophe, der wissenschaftliche Worst-Case, pseudowissenschaftliches Vorgehen wie es leibt und lebt. "Schwammig" war lediglich die höfliche Floskel ohne Wissenschaftstheorie explizit in den Mund zu nehmen.
Der Aufschrei ist jetzt natürlich obligatorisch, deswegen sag ich es gleich vorweg: die Begründung findet sich in meinem vorigen Beitrag. Was ich dort anführe ist nichts anderes als Wissenschaftstheorie.

Eine wissenschaftliche Argumentation wäre entweder den Kern Xins Definition direkt anzugreifen oder alternativ eine eigene, wohldefinierte, wissenschaftliche Definition anzubieten. Ersteres unterbleibt, da, wie du selbst sagst, Xins Definition Teil deines eigenen Verständnisses von OOP ist. Zweiteres dagegen unterbleibt, da du mit schwammigen Begriffen und Konzepten arbeitest.

Solange er aber auf diese Fälle nicht eingeht, zb warum statische Polymorphie kein OOP ist, können wir auch nicht weiter argumentieren.

Ich zitiere mal:

Xin schrieb:

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.

Xin schrieb:

Shade Of Mine schrieb:

In C++ und Java sieht man eben nur einen kleinen Teil der OOP. Wobei du halt auch dort Teile der OOP die sich nicht miteinander schneiden ignorierst. zB statische Polymorphie - aber wo trennt man da?

Überladene Funktionen sind Funktionen gleichen Namens aber unterschiedlicher Signatur. Sie sind damit vom Compiler problemlos zu unterscheiden. Statische Funktionen sind grundsätzlich nicht objektorientiert, sie sind eben statisch. Und sie bleiben statisch, wenn sie in einem anderen Namespace liegen. Ich sehe da eine ganz klare Grenze, die absolut keine Frage läßt: nicht OOP.

Das sind, bedenkt man Xins Verständnis eines Objekts und der Orientierung (was er beides bereits mehrmals wiederholt hat), schlüssige und einwandfreie Antworten, weshalb statische Polymorphie keine OOP ausmacht.
Es fragt sich also wer hier wessen Aussagen ignoriert ...

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.

Nein. OO ist nach Stroustrup die eine, OOP die andere Sache. Mein vorletzter Satz räumt dabei implizit die mögliche Existenz von OOP in Nicht-OO-Sprachen ein. Eine konkrete Existenzaussage wird nicht getroffen, es wird aber sehr wohl die Möglichkeit eingeräumt. Daraus folgt natürlich, dass OOP auch ohne OO-Sprache möglich ist.

Jester schrieb:

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.

Mir lügen zu untestellen, nur weil du die entsprechende Aussage von Xin ignorierst, vergessen oder nicht verstanden hast, ist nicht nur ausgesprochen arrogant sondern auch dreist.

Aber ich will ja nicht so sein:

Xin schrieb:

Mir bedeutet Logik etwas. Daran halte ich mich. Solange Du nicht mehr zu bieten hast als "Ich stimme nicht zu" und in Deinen Quellen nicht das "Warum" zitieren kannst, bedeutet mir Dein Wort genausowenig wie die Links.

Um das zu verstehen muss man natürlich Logik und Argumentation kennen. Wenn man Xin also etwas vorwerfen kann, dann, dass er "zuviel" Wissen voraussetzt. Zum Thema Logik und Argumentation:
Die Wahrheit einer Aussage ist davon logisch unabhängig wer sie tätigt.
Die Wahrheit einer Aussage ist davon logisch unabhängig wieviele sie für wahr oder falsch halten.
Das sind Grundregeln der Logik in der Argumentation und auf diese beruft sich Xin hier ziemlich eindeutig.

otze

Xin, du zeigst grad herrliche sturheit, und eine enorme fähigkeit das problem zu verkennen. Ich werde deine beleidigungen ignorieren, und einfach weitermachen.

Würdest Du bitte das Posting lesen. Ich bin aus dem Alter raus, um im Niveau "Das ist mein Sandschäufelchen" zu diskutieren, meine Güte...

Ja, ich habs gelesen. Ich weis nicht, was es mit Sandschäufelchen zu tun hat, aber ok. Fakt ist, du brauchst im zweifel 2 algorithmen. Wenn du sie nun in 1 funktion propfst ist das zwar sehr zweifelhaft, aber irgendwie kann man das sicher zurechtbiegen. Wichtig ist aber in dem Zusammenhang, dass für einen leser des codes nicht ersichtlich ist, ob ein bestimmter algo nun in collide fehlt, weil er vergessen wurde, oder ob er fehlt weil er in einer anderen Klasse drin steckt. Er muss also in jedem Fall beide Klassen anschauen um diese Frage zu beantworten. bei multimethoden steht das alles direkt untereinander in einer einzelnen Datei.

class Object
{
  vortual bool collide(const Object* o)const = 0;
}
Hast Du collide in Bar nicht definiert, meckert er, weil die Stelle, die Du markiert hast sonst nicht möglich wäre.

Darum geht es aber nicht. Wenns collide nicht gibt knallts, das ist klar.
Aber du musst dran denken, dass du Collide erweitern musst, darum und um nichts anderes, und kein pure virtual wird dich davor retten. Auch der Compiler wird dir nicht sagen, dass ein if zweig fehlt für den fall, dass du Rocket neu deklariert hast und Asteroid::collide noch keinen test für rocket besitzt(oder Rocket kein Test für Asteroide, oder irgendeine der beiden Klassen ein collide für beide Fälle). Für genau diesen Fall brauchst auch du eine exception. Dein Nachteil ist, dass du nicht sicher sein kannst, wann die exception geworfen wird, denn dieser Fall dass Asteroide und Rocket kollidieren muss erstmal auftreten. bei multimethods kann diese exception aber garnicht auftreten.
Schau dir nochmal den von mir geschriebenen Code an, und du wirst das Problem selbst erkennen.

Ansonsten weise ich vorsichtig auf die Verwendung von Referenzen hin, wobei ich die Nutzung von const in einem Beispielcode schon löblich finde.

nö, muss ich nicht. referenzen sind in einer polymorphen umgebung meistens hinderlich und für container brauchst du eh pointer. Mal davon ab brauchst du mir wohl nicht zu erklären, wie man C++ programmiert, danke.

otze schrieb:
oder willst du jetzt sogar für jede neue Klasse das Interface ändern?
class Object
{
    public:
       virtual bool collide(const Rocket*)=0;
       virtual bool collide(const Asteroid*)=0;
       virtual bool collide(const Starship*)=0;
};
Du hast absolut keine Vorstellung, was OOP ist, richtig?
Vielliecht eine vage Vermutung, aber selbst mit dem Standard-Unsinn, kann ich mir die Frage hier nicht mehr erklären.

Komm, Du darfst das Schäufelchen haben...

http://de.wikipedia.org/wiki/Sarkasmus

Dass du mir btw sone Designkatastrophe zutraust, spricht Bände

@DEvent

Wie waehrs damit? Es haette den Vorteil, dass ich weitere Objekt hinzufuegen kann, ohne den ebstehenden Code aendern zu muessen.

wir haben darüber shcon gesprochen, oder das ist ATM Xins position. Aber deine Implementation hat den Nachteil, dass sie bei nicht kommutativen funktionen nicht funktioniert. dafür brauchst du dann einen weiteren parameter der angibt, welches Objekt nun das aufrufende ist, und musst daran dann wieder unterscheiden. Auf diese Weise funktioniert es dann, aber ist fehleranfällig. Was ist, wenn ein Programmierer eine kollision vergisst oder ein vorhandenes Objekt das kollidieren kann nicht kennt und diese kollision dann auftritt?
In dem Fall kommts bei dir zu einer endlosschleife, weil er andauernd die Parameter versucht zu tauschen um eine passende funktion zu finden(mit parameter kannste das testen, aber dann musst du eine exception werfen, und eben die will Xin ja nicht haben).

Bei multimethods, zumindest wie sie in C++ implementiert werden können, gibts zur compilezeit den Fehler.

Jester

minhen schrieb:

Mir lügen zu untestellen, nur weil du die entsprechende Aussage von Xin ignorierst, vergessen oder nicht verstanden hast, ist nicht nur ausgesprochen arrogant sondern auch dreist.

Offensichtlich scheinst Du das was er betreibt ja für Logik zu halten und die Schlüsse auch für logisch zu halten. Das macht ja auch nix. Schließlich ist deren Wahrheitsgehalt ja nicht davon abhängig ob Du sie für wahr/gültig hältst oder nicht. Es ist also ziemlich dreist und arrogant und so von Dir mir zu unterstellen ich würde lügen, wenn ich sage dass das nicht stimmt... oder so ähnlich.

Um das zu verstehen muss man natürlich Logik und Argumentation kennen.

Ja, das sind zufällig zwei Dinge mit denen ich mich recht gut auskenne.
Ich halte das was er vorträgt nicht für schlüssig und insbesondere bin ich der Meinung, dass seine Definition nicht das abdeckt, was OOP ausmacht. Es deckt eben nur einen Teil davon ab und ist damit als Definition ungenügend. Vom wissenschaftstheoretischen Standpunkt vielleicht nicht katastrophal, aber halt unnütz. Mein OOP-Methodenbaukasten enthält mehr als virtual (nämlich vor allem Objekte als zentrales Abstraktionsmittel und entsprechende Kompositionstechniken), aber das habe ich ja schon mehrfach erklärt. Eine OOP-Definition, die diese Dinge nicht mit abdeckt greift zu kurz.

Dadurch, dass ich einen recht umfangreichen Teil meines Studiums auch mit Mathematik verbracht habe, denke ich auch ganz gut einschätzen zu können, wann eine Definition etwas taugt, sowie was schwammig ist und was nicht.

So, nun kannste mich dann aburteilen.

Xin

minhen schrieb:

Wenn man Xin also etwas vorwerfen kann, dann, dass er "zuviel" Wissen voraussetzt.

Hmm... ich weiß nicht...?! Was muss man denn alles Wissen, um meine Definition zu verstehen?
Eigentlich dachte, ich hätte alles notwendige Wissen oft genug vorgestellt und man müsste das nur lesen.

otze schrieb:

Xin, du zeigst grad herrliche sturheit, und eine enorme fähigkeit das problem zu verkennen. Ich werde deine beleidigungen ignorieren, und einfach weitermachen.

Schade eigentlich.

otze schrieb:

Xin schrieb:

Würdest Du bitte das Posting lesen. Ich bin aus dem Alter raus, um im Niveau "Das ist mein Sandschäufelchen" zu diskutieren, meine Güte...

Ja, ich habs gelesen. Ich weis nicht, was es mit Sandschäufelchen zu tun hat, aber ok. Fakt ist, du brauchst im zweifel 2 algorithmen.

Bei nicht kommutativen Dingen, kann das passieren. Aber keiner zwingt mich, deswegen alte Klassen anzufassen.

otze schrieb:

Wenn du sie nun in 1 funktion propfst ist das zwar sehr zweifelhaft, aber irgendwie kann man das sicher zurechtbiegen. Wichtig ist aber in dem Zusammenhang, dass für einen leser des codes nicht ersichtlich ist, ob ein bestimmter algo nun in collide fehlt, weil er vergessen wurde, oder ob er fehlt weil er in einer anderen Klasse drin steckt. Er muss also in jedem Fall beide Klassen anschauen um diese Frage zu beantworten. bei multimethoden steht das alles direkt untereinander in einer einzelnen Datei.

Das ist ein akzeptables Argument.
Aber es ist überwiegt nicht.

In meinem Fall gibt es genau zwei Möglichkeiten, den Algorithmus unterzubringen. Von "nicht ersichtlich" kann man da noch nicht sprechen. In Deinem Fall gibt es beliebig viele Möglichkeiten, die Multimethoden unterzubringen, von denen eine sinnvoll erscheint. Wenn der Entwickler ausreichend Disziplin hat, gibt's nur eine Möglichkeit den entsprechenden Part einer Multimethode zu finden. Fehlt die Disziplin, dann gute Nacht.
Dafür musst Du bei einer Erweiterung viele Dateien anfassen und dafür sorgen, dass Du nichts vergisst, denn der Compiler meckert nicht, wenn Du's vergißt.

Was Du sagst, ist nicht falsch. Wo man hier mehr Vorteile sieht - 2 Möglichkeiten und nur eine Datei ändern - oder (hoffentlich) nur eine Möglichkeit und viele Dateien anfassen (hoffentlich vergisst man keine) - dann kann ich das als Meinung durchaus akzeptieren.
Ich teile sie nicht.

Aber hier stehen die OO-Möglichkeiten überhaupt nicht zur Diskussion - also warum diskutierst Du mit mir derart unwichtige Details?
Widerlege doch lieber mal meine Vorstellung von OOP, darum geht's doch hier.

otze schrieb:

class Object
{
  vortual bool collide(const Object* o)const = 0;
}
Hast Du collide in Bar nicht definiert, meckert er, weil die Stelle, die Du markiert hast sonst nicht möglich wäre.
Darum geht es aber nicht. Wenns collide nicht gibt knallts, das ist klar.
Aber du musst dran denken, dass du Collide erweitern musst,

Ich schrieb bereits, warum ich die Collide-Versionen von zuvor geschriebenen Objekten nicht erweitern muss, inkl. Berücksichtigung von Kommutativität.

Ansonsten weise ich vorsichtig auf die Verwendung von Referenzen hin, wobei ich die Nutzung von const in einem Beispielcode schon löblich finde./quote]
nö, muss ich nicht. referenzen sind in einer polymorphen umgebung meistens hinderlich und für container brauchst du eh pointer.

Referenzen sind Pointer, die lediglich sichererstellen (das Wort ist korrekt geschrieben), dass der Zeiger valid ist. Ein Vorteil, den man nicht unbedingt verwerfen muss.

otze schrieb:

Dass du btw nicht gemerkt hast, dass ich das niemals hätte ernst meinen können zeugt nicht grade von Respekt gegenüber dem gesprächspartner(wie du mit der Antwort ansich eigentlich sehr schön beweist).

*lach*, der war gut.

Außerdem, was willst Du? Ich nehm Dich mit dem Posting doch auch nicht ernst, warum beschwerst Du Dich also jetzt?
Wenn Du Respekt willst, schreib doch etwas, was man ernstnehmen kann.

Jester schrieb:

Dadurch, dass ich einen recht umfangreichen Teil meines Studiums auch mit Mathematik verbracht habe, denke ich auch ganz gut einschätzen zu können, wann eine Definition etwas taugt, sowie was schwammig ist und was nicht.

*WINK*
Mehrere Befürworter der Standard-Definition haben schon klargestellt, dass (Zitat) *die* (/Zitat) Definition schwammig ist, was wissenschaftlich, wie mathematisch bedeutet: Taugt nix.
Wenn Du als mathematisch geschulter Mensch "schwammig" als mathematisch akzeptabel beschreibst, dann habe ich den Verdacht, dass der recht umfangreiche Anteil Deines Studiums Mathematik dadurch zustande kam, weil Du die Matheschein nie beim erstenmal bekommen hast. Das ist allerdings eine reine Mutmaßung, keine Behauptung.

Entweder die Definition ist schwammig, weil alle sie verstanden haben und davon einige festgestellt haben, dass sie schwammig ist, oder Du hast Deine eigene Definition und die anderen haben eine andere. Dann gibt es aber keine "Standard-Definition", dann reimt sich jeder was eigenes zusammen. Und das ist definitiv auch keine Definition.

Wenn Du Dich zufällig mit Logik ganz gut auskennst - wie Du ja schreibst - dann weißt Du sicher, dass man Schwachpunkte in Definitionen nicht durch Ignorieren beseitigt.

Mr. N

Xin schrieb:

Wenn Du Respekt willst, schreib doch etwas, was man ernstnehmen kann.

Wenn du Respekt willst, lern mal über den Tellerrand zu schauen und vielleicht sogar, was Multimethoden sind.

(Da ich keinen Respekt will kann ich hier wunderbar rummeckern.)

dv_

C++ 5-10mal langsamer als C.
Plattformunabhängiger Assembler.
Nutzt man OOP bei Funktionsrufen, wo keine Entscheidungen zu treffen sind, so verliert man Zeit.

Bitte Xin, werd kein Informatiklehrer/professor. Schreib keine Bücher. Behalt deine "Weisheiten" für dich. Wir haben schon genug IT-Verbrechen wie libxml. Danke.

Simon2

Wird eigentlich irgendjemand hier pro Buchstabe bezahlt ?
Kann es sein, dass irgendjemand "OO (nicht) ist langsamer" als Performancemythos dargestellt hat und anschließend 20 Seiten über die Definition von OO und später über Sprachvorteile gestritten hat (was ein prima Themen für eigene Threads wären).

Mein Vorschlag: Lasst uns doch mal stichwortartig die bisher entdeckten/vermuteten Performancemythen auflisten.

Ich fang' mal an:
- "OO ist (nicht) schlecht für Performance"
- "Die Ordnung eines Algorithmus' ist nicht das einzige Bewertungskriterium für die Performance"
- ...

Was fällt Euch noch auf ?

Gruß,

Simon2.

Shade Of Mine

@DEvent:
call mal bitte basisklasse::mach_was aus der "abgeleiteten" klasse
Das ist keine vererbung, das ist object cloning. du hast dort btw auch keine virtuellen funktionen auf die Xin so steht

Xin schrieb:

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

OK, das ist der Beweis: du kennst nur C++/Java und baust darauf deine kleine OO Welt auf. Macht also keinen Sinn mehr zu diskutieren. Deshalb kleiner Tip an dich: schau dich mal um welche OO Features andere Sprachen haben. Es ist ein wahnsinnig interessantes Thema. OO ohne Klassen zu programmieren - siehe zB JavaScript. Man kann sich zwar Objekte so hinbiegen dass sie ein bisschen wie Klassen wirken, aber man verliert dadurch soviel was JS einem bieten kann.

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Aber man hat keine virtuellen funktionen.

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.

Geil. Du weisst nicht was multimethoden sind aber versuchst mitzureden
multimethoden dispatchen zur laufzeit wenn nötig.

Fragen beantwortet, obwohl sie teils "Warum ist es nachts kälter als draußen?" Charakter haben. Hast Du noch mehr Fragen?

es waren die essentiellen fragen ob du dich mit OOP auskennst - du hast versagt. danke.

Die übliche Definition ist also Deiner Aussage nach, dass es nicht genau zu definieren ist. Und damit ist die Mehrzahl dann zufrieden?
Klasse Definition.

Exakt. Weil es eine Denkweise und keine technik ist.

Sprachen neben C++ oder Java machen mir keine bisher Probleme. Mal eben "LISP" einzuwerfen ohne etwas konkretes zu aufzeigen, was meiner Aussage widerspricht, ist dafür etwas wenig.

multimethoden habe ich eingeworfen die kennst du nicht und prototype sprachen kennst du auch scheinbar nicht. also was willst du? alles was du nicht kennst ignorieren?

Zumal Du erstmal Deine Definition an C++ belegen darfst - ich erinnere an die immernoch nicht beantwortete Frage von mir.
Wenn meine Definition auf LISP nicht passen würde, dann wäre das schlecht, aber die "Standard"-Definition passt nichtmals auf C++.

Und genau das ist der Punkt: eine Sprache ist nicht OO sondern ein Programm. C++ unterstützt OO features wie vererbung, polymorphie aber man muss nicht OO programmieren. in der tat sind die meisten C++ programme nicht rein OO.

Der Spaß heißt Reflection. Falsche Baustelle.

Nein, ein sehr relevanter Punkt: wie dynamisch muss Polymorphie sein damit sie polymorphie ist?

Bei wikipedia wird zB überladung bereits zur polymorphie gezählt. ist es nicht interessant dass deine definition nicht die einzig mögliche ist?

zumal du ausser C++ und Java nichts kennst - klar auf C++ und Java trifft deine Definition teilweise zu - aber du hast bereits mehrmals von Forengrößen hier gehört, dass sie OOP als eine Denkweise verstehen. Denk mal darüber nach.

Ich kann dir wirklich nur ans herz legen deinen horizont zu erweitern. Sprachen wie Self und LISP lernen dir ein komplett neues verständnis von OOP. Deshalb verstehst du uns hier auch nicht. Wir sind von dem Klassen denken komplett weg. Und ohne Klassen keine Vererbung und keine virtuellen Funktionen.

Jester

Xin schrieb:

Wenn Du als mathematisch geschulter Mensch "schwammig" als mathematisch akzeptabel beschreibst, dann habe ich den Verdacht, dass der recht umfangreiche Anteil Deines Studiums Mathematik dadurch zustande kam, weil Du die Matheschein nie beim erstenmal bekommen hast. Das ist allerdings eine reine Mutmaßung, keine Behauptung.

War mir fast klar, dass jetzt sowas in der Art kommt. Ich weiß was ich kann. Du bist nicht in der Position das in Frage zu stellen. Dementsprechend ist meine Motivation Dir jetzt irgendwas zu beweisen ziemlich gering. Aber ich kann natürlich meinerseits Vermutungen über Deinen mathematischen Bildungsstand tätigen sowie Deine Erfahrung in logischem Schließen. Über meine Studienleistungen bewahre ich jetzt einfach mal stillschweigen... wäre der Abschluß zu gut, dann bin ich ja völlig unbrauchbar und hab nur auswendig gelernt, ist er zu schlecht bin ich gleich doof. Und notfalls war's halt einfach ne Billiguni. Auf diese Kindereien hab ich einfach keinen Bock.

otze

Ich versuch mal eine weniger schwammige definition aufzustellen(ich hab kein mathematisches Studium und bin kein Diplominformatiker, darum: kreuzigt mich nicht).

Die Objektorientierte Programmierung versucht die Eigenschaften, abhängigkeiten und interaktionsmöglichkeiten von Objekten zu abstrahieren und als programmcode zu modellieren. Die OOP versucht somit, die Denkweise des Menschen direkt als programmcode umzusetzen.

Ein Objekt ist eine Abstraktion eines Physischen oder logischen Gegenstandes. Objekte zeichnen sich dadurch aus, dass sie Zustände und logische Abhängigkeiten untereinander besitzen. Diese Abhängigkeiten können in Form von Vererbung,Komposition oder Interaktion ausgedrückt werden. Der Zustand eines Objektes ist gekapselt und die kontrolle über ihn obliegt allein dem Objekt.

//edit hmm lange nicht komplett. schwer zu definieren. wie bringt man zb rein, dass Funktionen als Objekte augefasst werden können oder dass sogar der Programmcode selbst ein Objekt ist?

Xin schrieb:

Wenn Du als mathematisch geschulter Mensch "schwammig" als mathematisch akzeptabel beschreibst, dann habe ich den Verdacht, dass der recht umfangreiche Anteil Deines Studiums Mathematik dadurch zustande kam, weil Du die Matheschein nie beim erstenmal bekommen hast. Das ist allerdings eine reine Mutmaßung, keine Behauptung.

Dafür bekommst du inf *lol*-Punkte. Echt.

Xin

Shade Of Mine schrieb:

Xin schrieb:

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

OK, das ist der Beweis: du kennst nur C++/Java und baust darauf deine kleine OO Welt auf.

Es beweist, dass ich kein brauchbare Erfahrung in LISP habe, um damit zu argumentieren.

Shade Of Mine schrieb:

Macht also keinen Sinn mehr zu diskutieren. Deshalb kleiner Tip an dich: schau dich mal um welche OO Features OO ohne Klassen zu programmieren - siehe zB JavaScript. Man kann sich zwar Objekte so hinbiegen dass sie ein bisschen wie Klassen wirken, aber man verliert dadurch soviel was JS einem bieten kann.

Ich habe OO in JS programmiert, um SVG Dokumente zu bearbeiten und habe dafür u.a. grafische Elemente programmiert, wie Buttons, Listenwidgets usw.

Shade Of Mine schrieb:

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Aber man hat keine virtuellen funktionen.

Wo steht, dass man virtuelle Funktionen oder Klassen für OOP braucht?
Man braucht eine Methode, um OOP umzusetzen und das geht in C++ in der Regel mit virtuelle Methoden.
Man könnte auch z.B. Funktionszeiger verwenden. Es reicht jedenfalls nicht "plain classes" zu nehmen.

Shade Of Mine schrieb:

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.

Geil. Du weisst nicht was multimethoden sind aber versuchst mitzureden
multimethoden dispatchen zur laufzeit wenn nötig.

Ich war in dem Moment bei Überladen in etwa der Form:

bool operator =( BasisObjekt & lhs, BasisObjekt &rhs )

so dass die OO-Möglichkeiten über virtuelle Basisobjekte realisiert würden.
Mea culpa.

Wie ich schon zuvor schrieb: sobald man sich irgendwo einen Irrtum erlaubt, wird es als ultimativer Beweis gewertet. Ich seh's positiv: Ich habe sehr viele Antworten geschrieben, ohne mir Fehler zu erlauben.
Im Verhältnis liege ich damit weiterhin recht gut.

Shade Of Mine schrieb:

Die übliche Definition ist also Deiner Aussage nach, dass es nicht genau zu definieren ist. Und damit ist die Mehrzahl dann zufrieden?
Klasse Definition.

Exakt. Weil es eine Denkweise und keine technik ist.

weil...

Ich lese immer nur Behauptungen und "Du hast nicht recht".

Shade Of Mine schrieb:

Und genau das ist der Punkt: eine Sprache ist nicht OO sondern ein Programm. C++ unterstützt OO features wie vererbung, polymorphie aber man muss nicht OO programmieren. in der tat sind die meisten C++ programme nicht rein OO.

Rein "OO"? Was ist denn reines "OO"?
Ist das sowas wie "Anfänger OO" und "Experten OO", was ich hier schon lesen musste?
Entweder ist es "OO" oder nicht "OO".
Abgesehen davon, dass es bei Dir auch schmutziges OO zu geben scheint, unterscheidest Du wenigstens zwischen OO-Sprache - sie es nicht gibt - und OO-unterstützende Sprachen. Wir sind uns diesbezüglich also einig.

Shade Of Mine schrieb:

Der Spaß heißt Reflection. Falsche Baustelle.

Nein, ein sehr relevanter Punkt: wie dynamisch muss Polymorphie sein damit sie polymorphie ist?

Ich sehe hier keine Relevanz. Begründe, warum Du sie siehst.
Für OO muss ich zur Laufzeit auf überschriebene Funktionen zugreifen können, die objekt orientiert ausgewählt werden. Ich muss die Funktionen aber nicht zur Laufzeit austauschen können. Das ist die Baustelle von Reflection.

Shade Of Mine schrieb:

Bei wikipedia wird zB überladung bereits zur polymorphie gezählt. ist es nicht interessant dass deine definition nicht die einzig mögliche ist?

Überladung gehört zur Polymorphie. Das entspricht meiner Definition.
Überladung ist ein Part der Polymorphie, der nicht für OOP notwendig ist.
Das Überschreiben hingegen ist notwendig. Das könnte ein Grund sein, warum man zwischen Überschreiben und Überladen unterscheidet?

Shade Of Mine schrieb:

zumal du ausser C++ und Java nichts kennst

*smile*
Das lohnt einen Kommentar einfach nicht.

Shade Of Mine schrieb:

Ich kann dir wirklich nur ans herz legen deinen horizont zu erweitern. Sprachen wie Self und LISP lernen dir ein komplett neues verständnis von OOP. Deshalb verstehst du uns hier auch nicht. Wir sind von dem Klassen denken komplett weg. Und ohne Klassen keine Vererbung und keine virtuellen Funktionen.

Vererbung und virtuelle Funktion geht problemlos ohne Klassen, aber nicht ohne Klassifizierung.
C hat keine Klassen und man kann trotzdem OOP verwenden.

Damit Klassifizierung einfacher zu beschreiben ist, hat man in C++ Klassen.

Lies meine Postings, alles schon längst beschrieben.

Jester

Xin schrieb:

Exakt. Weil es eine Denkweise und keine technik ist.

weil...

Ich lese immer nur Behauptungen und "Du hast nicht recht".

Hä?

"Das ist ein Apfel" -- "Weil?" Was soll man denn dadrauf antworten? Es ist nicht logisch, dass ein Apfel "Apfel" heißt... es ist einfach so.

Shade Of Mine

Xin schrieb:

Entweder ist es "OO" oder nicht "OO".

klingt sehr vereinfacht. warum muss alles schwarz oder weiß sein? kann nicht etwas grau sein?

in c++ habe ich zB programme die teilweise aus reinem C code bestehen - weil es eben alter Code ist, der nach und nach an C++ angepasst wird. Ist jetzt alles OO oder sind nur teile OO oder ist garnichts OO?

Abgesehen davon, dass es bei Dir auch schmutziges OO zu geben scheint, unterscheidest Du wenigstens zwischen OO-Sprache - sie es nicht gibt - und OO-unterstützende Sprachen. Wir sind uns diesbezüglich also einig.

Was ist schmutziges OOP?
Ich betone doch die ganze Zeit, dass OO deine Denkweise ist. Also gibt es in meinen Augen auch keine OO Sprachen.

Wenn du JS programmiert hast - dann erklär mir mal fix wieso du dort keine OO hast. Oder hast du sie doch - wenn ja, dann widersprichst du dir ja, weil es in JS keine virtuellen Funktionen gibt. Es gibt kein dynamisches dispatchen.

Ich sehe hier keine Relevanz. Begründe, warum Du sie siehst.
Für OO muss ich zur Laufzeit auf überschriebene Funktionen zugreifen können, die objekt orientiert ausgewählt werden. Ich muss die Funktionen aber nicht zur Laufzeit austauschen können. Das ist die Baustelle von Reflection.

Warum?
Ich rede nicht von austauschen zur Laufzeit. Ich rede einfach nur von Laden von Klassen zur Laufzeit. Warum ist es Polymorphie wenn ich die Klassen die es gibt doch eh statisch vor mir habe? Wo trennst du ab wann etwas zu statisch für Polymorphie wird.

Nehmen wir das Shape-Circle-Triangle Beispiel. So wirklich toll dynamisch ist es nicht, weil ich ja nur Circle und Triangle habe. Warum ist es dennoch Polymorphie? Schließlich stehen die Klassen zur Compiletime fest die es gibt. Wirklich dynamisch wäre es erst, wenn man zur Laufzeit unendliche neue Klassen nachladen würde.

Worauf ich hinaus will ist: du ziehst einen Trennstrich den es nicht mehr gibt. Moderne VMs wie Java und .NET erlauben es die Compiletime der Runtime gleichzusetzen. Es gibt keine "das ist statisch" und "das ist dynamisch" Situationen mehr. Denn die Kompilierung findet während der Laufzeit statt und ich kann jederzeit neue Elemente nachladen.

Shade Of Mine schrieb:

Überladung gehört zur Polymorphie. Das entspricht meiner Definition.
Überladung ist ein Part der Polymorphie, der nicht für OOP notwendig ist.
Das Überschreiben hingegen ist notwendig. Das könnte ein Grund sein, warum man zwischen Überschreiben und Überladen unterscheidet?

Nach welchen Gesichtspunkten trennst du Polymorphie? Einfach wie du lustig bist...? Du sagst wunderschön dieser Teil ist OO, dieser Teil nicht - aber erklär echt mal wie du JS siehst: es gibt keine Vererbung, keine Polymorphie - es gibt dort nur Objekte.

Vererbung und virtuelle Funktion geht problemlos ohne Klassen, aber nicht ohne Klassifizierung.
C hat keine Klassen und man kann trotzdem OOP verwenden.

Vererbung ist für dich also auch Object Cloning?

Xin

otze schrieb:

Ich versuch mal eine weniger schwammige definition aufzustellen(ich hab kein mathematisches Studium und bin kein Diplominformatiker, darum: kreuzigt mich nicht).

Keine Sorge, der Versuch ist nicht strafbar.

Wenn Du OOP definierst, warum definierst Du dann, was ein Objekt ist und was man damit machen darf und was nicht?

Wir sind uns einig, dass ein Objekt "irgendein Ding" ist. Belassen wir es doch dabei, wo liegt der Vorteil sich einzuschränken?
Damit der Computer Objekte unterscheiden kann, benötigt ein Objekt eine Typinformation, darum leitet sich in Java alles von Object ab und für RTTI benötigt man in C++ ein Objekt, dass mindestens einen virtuellen Destruktor enthält. Objekte ohne virtuellen Destruktor haben diese Information nicht, können aber trotzdem "irgendein Ding" beschreiben, sind also Objekte.

Um sich am Objekt orientieren zu können, benötigt man etwas, woran man sich orientieren kann. Das kann die VTable sein, die erstellt wird, sobald man die erste virtuelle Funktion erstellt.
Man kann Objekte aber auch unterscheiden, in dem man jedem Objekttyp eine ID verpasst und danach entscheidet. Das ist sehr unschön, aber darüber lässt sich OOP realisieren.
Man kann auch jedem Objekt Funktionspointer mitgeben, die - abhängig vom Objekt - angeben, wo man hinspringt. Die müssen objekttypabhängig initialisiert werden und obwohl sie vom (statischen) Typ abhängig sind, finden sie sich nicht in einer statischen Jumptable, sondern im Objekt.

Für Multimethoden gilt das gleiche: Der Objekttyp muss im Objekt bekannt sein. Statt über Jumptable zu gehen, untersucht man die ObjektTypen und entscheidet sich dann für die passende Funktion.

In allen Fällen wird abhängig vom Objekttyp gehandelt. Das alles ist OOP. Und das ist auch die Definition von OOP:
"OOP liegt vor, wenn Objekte sich abhängig von ihrem Objekttyp verhalten und nicht abhängig vom ReferenzTyp, der auf das Objekt zeigt.":

#include <iostream>

class Tier 
{ 
  public: 
    void GibLaut() { std::cout << "Hallo!"; }   // mit virtual wäre es OOP.
}; 

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

int main( void )
{
  class Tier * tier  = new Katze(); 
  tier->GibLaut();  
}

Jester schrieb:

Xin schrieb:

Exakt. Weil es eine Denkweise und keine technik ist.

weil...

Ich lese immer nur Behauptungen und "Du hast nicht recht".

Hä?

"Das ist ein Apfel" -- "Weil?" Was soll man denn dadrauf antworten? Es ist nicht logisch, dass ein Apfel "Apfel" heißt... es ist einfach so.

OOP ist eine Technik. Ich habe ausführlich erklärt warum. Grade eben wieder. Es geht also doch.

Shade Of Mine

Xin schrieb:

In allen Fällen wird abhängig vom Objekttyp gehandelt. Das alles ist OOP. Und das ist auch die Definition von OOP:
"OOP liegt vor, wenn Objekte sich abhängig von ihrem Objekttyp verhalten und nicht abhängig vom ReferenzTyp, der auf das Objekt zeigt.":

Und warum genau ist dann die Definition
"Objekt orientierung bedeutet sich an den Objekten zu orientieren [was das verhalten des Programmes betrifft]" falsch?

Du wandelst dich langsam doch noch in die richtige Richtung - auch wenn dasn eine 180° Kurve ist.

Nichts anderes als das sagen wir hier die ganze Zeit: OOP ist eine Denkweise in der das Objekt das Zentrum dastellt. Ich brauche dafür aber keine dynamische Polymorphie - ich kann das auch mit statischer machen - solange das Objekt das Zentrum ist, das Objekt das verhalten festlegt.

PS:
deine Definition impliziert dass es Typen und Referenzen gibt - 2 Sachen die ich nicht unbedingt voraussetzen würde um ein OO Programm zu haben.

otze

Xin schrieb:

"OOP liegt vor, wenn Objekte sich abhängig von ihrem Objekttyp verhalten und nicht abhängig vom ReferenzTyp, der auf das Objekt zeigt.":

Das ist aber unlogisch. Ein Objekt muss sich immer so verhalten, wie der Referenztyp der auf es zeigt, denn der Referenztyp gibt die definition darüber, was das Objekt ist. Du kannst das Objekt nicht anders verwenden als der Referenztyp zulässt, und der Objekttyp darf sich niemals anders verhalten als das was die zusicherungen erlauben.

Im Zuge dieser Definition ist es völlig egal, ob sich nun der Referenztyp selbst um das verhalten kümmert, oder ob in anderes Objekt diese Arbeit erledigt, es gilt immer "pacta sunt servanda"- verträge müssen eingehalten werden. Solange dies gilt ist es für den aufrufer nebensächlich, was passiert, er fordert einen vertrag ein, und das Objekt kümmert sich darum, das er eingehalten wird.

Am Ende ist OOP nicht mehr als das. Ich halte mich an bestehende Verträge mit den Objekten und tue das, was mir erlaubt wird, aber erstelle meinerseits neue Verträge, an die sich andere Objekte halten müssen.

Mr. N

Dieser Thread hat Kult-Potenzial.