Vererbung & Polymorphie anhand von Beispiel erklären

Xin

TyRoXx schrieb:

Warum hat Encrypter überhaupt Methoden für beide Richtungen?

Ich habe sie jetzt einfach mal Encrypter genannt, weil ich den Namen der Basisklasse jetzt auch nicht wirklich vorschreibe. Es kann auch CryptBase oder was auch immer sein.

TyRoXx schrieb:

Man benötigt doch an einer Code-Stelle so gut wie immer nur eine der beiden Richtungen. Die Schnittstelle ist also unnötig groß.
Und lass mich raten: Die beiden Methoden sind bei Caesar fast identisch. An einer Stelle steht so etwas wie 26-n wo in der anderen Methode nur n steht.

Es geht mir hier darum, ein Beispiel für Vererbung und virtuelle Funktionen zu präsentieren. Ein Übungsbeispiel. Und "Ein" steht für 1.

Und Caesar und Atbash sind leicht zu implementieren, weil es zwar durchaus eine Programmier-Übung sein soll, aber eben kein Programmier-Projekt.

TyRoXx schrieb:

Xin schrieb:

Das ist eher imperative Herangehensweise, aber OOP ist auch nur ein imperatives Design-Pattern. Wenn man OOP die Magic nimmt, wird es leichter begreifbar.

!?
Erstaunlich... dass das mal einer gut findet. ^^

In der Regel bekomme ich von den "Experten" dafür einen auf den Deckel, weil OOP ja nicht mit Funktionen arbeitet sondern mit "Messages" und das ganze ja abstrahiert (eben so, dass es keiner kapiert) und man das deswegen auch nich so konkret beschreiben darf.

Dafür kapieren die Studenten, was sie tun.

volkard

Xin schrieb:

TyRoXx schrieb:

Xin schrieb:

Das ist eher imperative Herangehensweise, aber OOP ist auch nur ein imperatives Design-Pattern. Wenn man OOP die Magic nimmt, wird es leichter begreifbar.

!?
Erstaunlich... dass das mal einer gut findet. ^^

Find ich auch gut.

Sqwan

TyRoXx schrieb:

Xin schrieb:

icarus2 schrieb:

Angenommen ihr müsstet einer Gruppe von ca. 30 Studenten innerhalb von 45 Minuten Vererbung und Polymorphie erklären: Welches Beispiel würdet ihr dafür verwenden?

Ich verwende in der Regel eine Klasse, die Strings verschlüsselt: Es gibt eine Basisklasse Encrypter mit virtuellen Funktionen encrypt und decrypt, davon leite ich Atbash (a<->z, b<->y...) und Caesar ab.

Warum hat die Klasse Encrypter eine Methode decrypt ? Das ist ein Widerspruch.
Warum hat Encrypter überhaupt Methoden für beide Richtungen? Man benötigt doch an einer Code-Stelle so gut wie immer nur eine der beiden Richtungen. Die Schnittstelle ist also unnötig groß.
Und lass mich raten: Die beiden Methoden sind bei Caesar fast identisch. An einer Stelle steht so etwas wie 26-n wo in der anderen Methode nur n steht.

Wie das mit Schnittstellen in C++ aussieht weiß ich nicht. Aber in Java brauchst du Schnittstellen z.B. wenn dir egal ist was für ein Objekt du bekommst, solange es etwas Bestimmtes kann. Entsprechend beschreibt eine Schnittstelle nicht welche Methoden eine implementierende Klasse braucht, sondern welche Methoden von der empfangenden Klasse benötigt werden.
Braucht eine empfangende Klasse also sowohl encryption als auch decryption, muss die Schnittstelle beide vorweisen. Gut wäre also vllt wenn CryptBase von zwei Schnittstellen (encryption und decryption) „erbt“.

TyRoXx

Xin schrieb:

TyRoXx schrieb:

Xin schrieb:

Das ist eher imperative Herangehensweise, aber OOP ist auch nur ein imperatives Design-Pattern. Wenn man OOP die Magic nimmt, wird es leichter begreifbar.

!?
Erstaunlich... dass das mal einer gut findet. ^^

In der Regel bekomme ich von den "Experten" dafür einen auf den Deckel, weil OOP ja nicht mit Funktionen arbeitet sondern mit "Messages" und das ganze ja abstrahiert (eben so, dass es keiner kapiert) und man das deswegen auch nich so konkret beschreiben darf.

Ich muss meine Zustimmung leider ein wenig einschränken: Laut Wikipedia sind funktionale Sprachen "immer" (?) deklarativ und nicht imperativ. OOP findet man auch in deklarativen Sprachen. Das Lambda-Kalkül zum Beispiel ist pure OOP und das ohne Vererbung :).

In C ist OOP aber ein Entwurfsmuster. So kann man dann auch die übliche Umsetzung von Methoden und virtual im C++-Compiler illustrieren.

Xin

Theoretisches Glaubensbekenntnis ohne Wert für den Fragestellenden

TyRoXx schrieb:

Ich muss meine Zustimmung leider ein wenig einschränken: Laut Wikipedia sind funktionale Sprachen "immer" (?) deklarativ und nicht imperativ. OOP findet man auch in deklarativen Sprachen. Das Lambda-Kalkül zum Beispiel ist pure OOP und das ohne Vererbung :).

