Vererbung & Polymorphie anhand von Beispiel erklären

[volkard]

TyRoXx schrieb:

EDIT: Ich weiß gerade gar nicht was dein Problem ist. Man muss bei meinem Ansatz ja nicht den ByteGenerator benutzen, wenn es schnell sein soll.

Ich wollte nur zeigen, dass es nicht nötig ist zwei Schnittstellen zu einer zu verschmelzen. Und wenn man die Schnittstellen nicht unnötig groß macht, braucht man auf einmal keine Default-Implementierung für irgendwas mehr.

Das Verschmelzen zweier Schnittstellen ist die von mir gemeinte Premature Optimization. Nicht das Lesen in Arrays.

Ergibt das überhaupt Sinn, wenn Du (wie Du selber sagst) Vererbung nirgends sinnvoll anwenden kannst, über Schittstellendesign zu referieren?

[KennerDesJava8]

Kennt ihr eigentlich schon Java 8?
http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html

[hustbaer]

KennerDesJava8 schrieb:

Kennt ihr eigentlich schon Java 8?
http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html

Nö, kannte ich nicht!
Cool, danke!

[TyRoXx]

volkard schrieb:

Ergibt das überhaupt Sinn, wenn Du (wie Du selber sagst) Vererbung nirgends sinnvoll anwenden kannst, über Schittstellendesign zu referieren?

Entschuldige bitte meine Undeutlichkeit. Ich möchte nur von Implementierungsvererbung abraten. Schnittstellenvererbung hingegen ist sehr wichtig.

Für Implementierungsvererbung sehe ich keine sinnvolle Anwendung.
In C++ gibt es da noch reine Implementierungsvererbung, also private Vererbung. Das ist etwas ganz anderes, weil keine öffentliche Methode überschrieben wird, und deswegen in Ordnung.

[Xin]

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. Allerdings bringe ich den Leuten C++ praktisch bei. Das heißt, die programmieren das anschließend. Das ist mit 45 Minuten etwas zu knapp.

Die Tierwelt finde ich für kleine Beispiele gut, nutze das Beispiel auch. Wenn viel Zeit ist, es also um ein Test-Projekt geht, halte ich die Shapes am besten, wenn Zeit genug ist, diese auch zu zeichnen.

Ansonsten gefällt mir das beispiel im GoF-Entwicklungsmuster, wo ein Editor besprochen wird, der Zeilen aus einzelnen Zeichen zusammensetzt, die Grafiken oder Zeichen sein können, die ihre Größe auf dem Bildschirm zurückliefern und sich zeichnen lassen können.

Kannst Du aber alles vergessen: In 45 Minuten würde ich schätzen, dass Du vielleicht 5 das verständlich machen kannst und die vergessen es bis zum Abend wieder. Von daher ist es relativ egal, was Du erzählst, die Zeit reicht nicht, um etwas sinnvoll zu vermitteln.

cloidnerux schrieb:

Vererbung und Polymorphie wurden innerhalb von zwei Vorlesungsstunden (2 Mal 45 Minuten) eingeführt. Sie sollte also schon einmal davon gehört aber wohl kaum richtig verstanden haben, da es sehr schnell ging (und jetzt muss ich das innerhalb von 45 Minuten richten ).

Ich habe die Erfahrung gemacht, dass man bei Studenten im 3. Semester quasi bei 0 anfängt, obwohl die schon 2 Semester Vorlesungen hatten. Gerade bei Java sind die Vorstellungen teils sehr... virtuell.
Ich erkläre Vererbung und Polymorphie daher an der tatsächlichen Umsetzung: Ich erkläre eine Struktur, dass die Daten bei Vererbung hintereinander geschrieben werden, dass eine Methode auch nur eine Funktion mit this-Pointer ist und dass man über Funktionzeiger, bzw. die vtable an die Funktionszeiger kommt.
Das ist eher imperative Herangehensweise, aber OOP ist auch nur ein imperatives Design-Pattern. Wenn man OOP die Magic nimmt, wird es leichter begreifbar.

Das klappt eigentlich sehr gut, jedenfalls schließe ich das aus Aussagen wie "Jetzt habe ich verstanden, was ich die letzten zwei Semester eigentlich getan habe".

Unter Berücksichtigung, dass sie das eigentlich ja schonmal gehört haben, würde ich schätzen, dass Du hier den Leuten am ehesten etwas Nützliches mitgeben kannst, weil sie eigentlich Bekanntes aufgreifen müssen und zusätzliche Informationen erhalten.

Benutze eine Tafel, keine Präsentation, stelle richtungsführende Fragen und lass die Studenten das entwickeln. Wenn Du denen nur was von Rechtecken erzählst, musst Du die Hälfte danach wecken. Setz Dir sinnvolle Ziele für 45 Minuten Show und akzeptiere, dass Du in 45 Minuten mit einem kleinen Schritt weiter kommst, als wenn Du einen großen Versuchst und nur Verwirrung stiftest.

[TyRoXx]

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.

Xin schrieb:

Ich erkläre Vererbung und Polymorphie daher an der tatsächlichen Umsetzung: Ich erkläre eine Struktur, dass die Daten bei Vererbung hintereinander geschrieben werden, dass eine Methode auch nur eine Funktion mit this-Pointer ist und dass man über Funktionzeiger, bzw. die vtable an die Funktionszeiger kommt.
Das ist eher imperative Herangehensweise, aber OOP ist auch nur ein imperatives Design-Pattern. Wenn man OOP die Magic nimmt, wird es leichter begreifbar.

[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.

[Sqw4n]

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.