Ich glaube, hier muss man sich zum einen Fragen, was eigentlich ein Objekt ist und was Objektorientiert ist, ist gerne auch eine Glaubensfrage.

Dass funktionale Sprachen immer nicht imperativ sind, halte ich für ein Gerücht. Dass das switch()/if-Konstrukt nicht vom Entwickler geschrieben wird, bedeutet nicht, dass es nicht da ist. In FP nutzt man mehr Rekursion und entsprechend sind FPLs optimiert einen Rekursionsanker oder andere Besonderheiten zu formulieren.

Das ist auch nicht gerade die Variante von OOP, die man in C++, Java oder C# als OOP bezeichnet würde. Es ist die alte Variante, wie man in C vereinfacht OOP abbildet - was heute mit C++ für OOP eher verpönt wird: Man möge doch bitte ableiten, statt die richtige Funktion an einem anderen Status des Objektes als des Datentyps zu wählen.

Man kann in C genauso gut funktional programmieren. Man tut es teilweise auch. Man nennt es hier lediglich nicht so. Und man ist nicht darauf beschränkt, was bedeutet, dass man mit den Garantien zurückhaltender sein muss.

**Das alles ist aber nicht das Problem des Threadstarters, der das Verständnis von OOP in Java erweitern soll.
**

TyRoXx schrieb:

In C ist OOP aber ein Entwurfsmuster. So kann man dann auch die übliche Umsetzung von Methoden und virtual im C++-Compiler illustrieren.

Und Java und C++ sind keine imperative Programmiersprachen, die Unterstützung für rekursive Algorithmen bieten, sondern imperative Sprachen, die Unterstützung für das Datentyp-Orientierte Programmierung anbietet. Ich vermeide das Wort "Objektorientiert" hier mal, weil sich OOP eigentlich nicht um das Objekt kümmert, sondern nur um den Datentyp des Objektes. Bei echter OOP müsste man in meinem Verständnis die vtable pro Objekt manipulieren können.
Aber das würde nun wirklich einen Glaubenskrieg beschwören. Wichtig ist nur, was Java kann und was die Leute verstehen sollten.

Sqwan

Wiki schrieb:

Die Grundidee besteht darin, die Architektur einer Software an den Grundstrukturen desjenigen Bereichs der Wirklichkeit auszurichten, der die gegebene Anwendung betrifft.

Ich weiß nicht was man dem hinzufügen soll. Wieso hat das was mit "imperativ" zu tun? Das passiert bei Java / C# sofern es eine "Wirklichkeit" gibt. Die einzelnen Objekte komunizieren mit einander und die Eigenschaften / Aktionen (methoden) werden intern "imperative" gestaltet. Ich verstehe den Konflikt nicht.
Wenn ich wirklich auf dem Schlauch stehe kann mir das vllt jemand erklären?

Xin

Zur Information: Sqwan zitiert Wikipedia zum Begriff "Objektorientierte Programmierung".

Sqwan schrieb:

Wiki schrieb:

Die Grundidee besteht darin, die Architektur einer Software an den Grundstrukturen desjenigen Bereichs der Wirklichkeit auszurichten, der die gegebene Anwendung betrifft.

Ich weiß nicht was man dem hinzufügen soll. Wieso hat das was mit "imperativ" zu tun? Das passiert bei Java / C# sofern es eine "Wirklichkeit" gibt. Die einzelnen Objekte komunizieren mit einander und die Eigenschaften / Aktionen (methoden) werden intern "imperative" gestaltet. Ich verstehe den Konflikt nicht.
Wenn ich wirklich auf dem Schlauch stehe kann mir das vllt jemand erklären?

Dem gibt es nichts hinzuzufügen. Es gibt auch keinen Konflikt in der Programmierung.
Der Punkt ist nämlich, dass das Zitat der imperativen Programmierung auch nichts hinzufügt. Das ist wiederum eine Glaubensfrage und ich gehöre halt dem Glauben an, dass sich nichts an der Wirklichkeit ändert, egal ob man this->method( 1, 2, 3 ) schreibt oder function( this, 1, 2, 3 ).
Wichtig ist nur, ob function sich abhängig von this verhält - wie das implementiert wird oder wir man das im Quelltext formuliert, spielt für die Wirklichkeit keine Rolle.
Genau deswegen wurde der imperativen Programmierung auch nichts hinzugefügt.
Manche glauben aber, dass auto.oeffneTuer() intuitiver wäre als oeffneTuer(auto);

TyRoXx

Xin schrieb:

Dass funktionale Sprachen immer nicht imperativ sind, halte ich für ein Gerücht. Dass das switch()/if-Konstrukt nicht vom Entwickler geschrieben wird, bedeutet nicht, dass es nicht da ist. In FP nutzt man mehr Rekursion und entsprechend sind FPLs optimiert einen Rekursionsanker oder andere Besonderheiten zu formulieren.

Ich halte die Unterscheidung zwischen imperativ und deklarativ für ungeschickt. Das war vielleicht vor 40 Jahren mal praktisch. Da nannte man Sprachen, die Statement für Statement nach Assembly übersetzt wurden, imperativ. Und Sprachen, die so langsam sein konnten, wie sie wollten, Hauptsache schön mathematisch, nannte man deklarativ. Heute ist diese Unterscheidung wenig nützlich, weil sich die meisten Sprachen irgendwo zwischen diesen Extremen bewegen. In modernem C++ beschreibt man zunehmend was man will und weniger wie. In SQL, das angeblich deklarativ ist, achtet man in Wirklichkeit ständig auf das wie, wenn man Anfragen auf Geschwindigkeit optimiert.

Xin schrieb:

Ich vermeide das Wort "Objektorientiert" hier mal, weil sich OOP eigentlich nicht um das Objekt kümmert, sondern nur um den Datentyp des Objektes. Bei echter OOP müsste man in meinem Verständnis die vtable pro Objekt manipulieren können.

In OOP geht es nur um Objekte. Es geht nicht um Klassen und nicht um vtables.
OOP geht schließlich wunderbar ohne Klassen.
Was bei Wikipedia über OOP steht, ist in dem Punkt widersprüchlich:

http://de.wikipedia.org/wiki/Objektorientierte_Programmierung schrieb:

Es enthält Informationen über die auftretenden Objekte und deren Abstraktionen, ihre Typen. Die Umsetzung dieser Denkweise erfordert die Einführung verschiedener Konzepte, insbesondere Klassen, Vererbung, Polymorphie und spätes Binden.

Tatsächlich braucht man keine Klassen, keine Vererbung und keine Polymorphie. Nur spätes Binden braucht man. Genau das kann das Lambda-Kalkül und so ziemlich jede andere sinnvolle Programmiersprache.

Später im Artikel steht dann der Widerspruch:

http://de.wikipedia.org/wiki/Objektorientierte_Programmierung schrieb:

Die ISO-Definition gilt inzwischen im Allgemeinen als zu vereinfachend, da auch klassenlose objektorientierte Sprachen existieren und auch der Vererbung inzwischen weniger Bedeutung beigemessen wird als noch in den 1990ern.

Xin schrieb:

Zur Information: Sqwan zitiert Wikipedia zum Begriff "Objektorientierte Programmierung".

Sqwan schrieb:

Wiki schrieb:

Die Grundidee besteht darin, die Architektur einer Software an den Grundstrukturen desjenigen Bereichs der Wirklichkeit auszurichten, der die gegebene Anwendung betrifft.

Ich weiß nicht was man dem hinzufügen soll. Wieso hat das was mit "imperativ" zu tun? Das passiert bei Java / C# sofern es eine "Wirklichkeit" gibt. Die einzelnen Objekte komunizieren mit einander und die Eigenschaften / Aktionen (methoden) werden intern "imperative" gestaltet. Ich verstehe den Konflikt nicht.
Wenn ich wirklich auf dem Schlauch stehe kann mir das vllt jemand erklären?

Dem gibt es nichts hinzuzufügen. Es gibt auch keinen Konflikt in der Programmierung.
Der Punkt ist nämlich, dass das Zitat der imperativen Programmierung auch nichts hinzufügt. Das ist wiederum eine Glaubensfrage und ich gehöre halt dem Glauben an, dass sich nichts an der Wirklichkeit ändert, egal ob man this->method( 1, 2, 3 ) schreibt oder function( this, 1, 2, 3 ).
Wichtig ist nur, ob function sich abhängig von this verhält - wie das implementiert wird oder wir man das im Quelltext formuliert, spielt für die Wirklichkeit keine Rolle.
Genau deswegen wurde der imperativen Programmierung auch nichts hinzugefügt.
Manche glauben aber, dass auto.oeffneTuer() intuitiver wäre als oeffneTuer(auto);

Der unterschied ist, das auto.oeffneTuer() sich auf dieses eine Objekt bezieht, oeffneTuer(auto) aber nicht - es besteht einfach kein zusammenhang zwischen auto und oeffneTuer, das könnte überall herkommen.

OOP beschreibt immer ein Objekt und dessen eigentschaften/funktionsweisen. Diese sind abgeschlossen und bilden eine Einheit. Die methode des objekts ist fest an das Objekt gebunden. oeffneTuer(Auto auto) ist das nicht. Sie funktioniert für jedes Auto dieses types.

Zugegebener maßen habe ich deine Ansicht von OOP auch noch vorher nicht gehört.

Tatsächlich braucht man keine Klassen, keine Vererbung und keine Polymorphie. Nur spätes Binden braucht man. Genau das kann das Lambda-Kalkül und so ziemlich jede andere sinnvolle Programmiersprache.

Und wo ist dann die Orientierung am Objekt?

TyRoXx schrieb:

Später im Artikel steht dann der Widerspruch:

http://de.wikipedia.org/wiki/Objektorientierte_Programmierung schrieb:

Die ISO-Definition gilt inzwischen im Allgemeinen als zu vereinfachend, da auch klassenlose objektorientierte Sprachen existieren und auch der Vererbung inzwischen weniger Bedeutung beigemessen wird als noch in den 1990ern.

Welche Sprachen werden das? Würde gerne mal rein schauen wie das machen. Irgendwo muss ja auch da die Bindung sein.

hustbaer

TyRoXx schrieb:

EDIT: Ich weiß gerade gar nicht was dein Problem ist. (...)

Mein Problem ist, dass du ein Phrasendrescher bist, der mich (und andere) - auf reichlich grosskotzige Art - mit haltlosem Unsinn "korrigiert".

hustbaer

Sqw4n schrieb:

Welche Sprachen werden das? Würde gerne mal rein schauen wie das machen. Irgendwo muss ja auch da die Bindung sein.

z.B. JavaScript/ECMAScript
Bzw. allgemein alles was hier rein fällt (und nicht zusätzlich noch Klassen hat): http://en.wikipedia.org/wiki/Prototype-based_programming

TyRoXx

Sqw4n schrieb:

TyRoXx schrieb:

Später im Artikel steht dann der Widerspruch:

http://de.wikipedia.org/wiki/Objektorientierte_Programmierung schrieb:

Die ISO-Definition gilt inzwischen im Allgemeinen als zu vereinfachend, da auch klassenlose objektorientierte Sprachen existieren und auch der Vererbung inzwischen weniger Bedeutung beigemessen wird als noch in den 1990ern.

Welche Sprachen werden das? Würde gerne mal rein schauen wie das machen. Irgendwo muss ja auch da die Bindung sein.

So ziemlich jede Sprache, die Closures hat. Beispielsweise in Lua werden Closures nicht aus Klassen erzeugt, können nichts erben und sind nicht polymorph. Sie sind aber Objekte im Sinne von OOP.

local state = "private"
-- Konstruktion eines Objektes
local print_hello = function ()
	-- das Objekt bekommt genau eine Methode
	print("Hello, I am an object!")
	print("And I have " .. state .. " parts.")
end

-- virtueller Methodenaufruf
print_hello()

Hello, I am an object!
And I have private parts.

hustbaer schrieb:

TyRoXx schrieb:

EDIT: Ich weiß gerade gar nicht was dein Problem ist. (...)

Mein Problem ist, dass du ein Phrasendrescher bist, der mich (und andere) - auf reichlich grosskotzige Art - mit haltlosem Unsinn "korrigiert".

Ach, und was machst du?

hustbaer

lol

Xin

TyRoXx schrieb:

hustbaer schrieb:

TyRoXx schrieb:

EDIT: Ich weiß gerade gar nicht was dein Problem ist. (...)

Mein Problem ist, dass du ein Phrasendrescher bist, der mich (und andere) - auf reichlich grosskotzige Art - mit haltlosem Unsinn "korrigiert".

Ach, und was machst du?

Wenn es etwas gibt, was ich in diesem Forum gelernt habe, dann dass es viele Ansichten gibt, die nicht alle richtig sein können. Was ich im Studium gelernt habe, ist dass es für jede beliebige Ansicht, egal wie idiotisch sie ist, auch eine Quelle zu finden ist - notfalls im Informatikduden, da steht alles drin, inkl. dem Gegenteil von dem, was im Informatikduden steht. Belegen kann man alles.

Ich bin häufig anderer Ansicht als die Mehrheit und ich bin durchaus der Auffassung, dass hier viel Halbwissen präsentiert wird - und ich würde auf keinen Fall sagen, dass ich zwangsläufig richtig liege, ich schließe das lediglich mal daraus, dass eben nicht alle Recht haben können. Manche Standpunkte sind aber durchdachter als andere. Ich zähle mich aber durchaus zu den Leuten, die ihren Standpunkt lange abwägen.

Und so sollte man gerade die Standpunkte, die "totaler Blödsinn" sind, durchaus mal als Inspiration auffassen und hoffen, dass das Gegenüber auch einen Grund hatte, zu seiner Überzeugung zu kommen und nur nicht die richtigen Worte fand, das einem selbst günstig zu erklären. Neben der Möglichkeit, dass jemand das Konzept nicht verstanden hat, gibt es auch die Möglichkeit, dass er etwas verstanden hat, was man selbst noch nicht überlegt hat.
Manchmal haben alle intelligente Konzepte, aber keine intelligenten Vokabeln für ihre Ideen.

Ich kann nur sagen, dass in der Informatik viele Vokabeln eher wie Floskeln ("It's raining cats and dogs") benutzt werden und weniger wie Beschreibungen einer Eigenschaft. Interpreter und Compiler zum Beispiel: Jeder Compiler ist zwangsläufig ein Interpreter. Die meisten Interpretersprachen sind Bytecode-Compiler. Zwei nichtsaussagende Begriffe werden benutzt, um 10 Klassen von Programmiersprachen zu bescheiben - über solch schwammige Begriffe tauscht man sich in der Informatik aus. Das kann nicht sinnvoll funktionieren.

"Objektorientierte Programmierung" steht auf dieser Liste schwachsinniger Begriffe ganz weit oben, da sich die OOP in den populären Sprachen wie C++, C#, Java... definitiv einen Scheiß um das Objekt selbst kümmert, sondern lediglich um den Datentyp des Objektes. Es ist "Datentyp-orientierte Programmierung", darum nennen wir es "Objektorientiert"...!?
Ein Tier kann einen gibLaut() geben, aber ein Hund macht immer "Wau!". Zwei Objekte vom Datentyp Hund hingegen müssten einen Member haben, der den Algorithmus zum Bellen beschreibt. Würde man sich um an den einzelnen Objekte orientieren, bräuchte man Funktionpointer statt vtables, damit der eine Hund zur <wortspiel>Laufzeit</wortspiel> "Wau!" und der andere "Wa-Uff!" bellen kann.
Der eine Hund bellt immer, der andere bringt in Abhängigkeit zur Laufstrecke keinen Ton mehr raus.

Das leistet OOP in den "objektorientierten Sprachen" aber gar nicht, weil OOP sich am Datentyp orientiert und für datentyporientierte Programmierung benötigt man nunmal Vererbung der Datentypen.
Das Closure-Beispiel (ich kann kein Closure) erscheint mir ein Funktionpointer darzustellen, orientiert sich also offenbar am Objekt.

Der eine definiert DataHiding als Teil von OOP, ich wüsste nicht, wieso das erforderlich wäre, schließlich kann C OOP, aber kein Datahiding. Aber wenn das einer für wichtig hält... gut. Das dann OOP zu nennen... naja...

Auch funktionale Programmiersprachen benötigen Vererbung. Nur, dass man sie nicht selbst sieht, weil das Interface nicht vom Entwickler vererbt wird, sondern implizit von der Sprache. Es muss eine Methode geben, die eine Liste beispielsweise fragt, ob sie die Eigenschaften erfüllt, um einen entsprechenden Zweig des Algorithmus' auszuführen. Im Closure-Beispiel wäre da die Frage, ob "print_hello()" eine aufrufbare Funktion des Objektes ist und die Aufgabe, eben dieses zu tun. Nur weil der Entwickler diese impliziten Sachen nicht sieht, nicht explizit formuliert, heißt das nicht, dass sie nicht implizit da sind.

Missverständnisse sind also vorprogrammiert, weil viel zu viele Ideen und Konzepte unter einem in der Regel irreführenden Namen zusammengepanscht werden und jeder irgendjemanden finden kann, der das genauso geht und das in den Informatikduden, Wikipedia oder sonstwohin geschrieben hat.

Irgendjemanden zu zitieren bedeutet nicht, dass der Zitierte etwas sinnvolles geschrieben hat.
In diesem Sinne, lasst euch einfach voneinander inspirieren und vermeidet feststehende Begriffe, die jeder nach Belieben auslegt, sondern erklärt euch. Und wenn sich jemand die Mühe macht, sich zu erklären, lest es und sucht nicht nur, was eurer Meinung widerspricht, sondern auch, was eure Erkenntnis erweitert.

Kellerautomat

Nachdem dieser Thread ja ohnehin nichts mehr mit dem Startpost zu tun hat: Koennte sich jemand die Muehe machen, mir zu erklaeren, was diese "echte" OOP ist? Offensichtlich habe ich weder in C++, noch in Java jemals "OOP" programmiert, obwohl ich Klassen eingesetzt habe, da diese Sprachen ja keine OOP "im eigentlichen Sinne" unterstuetzen. Ich wuerde mich daher ueber die Erleuchteung freuen, was nun diese "echte OOP" sein soll, die C++ nicht unterstuetzt. Am besten anhand eines C++-Beispiels erklaert, wo man sieht, was fehlt, damit ich mir nicht erstmal irgendeine andere Sprache ansehen muss, um das zu verstehen.

volkard

Kellerautomat schrieb:

Nachdem dieser Thread ja ohnehin nichts mehr mit dem Startpost zu tun hat: Koennte sich jemand die Muehe machen, mir zu erklaeren, was diese "echte" OOP ist?

Ein Konzept, das stets von belehrenden Laien verbreitet wird, gehört in die esoterische Ecke der Informatik. Ein sehr guter Indikator, daß es gar keinen Zweck hat, sich mit dieser Person weiter fachlich zu unterhalten.

volkard

Xin schrieb:

TyRoXx schrieb:

hustbaer schrieb:

TyRoXx schrieb:

EDIT: Ich weiß gerade gar nicht was dein Problem ist. (...)

Mein Problem ist, dass du ein Phrasendrescher bist, der mich (und andere) - auf reichlich grosskotzige Art - mit haltlosem Unsinn "korrigiert".

Ach, und was machst du?

Wenn es etwas gibt, was ich in diesem Forum gelernt habe, dann dass es viele Ansichten gibt, die nicht alle richtig sein können. Was ich im Studium gelernt habe, ist dass es für jede beliebige Ansicht, egal wie idiotisch sie ist, auch eine Quelle zu finden ist - notfalls im Informatikduden, da steht alles drin, inkl. dem Gegenteil von dem, was im Informatikduden steht. Belegen kann man alles.

Ich bin häufig anderer Ansicht als die Mehrheit und ich bin durchaus der Auffassung, dass hier viel Halbwissen präsentiert wird - und ich würde auf keinen Fall sagen, dass ich zwangsläufig richtig liege, ich schließe das lediglich mal daraus, dass eben nicht alle Recht haben können. Manche Standpunkte sind aber durchdachter als andere. Ich zähle mich aber durchaus zu den Leuten, die ihren Standpunkt lange abwägen.

Und so sollte man gerade die Standpunkte, die "totaler Blödsinn" sind, durchaus mal als Inspiration auffassen und hoffen, dass das Gegenüber auch einen Grund hatte, zu seiner Überzeugung zu kommen und nur nicht die richtigen Worte fand, das einem selbst günstig zu erklären. Neben der Möglichkeit, dass jemand das Konzept nicht verstanden hat, gibt es auch die Möglichkeit, dass er etwas verstanden hat, was man selbst noch nicht überlegt hat.
Manchmal haben alle intelligente Konzepte, aber keine intelligenten Vokabeln für ihre Ideen.

Ich kann nur sagen, dass in der Informatik viele Vokabeln eher wie Floskeln ("It's raining cats and dogs") benutzt werden und weniger wie Beschreibungen einer Eigenschaft. Interpreter und Compiler zum Beispiel: Jeder Compiler ist zwangsläufig ein Interpreter. Die meisten Interpretersprachen sind Bytecode-Compiler. Zwei nichtsaussagende Begriffe werden benutzt, um 10 Klassen von Programmiersprachen zu bescheiben - über solch schwammige Begriffe tauscht man sich in der Informatik aus. Das kann nicht sinnvoll funktionieren.

"Objektorientierte Programmierung" steht auf dieser Liste schwachsinniger Begriffe ganz weit oben, da sich die OOP in den populären Sprachen wie C++, C#, Java... definitiv einen Scheiß um das Objekt selbst kümmert, sondern lediglich um den Datentyp des Objektes. Es ist "Datentyp-orientierte Programmierung", darum nennen wir es "Objektorientiert"...!?
Ein Tier kann einen gibLaut() geben, aber ein Hund macht immer "Wau!". Zwei Objekte vom Datentyp Hund hingegen müssten einen Member haben, der den Algorithmus zum Bellen beschreibt. Würde man sich um an den einzelnen Objekte orientieren, bräuchte man Funktionpointer statt vtables, damit der eine Hund zur <wortspiel>Laufzeit</wortspiel> "Wau!" und der andere "Wa-Uff!" bellen kann.
Der eine Hund bellt immer, der andere bringt in Abhängigkeit zur Laufstrecke keinen Ton mehr raus.

Das leistet OOP in den "objektorientierten Sprachen" aber gar nicht, weil OOP sich am Datentyp orientiert und für datentyporientierte Programmierung benötigt man nunmal Vererbung der Datentypen.
Das Closure-Beispiel (ich kann kein Closure) erscheint mir ein Funktionpointer darzustellen, orientiert sich also offenbar am Objekt.

Der eine definiert DataHiding als Teil von OOP, ich wüsste nicht, wieso das erforderlich wäre, schließlich kann C OOP, aber kein Datahiding. Aber wenn das einer für wichtig hält... gut. Das dann OOP zu nennen... naja...

Auch funktionale Programmiersprachen benötigen Vererbung. Nur, dass man sie nicht selbst sieht, weil das Interface nicht vom Entwickler vererbt wird, sondern implizit von der Sprache. Es muss eine Methode geben, die eine Liste beispielsweise fragt, ob sie die Eigenschaften erfüllt, um einen entsprechenden Zweig des Algorithmus' auszuführen. Im Closure-Beispiel wäre da die Frage, ob "print_hello()" eine aufrufbare Funktion des Objektes ist und die Aufgabe, eben dieses zu tun. Nur weil der Entwickler diese impliziten Sachen nicht sieht, nicht explizit formuliert, heißt das nicht, dass sie nicht implizit da sind.

Missverständnisse sind also vorprogrammiert, weil viel zu viele Ideen und Konzepte unter einem in der Regel irreführenden Namen zusammengepanscht werden und jeder irgendjemanden finden kann, der das genauso geht und das in den Informatikduden, Wikipedia oder sonstwohin geschrieben hat.

Irgendjemanden zu zitieren bedeutet nicht, dass der Zitierte etwas sinnvolles geschrieben hat.
In diesem Sinne, lasst euch einfach voneinander inspirieren und vermeidet feststehende Begriffe, die jeder nach Belieben auslegt, sondern erklärt euch. Und wenn sich jemand die Mühe macht, sich zu erklären, lest es und sucht nicht nur, was eurer Meinung widerspricht, sondern auch, was eure Erkenntnis erweitert.

Darfst nicht "objektorientiertes Programmieren" (gibt es) und "objektorientierte Sprache" (gibt es nicht) vermischen und daraus eine Definition von "objektorientiert" zusammenmixen.

TyRoXx

Xin schrieb:

Missverständnisse sind also vorprogrammiert, weil viel zu viele Ideen und Konzepte unter einem in der Regel irreführenden Namen zusammengepanscht werden und jeder irgendjemanden finden kann, der das genauso geht und das in den Informatikduden, Wikipedia oder sonstwohin geschrieben hat.

OOP an sich ist ein einfaches Konzept.
OOP als Buzzword ist sehr unübersichtlich und widersprüchlich. OOP war mal der neueste Schrei -> jeder schrieb an seine Sprache OOP dran -> alle Features dieser Sprachen wurden auf einmal als unverzichtbar für OOP beworben.
Java nannte sich "objektorientierte Programmiersprache", weil es ein paar Features hat, die einem bei OOP helfen (vor allem virtuelle Methoden und der Garbage Collector). Man kann mit Java auch wunderbar objektorientiert programmieren. Muss man aber nicht. Andersherum kann man auch ohne "objektorierte Programmiersprache" OOP machen wie in C.

Kellerautomat schrieb:

Nachdem dieser Thread ja ohnehin nichts mehr mit dem Startpost zu tun hat: Koennte sich jemand die Muehe machen, mir zu erklaeren, was diese "echte" OOP ist? Offensichtlich habe ich weder in C++, noch in Java jemals "OOP" programmiert, obwohl ich Klassen eingesetzt habe, da diese Sprachen ja keine OOP "im eigentlichen Sinne" unterstuetzen. Ich wuerde mich daher ueber die Erleuchteung freuen, was nun diese "echte OOP" sein soll, die C++ nicht unterstuetzt. Am besten anhand eines C++-Beispiels erklaert, wo man sieht, was fehlt, damit ich mir nicht erstmal irgendeine andere Sprache ansehen muss, um das zu verstehen.

War ich das, der angeblich geschrieben hat, dass C++ keine OOP unterstützt?

volkard schrieb:

Kellerautomat schrieb:

Nachdem dieser Thread ja ohnehin nichts mehr mit dem Startpost zu tun hat: Koennte sich jemand die Muehe machen, mir zu erklaeren, was diese "echte" OOP ist?

Ein Konzept, das stets von belehrenden Laien verbreitet wird, gehört in die esoterische Ecke der Informatik. Ein sehr guter Indikator, daß es gar keinen Zweck hat, sich mit dieser Person weiter fachlich zu unterhalten.

Anstatt hier rumzuheulen könntest du auch an der Diskussion teilnehmen. Was schreibe ich denn so für furchtbar Falsches?

Xin

Kellerautomat schrieb:

Nachdem dieser Thread ja ohnehin nichts mehr mit dem Startpost zu tun hat: Koennte sich jemand die Muehe machen, mir zu erklaeren, was diese "echte" OOP ist?

Da ist die Frage, wie Du "echte" OOP verstehst.
Ich würde den Begriff "OOP" als Floskel in populären Sprachen verwenden, wenn Du Datentypen klassifizierst (daher das Schlüsselwort 'class') und entsprechend des Datentyps eines Objektes unterschiedliche Algorithmen aufrufst (quasi in dem Moment, wo virtuelle Funktionen auftauchen).

Das kannst Du mit einer C-Funktion notfalls auch mit einem switch() lösen, so dass Du anhand eines Struktur-Members den einen oder anderen Algorithmus durchläufst.

Kellerautomat schrieb:

Offensichtlich habe ich weder in C++, noch in Java jemals "OOP" programmiert, obwohl ich Klassen eingesetzt habe, da diese Sprachen ja keine OOP "im eigentlichen Sinne" unterstuetzen. Ich wuerde mich daher ueber die Erleuchteung freuen, was nun diese "echte OOP" sein soll, die C++ nicht unterstuetzt. Am besten anhand eines C++-Beispiels erklaert, wo man sieht, was fehlt, damit ich mir nicht erstmal irgendeine andere Sprache ansehen muss, um das zu verstehen.

Was mich angeht, konzentriere Dich auf den Begriff: OBJEKT-ORIENTIERT.

Das kann man in zwei weisen verstehen: Die Perspektive des Entwicklers auf das Datenobjekt zu verlegen, dann reicht es für viele seine Funktionen in eine Klasse zu betten. Dann hast Du immernoch normale sturkturierte Programmierung, aber es steht halt "class" drumrum. Das verstehen manche Leute auch als OOP. Das kann man als Erklärung akzeptieren, aber das macht jeder brauchbare C-Programmierer auch. Von daher gibt es keinen Unterschied zwischen Fortran und Java. Die Erklärung führt also zu keinem Mehrwert, der ein so langes Buzzwort wert wäre.

Ich begreife das umgangssprachlich genannte "Objekt-Orientiert" als den Wunsch das Feature, den Mehrwert, den C++ zu C besser unterstützt zu nutzen. Weswegen man Sprachen wie C# und Java als "Objektorientiert" bezeichnet.
Das sind virtuelle Funktionen, die anhand des [Datentyps des] Objektes ausgewählt werden. Man orientiert sich am Datentyp(!) des Objektes, weswegen ich hier bevorzugt von "Datentyp-orientierter" Programmierung spreche - die man - übrigens vermeiden sollte, wann immer es geht, die aber eben eine sehr gute Standard-Lösung ist, um Designprobleme zu lösen, das reicht bereits, um sehr viele Probleme effizient zu lösen. Wenn man so ein Problem überhaupt hat.
Eine Standard-Lösung bezeichne ich als Design-Pattern, nicht als Sprachparadigma und auch da gehen die Meinungen deutlich auseinander, obwohl man dem angeblichen OOP-Sprachparadigma auch keine Generation zuordnen kann, das OOP-Sprachparadigma also auch bei den Befürwortern eines Paradigmas eine Sonderrolle einnimmt, weil es nunmal einfach nicht passt. OOP ist immer auch imperative Programmierung, die ich ebenfalls als Fundament der funktionalen Programmierung einordne. Ob FP nun eine Einschränkung oder Weiterentwicklung von IP ist... je nach Bedarf stimmt beides.

"Echte" Objekt-Orientierung orientiert sich am individuellen Objekt. Klingt logisch, weicht von der landläufigen Überzeugung ab! Die Entscheidung über den verwendeten Algorithmus fällt also nicht anhand des Datentyps für alle Objekte eines Datentyps gleich, sondern individuell für jede einzelne Objektinstanz. Vererbung (von virtuellen Funktionen/Interfaces) ist hierbei hilfreich/notwendig, damit man weiß, was man ein Objekt überhaupt fragen darf. Statt virtueller Funktionen, die in einer vtable gesammelt werden und nicht individuell anpassbar sind, müsste man in C++ individuell modifizierbare Funktionspointer erben.
Das braucht man aber extrem selten. Von daher gehe ich tatsächlich davon aus, dass Du nie im Leben OOP programmiert hast.

Datentyporientierte Programmierung unterstützt C++, in dem es virtuelle Methoden zur Verfügung stellt, die das automatische Anlegen der vtables unterstützt. In C ist das nervige Handarbeit.
Funktionspointer hingegen haben eine unschöne Syntax, ob das als "Unterstützung" im Sinne von Hilfe für den Entwickler verstanden werden kann, würde ich nicht unterschreiben. Aber als "Unterstützung" im Sinne von 'Man kann es formulieren, wenn man Funktionspointer formulieren kann'. Man kann in C auch vtables formulieren, aber C unterstützt einen eben nicht dabei.

Wenn man auf OOP und typ-orientierter Programmierung verzichten kann, dann sollte man das auch tun, denn die Indirektion kostet Zeit. Dabei ist TOP speichersparender (eine VTable pro Typ), aber langsamer (zweifach indirekt) als OOP (eine eingebettete VTable pro Instanz), aber schneller (einfach indirekt).
Der Hype um TOP aka "OOP" ist sicherlich berechtigt, aber man sollte Typ-Orientierte-Programmierung (aka OOP) nicht per default verwenden (wie in Java), sondern nur bei echtem Bedarf (wie in C++), bzw. in Java per "final" abschalten.

volkard schrieb:

Darfst nicht "objektorientiertes Programmieren" (gibt es) und "objektorientierte Sprache" (gibt es nicht) vermischen und daraus eine Definition von "objektorientiert" zusammenmixen.

Warum sollte es keine objektorientierten Sprachen geben? Nur C++, Java und C# sind in meinen Augen keine, da dies sinnvollerweise auch überhaupt nicht die Zielrichtung der Sprachen darstellt. Hier geht es darum - zumindet bei C++ - möglichst effizient zu arbeiten und das bedeutet, dass man Indirektionen vermeidet.

Wenn Du bei Python aber Funktionen objektorientiert (also individuell für ein Objekt) zur Laufzeit hinzufügen und überschreiben kannst, dann würde ich Python als objektorientierte Sprache bezeichnen. Leider aber eben nicht annähernd so effizient wie C#, Java oder eben C++.

TyRoXx schrieb:

OOP an sich ist ein einfaches Konzept.
OOP als Buzzword ist sehr unübersichtlich und widersprüchlich. ...
Java nannte sich "objektorientierte Programmiersprache", weil es ein paar Features hat, die einem bei OOP helfen (vor allem virtuelle Methoden und der Garbage Collector).

Dass der Garbage Collector jetzt zu OOP gehört höre ich jetzt tatsächlich zum ersten Mal.
Warum gehört GC jetzt Deiner Meinung nach zu OOP?

-----------

PS: Vielleicht sollte man bei allen Sprachen mal überall "-unterstützend" ranschreiben. C++ ist eine Typ-orientierte-Programmierung-unterstützende Sprache. Auch in C++ kann man beliebige Funktionen zu einem Objekt hinzufügen, man muss nur von einem Dictionary mit Funktionspointern ableiten. Aber C++ unterstützt das eben nicht. Man kann also immer sehr viel mit Sprachen machen, aber bei manchen Sprachen passiert halt vieles implizit, was den Entwickler unterstützt, bei anderen nicht.

Kellerautomat

TyRoXx schrieb:

Kellerautomat schrieb:

Nachdem dieser Thread ja ohnehin nichts mehr mit dem Startpost zu tun hat: Koennte sich jemand die Muehe machen, mir zu erklaeren, was diese "echte" OOP ist? Offensichtlich habe ich weder in C++, noch in Java jemals "OOP" programmiert, obwohl ich Klassen eingesetzt habe, da diese Sprachen ja keine OOP "im eigentlichen Sinne" unterstuetzen. Ich wuerde mich daher ueber die Erleuchteung freuen, was nun diese "echte OOP" sein soll, die C++ nicht unterstuetzt. Am besten anhand eines C++-Beispiels erklaert, wo man sieht, was fehlt, damit ich mir nicht erstmal irgendeine andere Sprache ansehen muss, um das zu verstehen.

War ich das, der angeblich geschrieben hat, dass C++ keine OOP unterstützt?

Auch wenn Xin mich dazu bewegt hat, nachzufragen, spreche ich hier niemanden direkt an. Ich werfe die Frage viel mehr in den Raum, da ich das schon oefters von mehreren Seiten gehoert habe.

Vererbung &amp; Polymorphie anhand von Beispiel erklären

Vererbung & Polymorphie anhand von Beispiel erklären