Diskussion:Vererbung (Programmierung)/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Vererbung (Programmierung)/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Vererbung_(Programmierung)/Archiv/1#Thema_1

Unterschied zwischen „Objekt“ und „Klasse“

Bitte darauf achten, dass ein Objekt nie "vererben" kann. Das können nur Klassen. Ich habe die Begrifflichkeiten von "Objekt" in "Klasse" geändert. Bitte anpassen, wenn noch etwas ist. e86 23:47, 30. Apr 2006 (CEST)

Unterschied zwischen „Schnittstellenvererbung“ und „Klassenvererbung“

Es ist zweckmäßig, die Begriffe Schnittstellenvererbung und Klassenvererbung zu unterscheiden. Siehe dazu z.B. http://wwwcs.uni-paderborn.de/cs/ag-schaefer/Lehre/PG/SHUTTLE/seminar/ausarbeitungen/Entwurfsmuster_Ausarbeitung.pdf#search=%22klassenvererbung%20schnittstellenvererbung%22 oder http://www.fh-wedel.de/~si/seminare/ws97/Ausarbeitung/2.Winter/gamma12.htm ; erste Einführung vorgenommen, wenn auch noch unvollkommen --Dr.Inform 22:16, 23. Sep 2006 (CEST)

Mehrfachvererbung

Ich finde den Begriff Mehrfachvererbung unpassend. Besser wäre mehrfaches Erben, da es ja darum geht, dass eine Klasse von mehreren etwas erben kann, nicht darum dass eine Klasse mehrfach etwas vererbt.

--Gar kein name 16:31, 11. Feb. 2007 (CET)

Ja, aus sprachwissenschaftlicher Sicht hast du recht. Aber der Begriff "Mehrfachvererbung" ist nunmal der gängige deutsche Fachbegriff für das, was im Englischen "multiple inheritance" genannt wird. Auch wenn die Begriffswahl an sich vielleicht falsch ist, so habe ich bisher nicht erlebt, dass er auch falsch aufgefasst wird.

Es ist halt schwer, für einen englischen Fachausdruck eine griffige, einprägsame und korrekte deutsche Übersetzung zu finden. Beispiele sind etwa die "Virtuelle Speicherverwaltung" (virtual memory management), die ja selbst auch nicht virtuell ist, sondern virtuellen Speicher verwaltet, oder die berühmten "Fließkommazahlen", die auch nicht totzukriegen sind, obwohl "float" ja eigentlich "gleiten" heißt und "Gleitkommazahl" die korrekte Übersetzung ist ("fließen" heißt ja bekanntlich "flow" im Englischen). :-(

Du kannst ja gerne einen besseren Begriff vorschlagen, oder halt dazuschreiben, dass der Begriff "Mehrfachvererbung" falsch ist. "Mehrfacherbschaft" müsste es vielleicht korrekterweise heißen. Dummerweise ist Wikipedia aber ein Lexikon, das vorhandenes Wissen zusammenträgt und darstellt und erläutert, es scholl keine Begriffsbildung betreiben, auch wenn das manchmal vielleicht wünschenswert wäre. --RokerHRO 19:00, 4. Mär. 2007 (CET)

Wie kann ein unpassender Begriff ein gängiger Fachbegriff sein? Ich würde ihn eher als gängige Fehlübersetzung bezeichnen. Einen passenden Begriff habe ich vorgeschlagen. Die Vorgehensweise, einen unpassenden Begriff als Abschnittsüberschrift zu benutzen und dann zu erklären, dass der Begriff eigentlich nüschte taucht, halte ich nicht für sinnvoll. Vielmehr sollte eine vernünftige Überschrift gewählt werden und diese dann durch den Zusatz ergänzt, dass viele Leute einen anderen Begriff verwenden.

--Gar kein name 20:16, 20. Dez. 2007 (CET)

Den Angehörigen eines Fachs ist es oftmals relativ egal, was ein Fachbegriff von der eigentlichen od. ursprünglichen Wortbedeutung meint, sofern jedem in der Fachwelt klar ist, was gemeint ist. So können eben auch unpassende (z.B. "Fließkommazahl"), falschgeschriebene (z.B. Referer statt Referrer) oder sogar vorher völlig sinnfreie Wörter (z.B. Quark) zum Fachbegriff mit einer definierte und anerkannten Bedeutung werden.

Du kannst in deinen eigenen Publikationen gerne eigene, von dir kreierte und möglicherweise treffendere Begriffe oder Übersetzungen für "multiple inheritance" verwenden. In der Wikipedia haben diese Begriffe aber nichts zu suchen, da wir hier etablierte Begriffe und Definitionen verwenden und vorhandenes und etabliertes Wissen zusammentragen und wiedergeben. Der Versuch, neuere und unter Umständen "bessere" Fachbegriffe einzuführen, wäre Theoriefindung und hat in einer Enzyklopädie nichts verloren.

Allenfalls könnte man einen Hinweis angeben, dass der engl. Begriff "(multiple) inheritance" treffender mit "(mehrfaches) Erben" übersetzt werden kann, da dieser Hinweis IMHO schon die Verständlichkeit des (etablierten Fach-)Begriffes "(Mehrfach)vererbung" verbessert könnte. Das war's aber auch. --RokerHRO 14:35, 21. Dez. 2007 (CET)

Ich verstehe, dass eine fehlende Eigenschaft einer Programmiersprache nicht unbedingt genannt werden sollte, insbesondere wenn diese einfach nur vergessen wurde, und verstehe daher auch das Bestreben eine solche Information zu entfernen (siehe Änderung 16:21, 2. Apr. 2008). Dennoch ist beim Design von Oberon bewusst auf die Möglichkeit der mehrfachen Implementationsvererbung verzeichtet worden, was ich wiederum als sehr erwähnenswert finde. Ich habe dies daher wieder in diesem Sinne eingefügt. Membeth 17:55, 2. Apr. 2008 (CEST)

Beispiel Aquisition

Um das Beispiel konsequent bis zum Ende zu denken müssten die vier Radkappen nicht nur Rot sein, sondern auch vier Radkappen haben, oder? Immerhin sagst du das Auto habe vier Radkappen. (85.181.230.50)

Radkappen haben Radkappen? Obskur. --RokerHRO 12:08, 24. Jul. 2007 (CEST)

RokerHRO hat es schon angerissen: eine Radkappe ist kein Auto (ein Auto enthält normalerweise keine Autos), sondern ist „enthalten“ im Auto; deshalb braucht sie auch keine Radkappen zu haben. Sie hat ihre eigenen Eigenschaften, die für eine Radkappe sinnvoll sind. Es ist möglich, daß die Farbe vom Container Auto geerbt wird; es kann auch sein, daß diese Eigenschaft lokal überschrieben wird, weil die Radkappe verchromt ist. --Tobias 23:09, 8. Sep. 2008 (CEST)

Akquisition (oder Aquisition) entfernt – warum?

Kann mir jemand verraten, warum die Akquisition aus dem Artikel entfernt wurde? Sie ist immerhin ein reales Konzept, das in der Objektdatenbank ZODB realisiert wurde und für diese grundlegend ist. Steht sie jetzt irgendwo anders? Es gibt auch noch den Link auf der Begriffsklärungsseite Akquisition, der nun ins Leere (d.h. auf eine nicht mehr existierende Überschrift) zeigt. --Tobias 23:05, 30. Apr. 2009 (CEST)

Ich habe es entfernt, weil es vor allem viel zu speziell ist. Eine spezielle Webanwendung bzw. eine OODB. Weiterhin widerspricht diese "Vererbung" der im Artikel dargelegten und eigentlich scheint es ja primär Akquisition und nicht Vererbung genannt zu werden. Dass ich die ins Leere zeigenden Links nicht angepasst habe, ist natürlich ein Versehen. Warum sollte man das, was bisher hier dokumentiert war, eigentlich nicht unter Zope (Webanwendungsserver)#Akquisition darstellen und dort auf die Unterschiede zur Vererbung in der Programmierung hinweisen? Das wäre doch eine gute Lösung.--Cactus26 10:18, 1. Mai 2009 (CEST)

Abstrakte Klassen

Ich denke im Absatz über abstrakte Klassen wurde da etwas mit Intrfaces stark vermischt. Das sollte noch einmal überarbeitet werden. Eine Abstrakte Klasse kann zumindest in Java sehr wohl Methoden und Attribute implementieren. Im gegensatz dazu kann ein Interface weder Methoden noch Variablen implementieren. Darüberhinaus müssen wenn man ein Interface in eine Klasse implementiert alle Methoden die das Interface bekanntmacht in der Klasse (welche das interface nutzt) implementiert werden (nicht können!).

Das liegt vielleicht daran, dass der Begriff "abstrakte Klasse" in verschiedenen Programmiersprachen unterschiedlich belegt ist. Manche Programmiersprachen, wie z.B. C++, kennen diesen Begriff in der Form gar nicht, aber das Konzept von abstrakten Klassen lässt sich damit dennoch modellieren. Und da die genauer Definition, was jemand unter einer abstrakten Klasse versteht, variiert, variieren dann auch die Beispielimplementierungen. --RokerHRO 11:20, 16. Mär. 2008 (CET)

Eine Klasse kann ein Interface durchaus partiell implementieren, solange ich sie nicht instantiere. D.h., der Artikel hat durchaus recht mit "können" statt "müssen". --Isarhamster 13:27, 24. Mär. 2009 (CET)

Metaklassen

Ein Artikel über Vererbung kann m.E. nicht daran vorbei, sich zu Metaklassen zu äußern. --Isarhamster 13:29, 24. Mär. 2009 (CET)

Da hast Du wohl Recht. Ich bin noch nicht fertig.... Danke für den Hinweis.--Cactus26 13:43, 24. Mär. 2009 (CET)

Nachtrag: Wo genau siehst Du den Bezugspunkt zur Vererbung?--Cactus26 15:23, 24. Mär. 2009 (CET)

Ich denke, die Abgrenzung von Metaklassen ist wichtig, um Vererbung und Instanzbildung in bestimmten Sprachen zu verstehen. In stark objektorientierten Sprachen werden Klassen, deren Instanzen Klassen sind, als Metaklassen bezeichnet. In den Meta-Klassen werden (im Gegensatz zu C++) die Klassenmethoden definiert. Während in diesen Sprachen alle Klassen von "Class" (oder einem Äquivalent) abgeleitet sind, werden Metaklassen von "Metaclass" abgeleitet. Siehe zum Beispiel Ruby und Smalltalk. -- Isarhamster 14:18, 31. Mär. 2009 (CEST)

Das ist mir schon bekannt, allerdings würde ich die Aufgabe, das zu klären, im Artikel Klasse sehen und nicht in Vererbung. Der einzige Stelle, an der ich überlegt habe, ob ich es darstellen soll, war die "Metaclass" bei "Sprachen mit zentraler Basisklasse", ich fand aber, dass dieser Aspekt, wenn er dort kurz erwähnt würde, mehr Fragen aufwirft als beantwortet.--Cactus26 16:36, 31. Mär. 2009 (CEST)

Review Schreibwettbewerb 03/2009

Der Artikel ist noch nicht fertig, aber nun steht zumindest mal eine Version, bei der sich die Durchsicht lohnen könnte. Ich werde den Artikel noch weiter ergänzen, vielleicht auch noch umarrangieren, aber nach jetzigem Stand bleibt zumindest alles was jetzt da ist drin. Würde mich über Feedback freuen.--Cactus26 14:56, 24. Mär. 2009 (CET)

Der Artikel entspricht jetzt aus meiner Sicht weitgehend dem Endzustand. Folgendes habe ich noch vor:

• Grafik zur Veranschaulichung des Problems Person/Kunde/Mitarbeiter(erl.)
• Design by Contract und Exception (im Zusammenhang mit der Vererbung) (vielleicht) (erl.)
• Klassen mit/ohne eine allgemeine Root-Klasse (erl.)
• Weblinks(erl.)
• Trennung Einzelnachweise/Anmerkungen (vielleicht) (erl.)
• Vereinheitlichung Begriffe: "Eigenschaft" als Überbegriff für "Attribut" und "Methode" (erl.)

--Cactus26 17:20, 26. Mär. 2009 (CET) Aktualisiert.--Cactus26 17:25, 28. Mär. 2009 (CET) Aktualisiert.--Cactus26 19:47, 28. Mär. 2009 (CET) Ergänzt.--Cactus26 11:54, 29. Mär. 2009 (CEST) Update.--Cactus26 13:22, 31. Mär. 2009 (CEST) Ende und Aus.--Cactus26 18:34, 31. Mär. 2009 (CEST)

Vererbung: Trennung Einzelnachweise/Anmerkungen, Pro/Cons

• Pro
  • Im Text ist an der Darst. der Fußnote erkennbar, welcher Typ vorliegt (kein unnötiges "nach Hinten blättern")
  • Die Einzelnachweisliste ist eine reine Quellenliste
• Cons
  • Zusätzliche (Zwischen)Überschrift zur Darstellung
  • Mehr Platzbedarf des Fußnotenzeichens bei Anmerkungen
  • Der Leser sieht sich genötigt, die Anmerkungen mitzulesen, damit er nichts verpasst
  • Die Etablierung dieses Stilmittels mag auch zur Verwendung in Artikeln führen, für die man das nicht braucht (für die eine Darstellung des Sachverhalts im Fließtext kein so klarer Nachteil wäre)

Meinungen?--Cactus26 16:53, 29. Mär. 2009 (CEST)

Wenn du die Anmerkungen in den Fließtext aufnimmst bist du auf der sicheren Seite. Anmerkungen als Fußnoten sind bei allen Diskussionen zu Kandidaturen die ich so mitbekommen habe nie gut angekommen. Ich hab mich mittlerweile damit abgefunden, wenn gleich ich diesen den Haupttext erläuerternden Ausführungen eigentlich gut finde. Ich kann, muss sie aber nicht lesen. Je nach Informationsbedarf. Mit weiteren Anmerkungen zu deinem Artikel hapert es momentan deswegen. Gruß --Succu 17:59, 29. Mär. 2009 (CEST)

nach meiner Durchsicht gibt es folgende Anmerkungen:

• 2: hilft nicht weiter, also nicht erforderlich
• 7: unsicher. Verschiebung nach oben oder Kennzeichnng als Anmerkung würde auch nicht schaden
• 15: ??
• 16: paßt besser nach oben, auch wegen (noch rotem) Link
• 20, 27: Details zu einer Sprache in so einem allgemeinem Artikel nicht erforderlich
• 31: ? Anderes Beispiel wählen?

-- 80.146.64.250 11:37, 31. Mär. 2009 (CEST)

Meine Einschätzung deckt sich nur teilweise mit Deiner:

• 2: wichtig, könnte ggf. nach oben
• 7: Ggf. entbehrlich
• 8, 9: Ggf. entbehrlich, aber ungern
• 13: Vielleicht entbehrlich
• 15:Vielleicht entbehrlich
• 16: könnte ggf. nach oben.
• 20: Wichtig, könnte ggf. nach oben.
• 31: Wichtig. Das erste was man von einem Java-Programmierer in diesem Zusammenhang hört: "Es gibt ja die Overwrite-Annotation....". Kann auch fast nicht nach oben.

Die einzige für mich Unlösbare im Moment scheint 31. Aber auch bei vielen anderen fände ich den Umzug bzw. die Streichung nicht gerade toll.--Cactus26 12:07, 31. Mär. 2009 (CEST)

Bei der Wichtigkeit sind wir wohl teilweise unterschiedlicher Ansicht. Nr. 8, 9 und 13 (wenn Sather dort als Ausnahme bezeichnet wird) lasse ich aber als Nachweise gelten. Den Gegnern von Anmerkungen ("Wichtiges gehört in den Text, Unwichtiges ist überflüssig") kann ich mich anschließen, auch wenn ich das nicht verbissen sehe. Auf jeden Fall sollten Anmerkungen als solche gekennzeichnet und nicht unter den Einzelnachweisen versteckt werden. Also solltest Du zuerst entscheiden, was wichtig ist ("Fehlt etwas zum Verständnis, wenn man das streicht?", "Ist das Mehrinformation zum Thema?") und dann überlegen, ob Du das oben einbaust oder als Anmerkung markierst. Bei Nr. 2 verneine ich beides (ein Beispiel dient der Veranschaulichung und berücksichtigt nur Teilaspkte). 80.146.64.250 12:44, 31. Mär. 2009 (CEST)

Ich persönlich liebe Anmerkungen, sowohl in der Rolle als Leser als auch in der Rolle des Autors. Sie bieten halt für jemanden, der sich intensiver damit auseinandersetzen will, einen Bonus ohne dass die anderen Leser beeinträchtigt werden. Natürlich setzt das voraus, dass sie diszipliniert eingesetzt werden. Vielleicht sollte ich zu meiner persönlichen Überzeugung stehen.--Cactus26 13:11, 31. Mär. 2009 (CEST)

Ja, das sollte man, solange man das begründet tut. Aber das betrifft doch wohl nicht das Verstecken von Anmerkungen unter den Belegen, oder?? Man muß sich irgendwann entscheiden und das dann durchziehen. 80.146.64.250 13:32, 31. Mär. 2009 (CEST)

Nein, das Verstecken unter den Einzelnachweise ist natürlich das Gegenteil von dazu stehen. Alea iacta est.--Cactus26 13:51, 31. Mär. 2009 (CEST)

Vererbung: Review 80.146.xx.xx

Ohne alles im Detail gelesen zu haben:

• Einleitung: schon oben genannt, soll ja noch kommen.
• Beispiel: Anfangssatz unglücklich ("könnte"). Besser konkret schreiben, was im folgenden erläutert wird. "Die Anforderung zur u

sichtigung internationaler Vorschriften ... würde ..." schweift für das Beispiel zu weit ab. Für Leser ohne Vorwissen wäre eine Unterscheidung zwischen Klassendefinition und der tatsächlich im Speicher vorhandenen Realisierung sicher hilfreich.

• Anwendungsfälle: Wer entscheidet über korrekte/falsche Verwendung. Ist übertriebene Anwendung falsch? Beim Apfelkuchen bezieht sich der Modellierungsfehler (hier ist es ein Fehler) doch nur auf den Apfel?
• Implementierungsvererbung: Ist das Beispiel gut gewählt? Es entspricht zwar der Beziehung "Quadrat ist ein Rechteck", aber bei abgeleiteten Klassen werden doch meist Eigenschaften ergänzt, was hier nicht der Fall ist. Probleme werden erst weiter unten angesprochen.
• Softwareentwicklung und -wartung: Ist es nicht auch vorteilhaft, daß bei genau beschriebener Klasse und deren Methoden Korrekturen in der Basisklasse oder Anpassungen an ein neues (Betriebs)system automatisch von Subklassen übernommen werden? Solange diese die Methoden konsequent und bestimmungsgemäß nutzen. Dabei ist die genaue Schnittstellenbeschreibung natürlich sehr wichtig. Probleme hierbei hast Du ja schon im letzen Abschnitt genannt.
• Angaben zur Realisierung in ausführbaren Programmen? Z.B. fester/dynamischer Methodenaufruf bei nicht virtuellen/virtuellen Funktionen.
• Anmerkungen und Einzelnachweise trennen? Irgendwo hab ich mal gesehen, wie das geht (Label in ref-Anweisungen).
• Teilweise finde ich den Artikel wegen der Fachbegriffe, die ja auch von Sprache zu Sprache variieren können (z.B. Schnittstelle/abstakte Klasse; Varianz bei den Signaturen überschriebener Methoden), schwierig zu lesen. 80.146.76.237 15:02, 26. Mär. 2009 (CET)

Danke für Dein ausführliches Feedback. Meine Antworten/Anmerkungen/Fragen dazu:

• Einleitung: Habe ich jetzt gekürzt, hat aus meiner Sicht jetzt die endgültige Form.
• Beispiel:
  • könnte den Ausschnitt eines Systemmodells . Besser konkret schreiben, was im folgenden erläutert wird. Nur wie? Das Schienenfahrzeug/Zweiwegfahrzeug ist ja für den Rest so ein bisschen ein Fremdkörper, es soll halt für die Mehrfachvererbung hier rein.
  • Internationale Vorschriften schweift zu weit ab. Finde schon, dass das hier zumindest erwähnt werden muss, da das Beispiel sonst zu trivial erscheinen könnte (warum der ganze Zauber?). Habe aber zumindest den 2. detaillierenden Satz in eine Fußnote genommen.
  • Tatsächliches Speicherabbild: Könnte ich bestenfalls für C++, wäre aber schon für dieses Beispiel unglaublich kompliziert. Würde sicher mehr verwirren als helfen. Für andere Sprachen könnte ich es gar nicht, bei vielen (selbst C++) ist es mW auch gar nicht durch die Sprache definiert sondern implementierungsbahängig.
• Anwendungsfälle:
  • Wer entscheidet über korrekt/falsch: Alle, die meinen Fachleute zu sein. Das ist ja das Problem, aber hier werden nur Dinge aufgeführt, wo Konsens besteht.
  • Übertriebene Anwendung ist falsch (wird das nicht deutlich?)
  • Apfelkuchen, nur der Apfel ist falsch: So ist es, soll ich das deutlicher machen?
• Implementierungvererbung: Beispiel Rechteck/Quadarat wird häufig gewählt, obwohl es problematisch ist. So wie das Beispiel ursprünglich ist, kann man es durchgehen lassen. Aber gerade die Veranschaulichung der Probleme im folgenden macht ja dieses Beispiel so wertvoll.
• Softwareentwicklung und -wartung: Das Beispiel, das Du nennst (Ermöglichung einer zentralen (redundanzfreien) Portierung auf ein neues System) ist sicher einer der Vorteile von OOP. Das erfordert aber ein von vornherein so ausgerichtetes Design. OOP alleine (und schon gar nicht die Vererbung alleine) hat diesen Vorteil nicht, die Vererbung ist nur ein Hilfsmittel, das eine portable Software elegant entwickelt werden kann (eigentlich könnte, in der Praxis macht's so gut wie keiner, solange er nicht muss). Möglich ist, dass die OOP (die Vererbung) hier zu negativ weg kommt. Soll ich noch mehr positives erwähnen?
• Angaben zur Realisierung in ausführbaren Programmen: Metzhodenaufruf virtual/non-virtual sehe ich allerdings nicht hier, sondern eigentlich in einem Artikel Polymorphie. Ich sehe aber schon, dass Du unbedingt was "phyisches" haben willst. Ich werden mal suchen, ob es da irgendwas mit Modellcharakter gibt, was man anbieten könnte.
• Trennung Einzelnachweise/Anermkungen: Habe ich auch irgendwo schon gesehen. Würde Dir das besser gefallen? Ich bin unentschlossen, denke aber drüber nach.
• Bei den Fachbegriffen habe ich versucht, nur in einer Sprache zu bleiben. Vollständig abstrakte Klasse=Schnittstelle ist aber wichtig, wird mW an einigen Stellen klargestellt, dass das einander entspricht.

--Cactus26 17:08, 26. Mär. 2009 (CET)

• Einleitung: In dieser Form deutlich besser. Nur im letzten Absatz ("Da Klassen der Spezifikation von Datentyp und Funktionalität dienen ...") steigt der OMA-Leser sicher aus, da er zum Verständnis erst einige Begriffe nachschlagen muß. Daher würde ich das aus der Einleitung rausnehmen und lediglich auf unterschiedliche Handhabung in unterschiedlichen Sprachen hinweisen. Sicher wäre nach dem Geschichtssatz über Simula auch eine Angabe zur heutigen Bedeutung/Verbreitung informativ (auch wenns vielleicht der von OOP entspricht).
• Vorschlag für Bild in Einleitung: Zur Veranschaulichung, daß geerbte Eigenschaften/Methoden auch Bestandteil der abgeleiteten Klassen sind, könnte in dem Bild die Eigenschaft x und Methode a mit hellerem Hintergrund hinzugefügt werden. Daß diese Darstellung nicht mit UML übereinstimmt, kann dann in der Bildunterschrift erwähnt werden.
• Beispiel: Da Du das noch ändern willst, sehe ich mir den Abschnitt später nochmal an.
  • Internationale Vorschriften: ich hätte eher diesen Hinweis gelöscht (der "würde"-Hinweis ist zum Verständnis des Beispiels nicht erforderlich) und die jetzige Anmerkung oben stehenlassen.
  • Tatsächliches Speicherabbild: so speziell meinte ich das nicht, sondern eine Unterscheidung zwischen Klassendefinition und dem im Speicher vorhandenen Objekt. Tatsächlich wird ja bei jedem Objekt eine eigene Variable Leergewicht gespeichert, auch wenn man sagt, die abgeleitete Klasse erbt diese Eigenschaft von der Basisklasse. Ich weiß nicht, ob das jedem Leser direkt verständlich ist.
• Anwendungsfälle: korrekt/falsch klingt oder ist wertend und daher in einer Enzyklopädie vorsichtig zu gebrauchen. Man kann das auch abmildern ("wird angesehen" statt "sind anzusehen", "meist", "i.a."). Die übertriebene Abstufung wird ja eindeutig als Fehler dargestellt. Das hat mich etwas verwundert, da ich das eher als "schlechten Programmierstil" angesehen hätte, solange das Programm korrekt funktioniert.
• Implementierungvererbung: Wenn das Rechteck/Quadarat ein häufiges Beispiel ist, würde ich wenigstens darauf hinweisen, daß es kein Idealfall für Vererbung ist und mögliche Probleme weiter unten behandelt werden.
• Softwareentwicklung und -wartung: Die Vererbung kommt meiner Meinung nach zu schlecht weg. Auch wenn sie nur ein Hilfsmittel ist, sollten positive Aspekte (auch wenn es nur mittelbare sind) ergänzt werden. Schließlich hat sie doch eine gewisse Bedeutung, die bei dieser Problemliste vielleicht verwundert, oder?
• Angaben zur Realisierung in ausführbaren Programmen: Dieses "Physische" hat mit beim Verständnis von Vererbung/Überschreibung/virtuellen Funktionen geholfen. Allerdings weiß ich nicht, ob das allgemeingültig für alle Sprachen dargestellt werden kann. Und die Polymorphie-Artikel helfen in der jetzigen Form auch nicht weiter.
• Trennung Einzelnachweise/Anmerkungen: Das wäre übersichtlicher. Allerdings sehen einige Wikipedianer Anmerkungen nicht gerne. Und wenn ich mir die 5 Anmerkungen ansehe, können die trivialen gestrichen und die anderen auch oben eingebaut werden.

-- 80.146.51.159 14:30, 27. Mär. 2009 (CET)

Also:

• Einleitung: "Da Klassen der Spezifikation von Datentyp und Funktionalität dienen ...". Das kann man auch OMA nicht ersparen, ich denke, wer hier nicht zumindest eine Ahnung hat, was gemeint sein könnte, hat im restlichen Artikel keine Chance. Schade ist, dass Klasse nicht sonderlich gut erklärt ist (Class scheint mir da besser).
• Einleitung: Satz zur Bedeutung von OOP: Habe ich ergänzt.
• Bild in der Einleitung: Ich bin unentschlossen. Ich habe versucht es mit Pfeilen zu veranschaulichen, das ist aber Mist, da man dann bei den Methoden auf die Idee kommen könnte, die rufen einander auf. Blöd ist halt, dass ich ja in der Einleitung die UML-Notation beschreibe, da gäbe dann ja einen Widerspruch. Reicht die verbale Erläuterung in der Legende nicht doch aus?
• Beispiel:
  • Internationale Vorschriften: ich hätte eher diesen Hinweis gelöscht (der "würde"-Hinweis ist zum Verständnis des Beispiels nicht erforderlich) und die jetzige Anmerkung oben stehenlassen. Ok, umgesetzt
  • Tatsächliches Speicherabbild: Stellst Du Dir so etwas vor: Zur Prüfung, ob eine Fahrerlaubnis gültig ist, wird nach Eingabe der entsprechenden Daten innerhalb des Awendungsprogramms das konkrete zu mietende Fahrzeug instantiiert, das heißt, die entsprechende Spezialisierung, und zudem die vorliegende Fahrererlaubnis. Diese wird dann der Methode PrüfeFahrerlaubnis des konkreten Fahrzeug-Objekts übergeben und die Rückgabe ausgewertet und beispielsweise dem Sachbearbeiter angezeigt.?
• Anwendungsfälle: korrekt/falsch zu "hart": Du hast in jeder Hinsicht recht, wäre auch außerhalb der WP zu hart, habe es angepasst.
• Implementierungvererbung, Bsp. Rechteck/Quadrat: Habe einen Hinw., dass Rechteck/Quadrat nicht in jeder Hinsicht ein ideales Bsp. ist, ergänzt. Schau es Dir bitte an. Sollte es besser in eine Anmerkung (siehe dazu auch unten)
• Softwareentwicklung und -wartung: Die Vererbung kommt zu schlecht weg: Stimmt schon. Für mich ist das halt alles kalter Kaffe und gerade die (neueren) negativen Aspekte spannend. Habe noch was ergänzt. Besser?
• Physischer Abbildung: Ich verstehe Dich voll und ganz. Mir hat mal ein Kollege erzählt, der OO-Schulungen gehalten hat, dass ein Teilnehmer, der Systemprogrammierer für IBM-Host war, steif und fest behauptet hat, dass das OO-Zeug auf einer IBM-Hardware niemals laufen könne. Es wirkt wie Zauberei, dieser Polymorphismus, aber wenn man's mal durchschaut hat, ist es halt doch wieder nur ein solider, sauber strukturierter, "bodenständiger" Mechanismus. Ich denke, übergreifend kann man das nicht darstellen, eher beispielhaft und modellhaft. Ich suche weiter.
• Trennung Einzelnachweise/Anmerkungen: Im Moment tendiere ich dazu, es zu machen. Ich selbst habe bei der Arbeit an einem meiner letzten Artikel sehr unter einer Quelle gelitten, bei der sich unter Fußnoten auch beides verbergen konnte und nach dem Nachintenblättern es oft genau das war, was man sich gerade nicht erhofft hatte.

Ich danke Dir für dieses tolle Review. Wäre schön, wenn Du bist Torschluss dranbleibst.--Cactus26 16:38, 27. Mär. 2009 (CET)

• Bild in der Einleitung: Das kann man auch so verstehen. War nur ein Vorschlag und ist ja mittlerweile weiter unten dargestellt.
• Tatsächliches Speicherabbild: Ich habe vorne noch etwas ergänzt (so ok?) - und dann gesehen, daß Du das unten bereits ausführlicher ausgeführt hast.
• Dann ist mir aufgefallen, daß hier alle Methoden überschrieben werden. Wäre nicht ein gegenteiliges Bespiel und Erläuterung im Text sinnvoll? (z.B. PrüfeFahrerlaubnis() in der Basisklasse mit dem Funktionswert "kann gemietet werden", die in der Klasse Fahrrad nicht überschrieben wird)
• Bsp. Rechteck/Quadrat: ich habe noch einen Hinweis ergänzt, sonst fehlt hier etwas, kannst Du aber noch verbessern.
• Softwareentwicklung und -wartung: Wenn das kalter Kaffee ist und langsam verdrängt wird, kannst Du das auch schreiben. Ansonsten liest sich das schon positiver. Ist es zu speziell, etwas näher auf Klassenbibliotheken mit definierter Schnittstelle einzugehen, oder gehört das eher in andere Bereiche wie Kapselung? Anpassungen der Klassenbibliotheken mit hoffentlich(!) geringer Änderung von Anwendersofware sind doch auch ein Wartungsaspekt.
• Physischer Abbildung: wenn selbst Fachleute hier noch Nachhilfe brauchen, dann ist so ein Abschnitt bitter nötig!! Im Ernst: ich habe mir das vor langer Zeit mal bei einer Sprache näher angesehen und weiß auch nicht, ob man das verallgemeinern und daher für alle Sprachen zusammenfassen kann. Vielleicht reicht ja ein Abschnitt mit dem Hinweis auf Tabelle virtueller Methoden (ist mittlerweile im Artikel), Unterscheidung zu statischen Methoden und Hinweis auf unterschiedliche Speichergrößen (eine Methode der Klasse Fahrzeug kennt nicht den Speicherplatz eines PKW, kann nicht auf AnzahlSitzplätze zugreifen, aber über virtuelle Methoden diese Eigenschaft trotzdem nutzen)

-- 80.146.92.93 16:19, 28. Mär. 2009 (CET)

Also zunächst einmal möchte ich mich für Deine Hartnäckigkeit beim "Physischen" bedanken (meine Betriebsblindheit ist nicht einfach zu besiegen...) Ich habe jetzt was ergänzt und bin recht glücklich damit. Es veranschaulicht halt deutlich, dass die Attribute verschiedener Klassen in einem Objekt friedlich nebeneinander liegen, der Pfeil zur vft bleibt etwas mysteriös, aber im Prinzip kann man erahnen, wie's geht. Folgende Einzelheiten:

• Beispiel, explizite Auflistung der Attr. in Klasse Kraftfahrzeug: Ja, ist jetzt ein wenig doppelt mit der Abb. unten. Bind unschlüssig, korrekt ist es natürlich schon, wie Du das ergänzt hast. Vielleicht kein Fehler, das so früh explizit darzustellen, da die UML-Bilder ja immer etwas anderes suggerieren.
• Alle Methoden werden überschrieben. Stimmt schon. Zudem drücke ich mich vor einer genauen Erläuterung, wie denn eigentlich die bereits in Kraftfehrzeug implementierte allgemeine Funktionalität überhaupt genutzt wird. Aber das ist zu kompliziert, glaube ich. Die Funktion PruefeFahrerlaubnis nach Fahrzeug hochzuziehen und dort in der Standardimpl. immer true zurückzuliefern (was dann für Fahrrad anwendbar wäre) halt ich für keine gute Idee. Finde den Erklärungsbedarf riesig. Finde es besser, dass es diese Methode beim Fahrrad nicht gibt, weil eben nicht relevant. Man könnte eine weitere Funktion wie "Reserviere" einführen, die allgemein implementiert wird und die Reservierung in der Datenbank verbucht. Oder umgekehrt: IstVerfügbar. Aber ich bin unentschlossen. Mir wird das fast zu kompliziert.
• Softwareentwicklung und -wartung: kalter Kaffee. Das ist POV. Ich habe halt die Sprüche wie Wartbarkeit, Erweiterbarkeit, ... zu lange gehört (und höre sie heute immer noch bei jeder neuen Mode). Aber nicht falsch verstehen. Ich finde OOP prima, nur ist sie für viele Entwickler nicht geschaffen, weil zu kompliziert.
• statische Methoden (Klassenmethoden): Möchte ich nicht erwähnen, sehe bislang keine Notwenigkeit, warum noch komplizierter machen?
• Zunehmende Speichergröße der Spezialisierungen, Vergleich. Weiß nicht, das klingt dann doch sehr nach C++.
• Indirekte Nutzung von Attr. der Spezialisierungen durch virtuelle Methoden von der Basisklasse aus: Geht mMn zu weit.
• : Hm. Im Grunde sind diese in beiden Unterabschnitten des Wartungs-Abschnitt eigentlich (hauptsächlich) gemeint. Kommt das nicht rüber?

--Cactus26 17:25, 28. Mär. 2009 (CET)

• Physisches: gern geschehen. Zu dem Pfeil könnte man neben dem Datenkasten noch einen Codekasten (Kfz::PrüfeFahrerlaubnis(), Motorrad::PrüfeFahrerlaubnis() usw.) zeichnen, wo der Pfeil dann auf die richtige Methode zeigen kann.
• Beispiel, explizite Auflistung der Attr.: ich habe Deine Änderung erst danach gelesen, fand meine Ergänzung dann an dieser Stelle trotzdem nicht schlecht (da Du ja partout in den Bildchen nichts ergänzen willst!).
• Alle Methoden werden überschrieben: eine weitere Methode würde das Beispiel und die Beschreibung eher unübersichtlich machen. Daß Methoden nicht überschrieben werden müssen (sondern auch geerbt werden können) halte ich in dem Beispiel jedoch für nennenswert. Minimallösung wäre ein Satz wie "Wenn eine Methode in einer abgeleiteten Klasse nicht überschrieben wird, wird die entsprechende Methode der Basisklasse verwendet, so daß Methoden nur überschrieben werden müssen, wenn die gegenüber der Basisklasse ergänzt oder verändert werden müssen."
• vorgeschlagene Erweiterungen: ist ja jetzt im Beispiel ("Physisches") im Ansatz enthalten
• Klassenbibliotheken mit definierter Schnittstelle: ist schon klar, daß es in den beiden Abschnitten darum geht, aber mehr unter dem negativen Aspekt.
• Der Verweis auf den nicht existierenden Hauptartikel: Fragile Base Class Problem stört mehr als daß er hilft.

-- 80.146.124.97 19:12, 28. Mär. 2009 (CET)

Aus meiner Sicht noch offen:

• Physisches, explizitere Darstellung der vft: Ich glaube nicht, dass das Beispiel hier geeignet ist, das zu verdeutlichen, finde auch, dass dies der Artikel Tabelle virtueller Funktionen einfach zu leisten hat.
• Methodenbeispiel, das nicht überschrieben werden muss. Bin unentschlossen. Was hältst Du von folgendem:
  • Methode PruefeVerfuegbarkeit und Eigenschaft Typkennung zusätzlich in der Basisklassse
  • Zusätzlicher Text als 2. Absatz: In der Klasse Fahrzeug gibt es eine Methode PruefeVerfuegbarkeit, die über die Typkennung des Fahrzeugs, beispielsweise durch einen Datenbankzugriff, die Verfügbarkeit eines bestimmten Fahrzeugtyps ermittelt. Diese Methode wird von allen Spezialisierungen geerbt und ist somit für diese ebenfalls nutzbar.
• Fehlender Hauptartikel "Fragile Base Class Problem": Ist mir schon klar, dass das lächerlich ist. Ich will die roten Links so gut es geht im April abarbeiten. Den zuerst.
• Wie gefällt Dir eigentlich der neue Abschnitt "Zentrale Wurzel des Klassenbaums"? Bei der Abschnittsüberschrift habe ich ewig überlegt. Hast Du vielleicht eine bessere Idee?
• Begriffe Methode/Attribut/Eigenschaft: Ich tendiere im Moment zu folgendem: "Eigenschaft" als Überbegriff für "Attribut" und "Methode". Das sauber durchziehen (im Moment nicht der Fall). Kennst Du einen besseren Überbegriff? "Merkmal" gefällt mir nicht, klingt zu sehr nach Attribut.--Cactus26 11:27, 29. Mär. 2009 (CEST)

--Cactus26 11:27, 29. Mär. 2009 (CEST)

• Physisches: die Ergänzung des Bildes würde den Pfeil weniger myteriös erscheinen lassen. Da Details im verlinkten Artikel beschrieben werden, wäre keine Erläuterung oder nur eine kleine Anpassung des vorhandenen Textes nötig.
• Methodenbeispiel, das nicht überschrieben werden muss: An das Beispiel der Verfügbarkeit habe ich auch schon gedacht, allerdings wegen des höheren Aufwandes wieder verworfen. Wenn es Dir besser gefällt, kannst Du es aufnehmen. Statt Typkennung würde ich vielleicht Fahrzeugnummer o.ä. wählen, denn das jeweilige Objekte bezieht sich ja auf das "konkrete zu mietende Fahrzeug" (hier gehört hinter "konkrete" ein Komma oder es muß "konkret" heißen, oder?) oder stattdessen ein Attribut "VerliehenBis".
• Zentrale Wurzel des Klassenbaums: gut verständlich. Titelvariante: "Zentrale Basisklasse von Programmiersprachen". Das würde im Titel hervorheben, daß sie für eine gesamte Sprache gelten. Das Ende könnte konkreter sein, z.B. "dass bei Variablen der Basisklasse/von allgemeinen Klassen eine Typprüfung erst während der Laufzeit anhand der tatsächlichen(?) Daten eines Objekts durchgeführt werden kann". Prinzipiell kann die Typprüfung bei konkreteren Klassen doch vom Compiler geprüft werden, oder?
• Begriffe Methode/Attribut/Eigenschaft: Ich würde Eigenschaften eher mit Attributen vergleichen und nicht als Oberbegriff sehen. Am besten konsequent "Eigenschaft" oder "Attribut" für die Daten benutzen und statt Oberbegriff einfach "Eigenschaften und Methoden".
• Trennung Anmerkungen: mit der Ergänzung <ref group="Anm."> in der ref-Anweisung erscheint im Text auch "Anm. x", so daß der Leser sofort erkennt, daß ihn unten kein Nachweis, sondern eine Anmerkung erwartet.

-- 80.146.69.6 13:31, 29. Mär. 2009 (CEST)

Zwischendurch noch mal ein Danke für Deine vielen Anregungen und für Deine für micht wichtige aufopfernde Bereitschaft, hier Diskussionspartner zu spielen.

• Physisches, Pfeil auf vft: Ich habe die vft jetzt zumindest skizziert, damit der Pfel nicht im Nichts endet. Gefällt Dir das zumindest besser? Mehr will ich nicht, eine Namensnennung würde hier viel Raum (in der Breite des Bilds) einnehmen, der mMn wenig bringt und bewirkt, dass man bei Thumb-Darst. nichts mehr lesen kann.
• Beispiel: Jetzt ergänzt. Danke für den Hinweis "Fahrzeugnummer". Ich war darauf und dran einen Fahrzeugtyp zu instantiieren. Das wäre zwar technisch prinzipiell auch eine denkbare Lsg., würde aber unnötig verwirren, wenn eine Instanz einen (Fahrzeug)Typ darstellt (Ebenenwechsel!).
• Zentrale Wurzel des Klassenbaums: Angepasst. Schau es Dir bitte nochmal an.
• Eigenschaft/Methode/Attribute: Bin auf "Attribute" umgestiegen und an den meisten Stellen habe ich "Attr. und Methoden" verw., wenn ich beides meine, bis auf wenige Ausnahmen. Die finde ich implizit so klar, dass ich ungern sperrig "Attr. und Methoden" schreiben würde. Unter den verbliebenen "Eigenschaften" sind aber auch Fälle, die sich nicht direkt auf "Klassnmember" beziehen, sondern die von der fachlichen (nicht programmtechnischen) Ebene her gemeint sind, auch dort würde ich "Eigenschaft" sehen lassen wollen.
• Trennung Anmerkung/Einzelnachweise: Habe oben mal ein Pro/Cons ergänzt. Vielleicht sagt ja noch einer was dazu.

--Cactus26 16:56, 29. Mär. 2009 (CEST)

Hallo, ich les mir den Artikel morgen vormittag nochmal vollständig durch. Heute muß Du nicht mehr auf Beiträge warten. 80.146.87.114 19:05, 30. Mär. 2009 (CEST)

Endspurt:

• Mit dem Satz "Da Klassen der Spezifikation von Datentyp und Funktionalität dienen, kann bei der Vererbung sowohl der Typ – spezifiziert durch seine Schnittstelle (engl. Interface) – als auch die Implementierung vererbt werden" bin ich immer noch nicht glücklich. Im ersten Teil wird zwischen Datentyp (Attribute) und Funktionalität (Methoden) unterschieden, im zweiten zwischen Schnittstelle (Beschreibung von Daten und Methoden) sowie Implementierung (konkrete Realisierung in einer Sprache). Irgendwie paßt das logisch nicht ganz. Vielleicht: "Klassen dienen der Spezifikation von Datentyp und Funktionalität, die beide vererbt werden können."
• Anmerkungen: s.o.
• Siehe auch habe ich gelöscht und ober verlinkt, Dieser Link war nicht das, was man dort erwarten könnte.

-- 80.146.64.250 11:37, 31. Mär. 2009 (CEST)

So:

• Spezifikation von Datentyp und Funktionalität: Deine Formulierung gefällt mir. Habe sie umgesetzt. Meine urspr. Intention für war die Erwähnung der "Schnittstelle". Habe ich anders umgesetzt, finde, sogar wesentlich besser als bisher. Großer Fortschritt. Danke.
• Anmerkungen (siehe auch oben): Ich bin weithin sehr unentschlossen. Aber die Umwandlung in Anmerkungen ist ja eine formale Sache, die in kurzer Zeit erledigt werden kann und sollte die Schlacht nicht entscheiden, wenn wir es auch im jetzigen Stadium nicht umsetzen. Für die Entscheidung wäre ein breiteres Publikum hilfreich.--Cactus26 12:15, 31. Mär. 2009 (CEST)
• "siehe auch" gelöscht. Klar. Warum bin ich da nicht gleich selbst draufgekommen? Danke.

--Cactus26 12:15, 31. Mär. 2009 (CEST)

Ich möchte mich jetzt abschließend für Deine wieder einmal tolle Mitarbeit bedanken. Eigentlich wäre jetzt schön, zusammen ein Bierchen zu trinken... Es wird dieses mal im Wettbewerb auch der beste Reviewer gekürt, wenn ich das richtig gesehen habe. Aus meiner Sicht ist klar, wer den Preis erhalten sollte. Ich kenne die genauen Kriterien nicht, aber übersehen kann die Jury Deine Beiträge wirklich nicht. Freue mich schon auf unser nächstes gemeinsames Projekt, wenn Du wieder mal unverhofft irgendwo auftauchst. Habe Dir noch was auf meiner Disk. hinterlassen.--Cactus26 18:33, 31. Mär. 2009 (CEST)

Vererbung: Weiteres Feedback/Reviews

Hi! Ganze sechs Einzelnachweise in der Einleitung ist äußerst ungünstig. Da sollten überhaupt keine auftauchen, da dort der Artikelinhalt zusammengefasst wiedergegeben werden sollte. Bitte die Einzelnachweise in den Artikeltext verschieben. --Succu 18:42, 24. Mär. 2009 (CET)

Die Einleitung ist mir zu umfangreich und sollte nicht mehr als zwei kurze Absätze umfassen. Ein paar Ideen zur Verkürzung habe ich: Vielleicht kann man die Darstellung in UML-Klassendiagrammen in einen eigenen Abschnitt verlagern (z. B. „Notation“). Dort könnte man dann auch auf andere Notationen als UML eingehen. Und natürlich wäre dort Platz für ein Diagramm, damit sich der geneigte Leser vorstellen kann, wie ein „Pfeil mit einer dreieckigen Spitze“ aussieht. Die Geschichte der Vererbung (beginnend mit Simula) könnte ebenfalls in einen eigenen Abschnitt namens „Geschichte“. Weitere Teile der Einleitung könnten in die Abschnitte „Varianten der Vererbung von Typ und Implementierung“ und „Mehrfachvererbung“ verschoben werden. --j ?! 20:11, 25. Mär. 2009 (CET)

Danke für Dein Feedback. Die Einleitung kann und wird nicht so bleiben. Ich habe die Erfahrung gemacht, dass es am besten ist, ganz am Ende der Arbeit an einem Artikel sich nochmal um die Einleitung zu kümmern, da man dann den besten Blick für Wichtiges und Unwichtiges hat. Leider bin ich noch immer ein wenig am inhaltlichen ergänzen. Im Moment tendiere ich allerdings dazu, gerade die UML-Sache in der Einleitung zu lassen und ein Bild zur Erläuterung der UML-Notation (wie Du es ja auch siehst) als Artikelbild zu verwenden. Ich werde eher die Schnittstellen-/Implementierungs-Diff. erheblich kürzen. Bei der Geschichte der Vererbung ist das Problem, dass es außer Simula dort nicht wirklich was gibt, was man in einem sep. Abschnitt behandeln könnte (es geht ja nicht um die Gesch. der OOP). Die Sache mit dem ADT und der Zus. zur Vererbung ist für einen Geschichtsabschn. erheblich zu kompliziert. Dann könnte man noch ein wenig Geschichte zur Mehrfachvererbung erzählen, aber auch das ist, wenn überhaupt, leichter im Abschnitt Mehrfachvererbung erklärbar.--Cactus26 05:57, 26. Mär. 2009 (CET)

• Trennung Einzelnachweise/Anmerkungen - wie es geht siehe beispielsweise hier, allerdings ist das Unterbringen von Anmerkungen in Fußnoten soweit ich das kenne ziemlich verpönt. --Succu 18:13, 26. Mär. 2009 (CET)

Danke, Ich tendiere dazu, es zu machen. Der Vorteil ist, dass man im Text Quellen und Anmerkungen unterscheiden kann. Mich ärgert in Literatur auch immer, wenn man das nicht kann und vergeblich hinten nachschaut.--Cactus26 18:45, 26. Mär. 2009 (CET)

Im Gegensatz zu den hier aufgeführten Eindrücken nur eine Kleinigkeit: Im Absatz „Mehrfachvererbung“ ist die Bildunterschrift nicht vollständig (Es soll wohl heißen „Mehrfachvererbung mit UML“). --Toffel 18:25, 26. Mär. 2009 (CET)

Danke. Ich vermute, ich wollte das sagen, was ich jetzt versucht habe, hatte aber keinen Formulierungseinfall und hab's dann vergessen.--Cactus26 18:41, 26. Mär. 2009 (CET)

• Einleitung: der letzte Satz sollte wegfallen da er über das Allgemeine hinausgeht. Die Formulierung in den zwei darvorstehenden Sätzen enthält zweimal "dies". Zweimal "auch" in der Einleitung ist unschön. Die Einzelnachweise gefallen mir immer noch nicht. Kannst du die nicht später unterbringen. Die Einleitung soll ja ein Zusammenfassung des Artikels sein. Somit gibt es nichts zu belegen. --Succu 18:56, 26. Mär. 2009 (CET)

Hab mal eine Verbesserung versucht. Beim letzten Satz verstehe ich Deine Argumentation, tendiere aber im Moment zu behalten, da Java einfach wichtig ist. Die Quellen kann man ggf. weglassen, ich finde sie aber eher hilfreich (der Simula-Sachverhalt taucht allerdings nirgendwo anderes auf, die anderen Dinge auch eher indirekt, nicht in dieser allgemeinen Form).--Cactus26 19:20, 26. Mär. 2009 (CET)

• Beispiel: Eine Autovermietung (siehe wikilink) die auch auch Schienenfahrzeuge im Angebot hat?! Systemmodell - eher Anwendungsgebiet (Problemdömäne etc.). "Die Anforderung zur Berücksichtigung internationaler Vorschriften würde eine solche Implementierung noch erheblich komplizierter machen" - streichen, wozu verkomplizieren? Das Beispiel wirkt auf mich ziemlich konstruiert und passt auch am Artikelanfang nicht. Evtl. erst die Theorie und dann das Beispiel oder die Problematik ohne konkreten Bezug auf die softwaretechnische Umsetzung darstellen. Genau!: Als Einstieg eine allgemeine Problemstellung darstellen, aus der sich der Einsatz von Vererbung "zwanglos" ergibt. Laut denkend --Succu 20:17, 26. Mär. 2009 (CET)

Ich habe wirklich lange darüber nachgedacht, wie man diesen Artikel aufziehen kann und es ja auch mehrfach umgebaut. Eigentlich war ich mit meinem Beispiel ganz glücklich. Ich finde (fand) es erheblich besser (praxisnäher), als das, was man in der Literatur so angeboten bekommt. Deine Idee, das über das Problem aufzuziehen, halte ich für chancenlos (ich habe wirklich lange darüber nachgedacht). Der Grund: Eine Problemstellung, die tats. eine objektorientierte Lösung rechtfertigt (die nicht konstruiert wirkt) ist so kompliziert, dass sie einen viel zu großen Raum einnimmt (und dabei bereitet das Anwendungsproblem selbst bereits Verständnisschwierigkeiten, was für den Leser auf die eigentlich zu vermittelnde Thematik noch oben draufkommt)

Ok, das mit dem Zweiwegefahrzeug ist konstruiert, der Mehrfachvererbung geschuldet. Mein Vorschlag: Ich baue das Zweiwege- und Schienenfahrzeug hier aus und führe stattdessen Fahrrad und LKW ein. Dann habe ich hier keine Mehrfachvererbung (das Fahrrad mit Hilfsmotor erspare ich uns dann doch), führe das Zweiwegefahrzeug halt hinten (bei der Mehrfachvererbung) ein. Was hältst Du davon?

--Cactus26 08:19, 27. Mär. 2009 (CET)

Sorry, ich hab deine Antwort gerade erst entdeckt. Ich habe auch nochmal darüber nachgedacht was mir so an Beispielen aus der Literatur bekannt ist, bin aber auf nix vernünftiges gekommen. Blöde Mehrfachvererbung! Mein Vorschlag passt vermutlich eher in ein Lehrbuch als in ein Enzyklopädie. OK versuchs so, wie oben beschrieben. Die Änderungen von gestern hab ich mir noch nicht angesehen. Ich versuche am Wochenende die restlichen Abschnitte durchzugehen und dir hier soweit erforderlich ein Feedback zu geben. --Succu

Da ich gerade über das javatypische Wort Attribut gestolpert bin: wäre es nicht sinnvoll im Artikel einheitlich die UML-Sprachweise anzuwenden, also Operation für Methode und Attribut für Eigenschaft? --Succu 12:19, 28. Mär. 2009 (CET)

Mit Attribut könnte ich mich anfreunden, mit Operation aber nicht ("Signatur einer Operation" habe ich noch nie gehört). Wenn man das "Signatur einer..." mal als Gradmesser nimmt: Methode > Funktion > Operation.--Cactus26 12:31, 28. Mär. 2009 (CET)

Das liegt wohl daran das Vererbung im Rahmen von UML als allgemeines Konzept verstanden wird (so wie es der Artikel auch darstellt), der Begriff Methode aber aus dem speziellen Verständnis ein Programmiersprache und ihrer Implementierung (wie bei Signatur) kommt.

Zum Abschnitt Anwendungsfälle der Vererbung Unglücklich formuliert sind die Sätze

• Daneben tauchen in der Praxis Fälle auf, die eindeutig nicht als sinnvolle Verwendung der Vererbung anzusehen sind.
• Insbesondere bei bei den ersten Gehversuchen in objektorientierter Programmierung ergibt sich häufig eine aus der Begeisterung resultierende übertriebene Abstufung der Vererbungshierarchie, oft für eine simple zusätzliche Eigenschaft.

Rolle sollte verlinkt sein, zur Not auch rot. --Succu 12:54, 28. Mär. 2009 (CET)

Ich finde die Formulierungen eigentlich gut. Insbesondere gefällt mir, dass ich durch die "ersten gehversuche" den "Anfänger" losgeworden bin. Hättest Du Vorschläge? Wohin würdest du Rolle denn verlinken (wie soll das Lemma heißen)?--Cactus26 17:28, 28. Mär. 2009 (CET)

Die Puzzle-Aufgabe mit der Rolle wollte ich eigentlich auf dich abwälzen, da ich auf die schnelle nix passendes gefunden hatte. Vollständig sollte es wohl Anwenderrolle heißen. Es gäbe Akteur, was zwar aus UML-Sicht korrekt ist, aber aus Analysesicht nicht den Kern trifft (Oder doch, bin mir grad unsicher?).

Gehversuche = beim Erlernen objektorientierter Paradigmen wird häufig der Fehler begangen...

tauchen in der Praxis Fälle auf = Das Prinzip der Vererbung wird oft missverstanden und falsch genutzt. In die Richtung... --Succu 18:56, 28. Mär. 2009 (CET)

Entschuldige, ich sehe Deine Antwort erst jetzt:

• Gehversuche: Gerade den "Fehler" wollte ich vermeiden (siehe Disk. oben). Zu hart. Ich finde die "Gehversuche" eigentlich eine ganz schöne Metapher, würde es so lassen wollen, glaube ich.
• Ja, die Rolle. Das Visitor-Pattern geht in die Richtung, trifft es mMn aber auch nicht so ganz (würde hier, wenn verlinkt, auf jeden Fall nur verwirren). Akteur halte ich für nicht passend. In EN finde ich auch nichts rechtes, insofern würde ich das Verlinken hier gerne erst mal lassen, da das Prinzip "Rolle" ja eigentlich schön anschaulich ist.
• tauchen in der Praxis Fälle auf fand ich auch nicht so toll, habe ich durch diesen Edit jetzt eliminiert.

--Cactus26 12:29, 29. Mär. 2009 (CEST)

Puh... Bei deinem m.E. extrem schwierigen Thema mitzueditieren ist nicht so ganz einfach. Für mich ist der Aufbau und die Reihenfolge der Abschnitte nicht stimmig. In der gegenwärtigen Form "funktioniert" der Artikel für mich einfach nicht. Es ist eine ziemliche Herausfoderung die alltäglich eingesetzten Paradigmen der OOP verständlich darzustellen. Ich hab viel Neues erfahren, aber konstruktive Hinweise kann ich dir vermutlich nicht mehr geben. --Succu 20:53, 29. Mär. 2009 (CEST) Nachtrag: Das Visitormuster hat mit der Anwenderrolle nichts zu tun.

Danke für Deine Durchsicht und Deine Anregungen. Auch an den Stellen, an denen ich Deine Formulierung nicht exakt übernommen habe, habe ich doch erkannt, dass dort etwas nicht optimal formuliert war. Folgende Einzelheiten noch:

• Anwendungsfälle vs. Nutzung: Das Problem bei "Nutzung" ist, dass nicht klar wird, dass es hier nicht darum geht zu zeigen, wie eine Vererbung codiert wird. Dies könnte man erwarten. "Anwendungsfälle" passt mMn besser zum Inhalt, eine bessere Idee habe ich im Moment nicht.
• Reihenfolge nicht stimmig: Ich vermute, Dein Gefühl rührt daher, dass der Artikel weder Top-Down nicht Bottom-Up vorgeht. Gedanklich habe ich beide Variante durchgespielt. Beide müssen einfach immer vorgreifen. Auch habe ich Bekannte/Kollegen gefragt, was sie denn als erstes lesen wollen. Ergebnis eindeutig: "Für was man es brauchen kann". Also "Anwendungsfälle" ganz vor? Geht nicht. Ist praktisch unverständlich ohne den Kontext ein wenig vorzubereiten. Die jetzige Strategie ist nach der naturgemäß etwas unscharfen Einleitung mit einem Beispiel alle Abstraktionsebenen (was das Beispiel dank eurer Hilfe tats. praktisch schafft!) einmal durchzuzspielen. Das Beispiel laviert dabei um Problemfälle bewusst ein wenig herum (nicht zuletzt ist die Mehrfachvererbung draußen, wofür ich Dir sehr dankbar bin!). Dann die Anwendungsfälle (entsprechend meiner (zugegebenermaßen nicht repräsentativen) Umfrage), dann die Theorie, dann die Spezialfälle. So ist es gedacht. Ich bin einigermaßen glücklich damit und zugegebenermaßen etwas enttäuscht, dass es Dir nicht zusagt.

--Cactus26 08:16, 30. Mär. 2009 (CEST)

Gescheiterte KEA 21. April-11. Mai 2009

Die Vererbung (engl. Inheritance) hat große Bedeutung in der Softwareentwicklung und ist eines der grundlegenden Konzepte der Objektorientierung. Die Vererbung dient dazu, aufbauend auf existierenden Klassen neue zu schaffen. Diese können eine Erweiterung oder eine Einschränkung der ursprünglichen Klasse sein. Neben diesem konstruktiven Aspekt dient Vererbung auch der Dokumentation von Ähnlichkeiten zwischen Klassen, was insbesondere in den frühen Phasen des Softwareentwurfs von Bedeutung ist. Auf der Vererbung basierende Klassenhierarchien spiegeln strukturelle und verhaltensbezogene Ähnlichkeiten der Klassen wider.

• Pro - ein weiterer Teilnehmer, den ich überraschend fand, diesmal aus dem (in meinen Augen bei der Nutzzusammensetzung unverständlicherweise im oberen Qualitätssegment vollkommen unterepresentierten) Bereich der Informatik. Als Laie fand ich den Artikel sehr gut zugänglich und plausibel, auch wenn ich mir keine Wertung über die Vollständigkeit erlauben mag. -- Achim Raschka 07:16, 21. Apr. 2009 (CEST)
•  Pro - Wie sich der Autor mit diesem sehr komplexen Thema auseinandergesetzt hat ist einfach exzellent. --Succu 07:25, 21. Apr. 2009 (CEST)
•  Pro Das ist ein Thema, bei dem man als Programmierer auch mal verzweifeln kann. Umso mehr beeindruckt mich dieser (auch dank der gut gewählten Beispiele) sehr verständlich und geschickt geschriebene Artikel, der schon längst überfällig war. --Leithian ^{Keine Panik!} _Handtuch? 12:31, 21. Apr. 2009 (CEST)
•  Pro sehr ordentlich recherchiert und sauber geschrieben, so wünschen wir uns das doch! --Herbert Klaeren 14:55, 22. Apr. 2009 (CEST)
•  Pro - hätte von mir fast die Publikumsstimme in dieser Sektion erhalten. Sehr anschaulich geschrieben. Gute Beispiele! --Micha 14:58, 22. Apr. 2009 (CEST)
•  Kontra --WiseWoman 19:08, 22. Apr. 2009 (CEST)
  • Nur, dass es kein gutes Beispiel ist. Die Prüfung von einer Fahrerlaubnis ist kein Verhalten eines Fahrzeugs, das hängt vom jewiligen Land ab. Das das als Grund angegeben wird, dieser Methode hier anzubringen, ist sher kraus. Ein Fahrzeug gibt nur Informationen über sich selber ab, nicht über irgendwelche Länderbestimmungen. Da kann man höchstens Achsen unter Kraftfahrzeug machen, und dann unter Motorrad irgendwas (kenne mich nicht mit aus), unter PKW zulässige Passagieranzahl und unter LKW maximaler Ladegewicht. Das ist einer der größten Probleme der Vererbung, die Entscheidung welche Methoden wo hingehören. Das mischen von Methoden ganz unterschiedlicher Klassen (hier: Fahrzeug und Fahrzeugpapiere) ist leider sehr oft in der Literatur anzutreffen und hat schon Generationen von Leute auf falsche Fährten gelockt. Es ist viel Arbeit in den Beispiel gesteckt worden, aber gerade Fahrerlaubnis passt das überhaupt nicht rein.
  • "Speicherabbild" finde ich auch zu hardware-nahe. Wir sprechen ja vom Zustand des Objekts, und es ist wurscht egal ob sie nebeneinander liegen oder Kilobyten von einander entfernt sind. Das sollte ganz raus, bzw. als Bild so was ähnliches wie ein BlueJ-Inspector-Bildchen.
  • Sind die Anwendungsfälle wirklich klar für Laien?
  • Da laenge und breits doubles sind, sollte der Literal 2.0 sein und nicht 2 im Rechteck-Beispiel
  • Die weiteren Abschnitte sind extrem speziell - es wird langsam ein kompletter Dissertation rund um Vererbung. Ein Enzyklopädie legt doch nur dar, was was ist, die Anwendung und Wartungsprobleme sind doch besser in einem Lehrbuch aufgehoben, oder? Für mein Empfinden ist der Artikel noch zu groß und zu komplex für Laien. Aber ich bin ja kein Laie mehr :)

Zu den einzelnen Punkten:

• Was man zu einem Auto speichert, hängt vom Anwendungsfall ab. Alle realen Eigenschaften eines Objekts werden sich sicher (sinnvollerweise) nicht in einer Klasse wiederfinden, sondern nur die, die anwendungsrelevant sind. Und dass ich hier nicht den Klassiker (Methoden "Fahre", "Bremse" etc) verwendet habe, möchte ich eher als Pluspunkt verbucht wissen, denn eine praktische Anwendung, die wirklich solche Methoden brauchen kann, gibt es fast nicht (bestenfalls ein Simulationssystem). Ich halte das Beispiel des Artikels für wesentlich prasisnäher.

Das ist ein Proble der Sichtweise: Aus der Sicht des Herstellers hat die Fahrerlaubnix nichts mit dem Fahrzeugt zu tun. Aus Sicht der Autovermietung ist sie mit dem Fahrzeugt untrennbar verbunden. --HelgeRieder 10:07, 25. Apr. 2009 (CEST)

• Das Speicherabbild soll der Veranschaulichung dienen. Auch soll es den "Mythos Objektorientierung" etwas mildern und zeigen, dass auch da nur mit Wasser gekocht wird.
• Literal "2.0" statt "2". Naja. Performance, Ästhetik oder was ist Deine Motivation?
• Muss sich der Artikel nur an Laien richten? Das tut er sicher primär nicht. Ich bin mir dessen bewusst, dass der Artikel selbst für Fachleute eine harte Kost ist (wäre es für mich auch, hätte ich mich nicht in letzter Zeit so intensiv mit dem Thema auseinandergesetzt). Aber was spricht dagegen, hier nicht mal zu versuchen, alle relvanten Aspekte der Vererbung zusammenzutragen?

--Cactus26 19:30, 22. Apr. 2009 (CEST)

• Insgesamt leider  Kontra --Zipferlak 19:32, 22. Apr. 2009 (CEST)
  • Die Gliederung/Strukturierung ist nicht überzeugend.
  • In Vererbung_(Programmierung)#Anwendungsf.C3.A4lle_der_Vererbung wird der Begriff Anwendungsfall anders benutzt, als es normalerweise in der Informatik üblich ist; dies könnte verwirren und irreführen.
  • "Die Vererbung (engl. Inheritance) ist eines der grundlegenden Konzepte der Objektorientierung" - warum das so ist, erschließt sich aus dem Artikel nicht. Mit anderen Worten: Es fehlen grundlegende konzeptionelle Überlegungen. Der Artikel erklärt zwar, wie Vererbung funktioniert und welche Varianten es gibt, nicht aber, welchen Nutzen sie bringt.
  • Stil und Ausdruck sind gut, aber nicht überzeugend. Bisweilen ist der Text anstrengend zu lesen.
  • Vielleicht ist es zuviel verlangt, aber ich würde mir mehr Informationen über die Implementierung der Vererbung in verschiedenen Entwicklungsumgebungen und Programmiersprachen wünschen.
  • Warum kommt das Wort Objektmodell in dem Artikel nicht vor ?
  • Der Leser erfährt auch nichts über die praktische Bedeutung der Vererbung. Welche und wie viele Softwarehäuser / Entwicklungsprojekte arbeiten damit ? Wie hat sich das in den letzten 30 Jahren entwickelt ?

Nur mal ein spontaner Einwand zur deinen Fragen: Hast du den Artikel aufmerksam gelesen?! --Succu 20:01, 22. Apr. 2009 (CEST)

Danke für Dein Interesse am Artikel. Zu Deinen Punkten

• Die Strukturierung des Artikels ist schwierig. Ich habe mehrere Varianten versucht. Weder Top-Down noch Bottom-Up ist möglich, ohne ständig vorgreifen zu müssen (siehe auch SW-Review). Das einführende Beispiels ist nötig, um die Vererbung in ihrer ganzen Breite vorzustellen. Auch ermöglicht es Lesern, die mit OO nicht vertraut sind, bis hier folgen zu können.
• Anwendungsfall: Der Artikel verwendet das deutsche Wort. Dass man in der WP Use Case eingedeutscht hat, halte ich für praxisfremd, keine gute Idee und nahe an der Begriffsfindung. Bemerkung am Rande: Wir haben es im Deutschen ja eigentlich gut, dass die Fachtermini englisch sind, da dann keine Verwechslungsgefahr zwischen Fachbegriff und Normalsprache besteht. Diesen Vorteil schenkt man hier her. Aber ich hänge nicht an dem Wort. Hättest Du einen Alternativvorschlag?
• Explizitere Darstellung, welchen Nutzen die Vererbung bringt. Ich halte es nicht für sinnvoll, hier alle mit OO assoziierten Vorteile in epischer Breite wiederzukauen. Wiederverwendung von Code und Vermeidung von Redundanz scheinen an vielen Stellen durch. Einen nennenswerten Aspekt hatte ich vielleicht tats. übersehen: Die Analogie zur menschlichen Vorstellung der realen Welt. Das habe ich ergänzt.
• Bisweilen ist der Text anstrengend zu lesen: Das sehe ich auch so, liegt mMn aber nicht am Stil sondern an der Dichte. Ich bin mir darüber im klaren, dass insbesondere der zweite Teil des Artikels auch für Softwareentwickler schwierig ist. Ziel war es, Einblicke in Dinge zu eröffnen, über die sich ein SW-Entwickler beim Tagesgeschäft normalerweise keine Gedanken macht. Und da gibt es im Zusammenhang mit der Vererbung recht viel und Schwieriges.
• Implementierung der Vererbung bei verschiedenen Programmiersprachen: Das wäre wirklich rahmensprengend. Ich habe das ja ansatzweise mit dem (oben als zu physisch kritisierten) Speicherabbild versucht. Mehr ist mMn nicht möglich, auch ist vieles nicht sprach- sondern sogar compilerspezifisch.
• Warum ist Dir der Begriff Objektmodell so wichtig? Was würde er hier bringen? Ein Indiz für mangelnde Bedeutung des Begriffs ist schon die Linkliste. Nicht mal im Artikel UML kommt der Begriff vor. In der Literatur über Softwareentwurf finde ich den Begriff nirgendwo im Index. Für den Artikel Vererbung ist Klassendiagramm passender, der kommt vor und ist jetzt verlinkt.
• Der Leser erfährt auch nichts über die praktische Bedeutung der Vererbung. Doch, in Anwendungsfälle.
• Welche und wie viele Softwarehäuser / Entwicklungsprojekte arbeiten damit ? Was Du meinst ist die praktische Bedeutung von OOP. Die gehört nicht hierher. Das kannst Du alleine schon daran erkennen, dass bestimmt kein Softwarehaus damit wirbt, seit x Jahren die Vererbung zu benutzen

Mein Vorschlag wäre, dass Du den Artikel noch mal in Ruhe liest. Wenn Du weitere Fragen hast, gerne.--Cactus26 08:48, 23. Apr. 2009 (CEST)

• Leider  Kontra--Salier100 20:32, 22. Apr. 2009 (CEST)
  • Die Einleitung ist richtig gut und nun dachte ich.. guter Artikel... dann kam aber nur noch klein, klein, mit Beispielen garniert. Somit hat der Artikel keinen roten Faden und ist IMHO auch nicht OMA-tauglich.Beschränkung auf das Wesentliche wär hier besser
  • In der Einleitung wird Veerbung als Konzept für die SW-Entwicklung bezeichnet. Später wird fast nur noch auf Implementierung und Programmierung eingegengen. (Wundert mich auch nicht, es gibt in der deutschsprachigen WIKI auch nur die Kategorie:OOP. Objektorientierung ist aber wesentlich mehr als Programmierung.
  • Leider, dass muss ich zugeben hab ich das Review des Artikels verpasst.

Dass Dir die Einleitung gefällt, freut mich (war ein hartes Stück Arbeit, siehe SW-Review). Dass der Artikel nicht OMA-tauglich ist, stimmt spätestens ab der Erwähnung des LSP. Aber den Inhalt als "klein klein" zu bezeichnen, ist nicht zutreffend. Beschränkung auf das Wesentliche: Was ist das? Möchtest Du eine seichte Einführung, wie sie in jedem "Jetzt lerne ich OOP" zu lesen ist, wo beispielsweise auf der Syntax zur Codierung einer Vererbung in verschiedenen Sprachen herumgeritten wird? Die Hauptintention des Artikels ist tatsächlich eine andere: Ziel war es, Einblicke in Dinge zu eröffnen, über die sich ein SW-Entwickler beim Tagesgeschäft normalerweise keine Gedanken macht. Und da gibt es im Zusammenhang mit der Vererbung recht viel und Schwieriges. Dass hier de Schwerpunkt auf der Programmierung liegt, ergibt sich dadurch, dass die Vererbung ein Konzept der Programmierung ist. Was fehlt Dir hier zur Entwurfsphase?--Cactus26 09:08, 23. Apr. 2009 (CEST)

• Leider ein schwaches  Kontra, die Einleitung ist ja noch lesbar, aber kurz danach bricht der Faden einfach ab. Ich hab mindesten vier Versuche gebraucht den Artikel durchzulesen, und hab immer noch das Gefühl, dass ich einen Abschnitt doppelt gelesen oder vergessen habe. Er liest sich schlicht weg nicht flüssig, und das vermute ich mal liegt auch an der <code> Verwendung. Diese Schreibweise stört den Lesefluss ungemein. Es macht einfach keinen Spass wenn man andauert neu zum Lesen ansetzetn muss, nur weil ein schlechte Darstellung gewählt wurde. Zu dem Gefühl das ich eine Abschnitt vergessen hab, ich vermisse einfach denn Geschichtsabschnitt (oder was änliches). -- Bobo11 22:32, 23. Apr. 2009 (CEST)

Die Hervorhebung der Bezeichner der Klassen bzw. Methoden im Text finde ich auch nicht so sonderlich hübsch. Einig sind wir uns vermutlich, dass sie hervorgehoben werden müssen und da die Bezeichner auch im Code verwendet werden, hielt ich das Code-Tag mal für nahe liegend (eine Kursivdarstellung hätte das Problem, dass diese auch für andere Dinge verwendet wird). Ich weiß nun nicht, was Dich mehr stört: Der Wechsel der Hintergrundfarbe oder der Wechsel auf einen nicht-proportionalen Font. Sollte das erste der Fall sein, dann gäbe es eine Lösung: <code style="background-color:transparent;">Bezeichner</code> würde zu Bezeichner.

Du wirst Dir fast denken können, dass ich mir über einen Geschichtsabschnitt durchaus Gedanken gemacht habe. Das Thema wurde auch im SW-Review bereits thematisiert. Ein Geschichtsabschnitt hat aus meiner Sicht zwei Probleme: 1. Die Geschichte der Vererbung ist sehr verzahnt mit der Geschichte der OOP an sich und schwer von dieser zu trennen. 2. Ein Geschichtsabschnitt, müsste sehr viele Begriffe verwenden, die an dieser Stelle noch nicht erklärt sind (LSP, Abstrakter Datentyp, Mixin, Mehrfachvererbung, prototypbasierte Programmierung, ...). Aus diesen Gründen halte ich einen solchen Abschnitt hier für wenig sinnvoll. --Cactus26 17:16, 27. Apr. 2009 (CEST)

Zur Art der Hervorhebung von Bezeichnern: Die Darstellung von Quelltexten und Bezeichnern in einem Zeichensatz mit fester Zeichenbreite ist in der Literatur doch üblich. Davon sollte meiner Meinung nach hier deshalb nicht abgewichen werden. Eine Regel, welche Formatierung (außer für größere Programmteile, s. Hilfe:Source) verwendet werden soll, habe ich nicht gefunden. Es gibt die Möglichkeiten <code> (soll laut Hilfe:Textgestaltung nicht verwendent werden) und <span style="font-family:monospace;"> (führt jedoch zum gleichen Ergebnis). Das Darstellungsergebnis hängt jedoch auch wesentlich von den individuellen Browsereinstellungen (Schriftart/-größe) ab, so daß es wenig bringt, die Darstellung für einen bestimmten Nutzer zu optimieren. 80.146.114.84 12:25, 5. Mai 2009 (CEST)

•  Neutral - Da ich mir schwor, hier bei WP von Informatik die Finger zu lassen, nur ein paar Gedanken zu diesem sehr interessanten Artikel, die ich nur als Anregungen verstehe. :-) (Mir fehlt die Zeit den Artikel "durchzuarbeiten")

  Vorweg mein Verständnis zur OO und worauf es dabei für die Vererbung ankommt:

  1. Zweck des objektorientierten Ansatzes ist Datenstrukturen und deren Methoden zu bündeln und mit Eigenschaften zu versehen. Klassen sind nur eine mögliche Implementierung dieses Ansatzes. Für diese Implementierung gibt es vier grundlegende Prinzipien: Vererbung, Kapselung, (Poly-)Morphismus und Abstraktion. Objektorientierte Programmierung (mit und ohne Klassen) ist jedoch auch ohne diese Prinzipien möglich.
     
  2. Dabei stellt Abstraktion das induktive, die Vererbung das deduktive Konzept dar. Das bedeutet, durch die Vererbung werden Datenstrukturen und Methoden vom Allgemeinen zum Besonderen hin entwickelt und erweitert, bei der Abstraktion genau umgekehrt.
     
  3. Die Besonderheit der Vererbung, dass die Datenstrukturen und Methoden, bzw. deren Bezeichner überschrieben werden, dient hauptsächlich der Einheitlich- und Übersichtlichkeit, Ersetz- bzw. Austauschbarkeit und dem Ausschalten von Fehlerquellen. Indirekt soll damit Entwicklungszeit gespart werden. Die Funktionalität der Wiederverwendbarkeit und Erweiterung könnte man auch anders implementieren.

  Und hier was mir auffiel:

  - Im Artikel scheint mir der Zusammenhang und die Abgrenzung zu den anderen Prinzipien nicht gleichmäßig und der Zweck zu wenig dargestellt.

  - Das Beispiel Person zeigt das Modellierungsproblem sehr gut auf. "Apfelkuchen als Erbe von Kuchen und Apfel" sehe ich hingegen nicht generell als Modellierungsfehler an, da die Klasse Apfel nicht nur über die Daten "Apfel", sondern auch über Methoden z. B. zur Verarbeitung verfügt, die eine Oberklasse "Obst" nicht enthalten kann. Ebenso wäre ein Apfelkuchen ohne "Apfelkonstruktor" nicht möglich. :-)

  - Im Bild Klassendiagramm würde ich die Pfeile nach unten zeigen lassen, um die Vererbungsrichtung zu verdeutlichen (vom Allgemeinen zum Besonderen).

  - Beim Absatz Kovarianz und Kontravarianz bin ich mir nicht sicher, ob ich verstehe, was gemeint ist, bzw. ob dort auch steht, was gemeint ist. :-)

Grüße, --Steevie schimpfe hier :-) 06:22, 24. Apr. 2009 (CEST)

Eigentlich hatte ich mir auch geschworen, nie mehr etwas zur Informatik zu machen...

• Ich habe (noch) keine Idee, wie ich aus Deinen allgemeinen Hinweisen zur Objektorientierung Verbesserungen ableiten kann. Abstraktion sehe ich eigentlich fast als Konzept der Programmierung allgemein, nicht nur der Objektorientierung. Außerdem würde ich die Aufgabe, diesen Begriff in seinen Gesamtzusammenhang einzuordnen, eher beim Artikel Klasse sehen.
• Das Apfelkuchenbeispiel soll verdeutlichen, dass "Apelkuchen ist ein Kuchen" stimmt, "Apfelkuchen ist ein Apfel" hingegen nicht so richtig. Somit ist es hier eher angebracht, eine Aggregationsbeziehung zu verwenden. Das ändert nichts an der Notwendigkeit bzw. Verwendung des Apfelkonstruktors.
• Pfeile in Klassendiagrammen andersherum: Es verblüfft mich, dass Du das wirklich forderst. Es widerspräche UML und somit wäre die Verwirrung komplett. Eine andere Lösung wäre, die Verwendung einer gänzlich anderen Notation, aber auch das halte ich bei der heutigen Bedeutung von UML nicht für sinnvoll. Auf einem anderen Blatt steht, dass ich Dir inhaltlich recht gebe: Die Notation der Vererbungsbeziehung in UML halte ich auch für kontraintuitiv. Aber was will man machen, es setzt sich halt nicht immer das bessere durch.
• Kovarianz und Kontravarianz: Habe den Abschnitt nochmal überarbeitet, vielleicht hilft das ja

--Cactus26 19:04, 27. Apr. 2009 (CEST)

Sorry, ich hatte die Antwort nicht mitbekommen. Ich weiß nach Deiner Antwort leider nicht, ob ich mich nicht doch irre. :-)
Bezüglich der Einordnung von Abstraktion hast Du jedenfalls recht, doch bei der Vererbung tritt Abstraktion als "der" Gegenpol auf. Wenn der Artikel allerdings und das hatte ich völlig übersehen (oder ignoriert?) auf UML aufbaut, verschwindet dieser Aspekt, da die Generalisierung sowohl die Vererbung sowie die Abstraktion umfasst. Wieso die Generalisierung eine Umkehrung der Spezialisierung ist/sein soll erschließt sich mir allerdings nicht (Sprachlich beschreiben die beiden Begriffe natürlich die entgegen gesetzte Richtung wie es "kleiner" (<) und "größer"(>) auch tun). Deshalb hatte ich auch die Pfeile, die ich bzgl. Vererbung schrecklich finde, angesprochen. Sie beschreiben eben die generalisierte Zugriffsrichtung und nicht die Vererbungsrichtung, so wird eine abstrakte Klasse wie z. B. Währung mit den Subklassen $ oder € genauso dargestellt wie Person zu Mitarbeiter und Kunde.
Den Fehler des Apfelkuchenbeispiels sehe ich nach Deiner Erklärung vielmehr in der Abstraktheit der Klasse "Kuchen", denn Deine Erklärung funktioniert nur bei Mehrfachvererbung abstrakter Klassen. Das für mich schönste Beispiel einer Mehrfachvererbung ist übrigens die Combobox aus Liste und Edit-Feld. Viele Grüße, --Steevie schimpfe hier :-) 19:29, 9. Mai 2009 (CEST)

Die Beziehung zwischen Generalisierung, Spezilaisierung und Abstraktion scheint mir wirklich etwas verschwommen. Eine Philosophie von UML ist ja, dass Darstellungselemente übergreifend über die unterschiedlichen Diagrammtypen einheitlich verwendet werden. Dabei taucht die Generalisierung ja noch nicht einmal in vielen verschiedenen Diagrammtypen auf. Allein im Klassendiagramm ist die Bedeutung abhängig von der Abstraktionsebene wohl unterschiedlich. Aus meiner Sicht ist es ein wesentlicher Schritt der Verfeinerung eines konzeptionellen Klassenmodells zu entscheiden, welche Generalisierungsbeziehungen tatsächlich in eine Vererbungsbeziehung umgesetzt werden und welche nicht und sich beispielsweise in schlichten Klassenattributen wiederfinden. In der Praxis zeigt sich nach meiner Erfahrung aber, dass versucht wird, die Klassenmodelle bereits in der konzeptionellen Phasen so zu gestalten, dass nur wirkliche Vererbungsbeziehungen als Generalisierung modelliert werden (man will ja schließlich Code daraus generieren....).

Das Beispiel "Apfelkuchen" ist natürlich nicht fair gegenüber dem Apfel. Er hat natürlich auch deshalb keine Chance, da Apfel das wesentlich konkretere Konzept im Vergleich zu Kuchen ist. Ich denke, darum ging es B. Meyer (von dem das Beispiel stammt) aber nicht. Es soll ein anschauliches Beispiel sein, wo im einen Fall eine klare Ist-Ein-Beziehung besteht, im anderen nicht. Mehr nicht. Und dass die zum Apfel nicht passt, liegt nicht nur an dessen mangelnder Abstraktheit. "Kuchenkrümel" stellt in ähnlicher Weise trotz der Abstraktheit von Kuchen keine sinnvolle Spezialisierung von "Kuchen" dar.

Combo-Box als Beispiel der Mehrfachvererbung: War auch das erste, was mir in den Sinn kam. Ich hatte es sogar schon im Artikel (siehe hier). Problem ist, dass ich keine Klassenbibliothek gefunden habe, die das tatsächlich so macht. Mir ist auch in etwa klar, warum (aus verschiedenen anderen Gründen ist es ohnehin hilfreich, praktisch alle Eigenschaften des Edit-Controls schon in einer Basisklasse "Control" zu haben, dass es die Mehrfachvererbung nicht mehr braucht). Nur dies hier langatmig erklären und ggf. diskutieren zu müssen, wollte ich nicht. Eigentlich aber schade, da es tatsächlich ein wunderschönes Beispiel wäre.

--Cactus26 09:02, 11. Mai 2009 (CEST)

Die Praxisbezogenheit des Artikels ist natürlich "der" Pluspunkt, außerdem habe ich wie auch schon bei anderen Artikeln festgestellt, dass Kritik das Eine ist, aber dass das Andere, nämlich das Verbessern ungleich schwerer fällt. Im Normalfall liest man einfach den Artikel und merkt nicht, was der Autor schon alles bedachte und wieder verwarf. Weil ich das gesehen habe und meine Bedenken mittlerweile zerstreut sind, ist ein  Pro sicher gerechtfertigt.
Nur bezüglich des Apfelkuchenproblems möchte ich noch einmal anmerken, ich die Aussage "Häufig tritt dieser Fall in Verbindung mit Mehrfachvererbung auf. Apfelkuchen als Erbe von Kuchen und Apfel stellt ein bildhaftes Beispiel dieses Modellierungsfehlers dar, ..." zwar für richtig, die Begründung "... da Apfel keine sinnvolle Basisklasse ist." in Zusammenhang mit der angesprochenen "Ist-Ein-Beziehung" nach wie vor für falsch halte. In einer "echten" Mehrfachvererbung tritt diese "Ist-Ein-Beziehung" doch gerade nicht auf oder doch? :-) Viele Grüße, --Steevie schimpfe hier :-) 14:15, 11. Mai 2009 (CEST)

---

 Neutral s.unten - Zuerst einmal ein ganz großes Lob an den Hauptautor einen Informatik-Arikel, zu zu einem komplexen Thema, zu dem man auch eine Diss schreiben könnte, so weit ausgebaut zu haben. Viele Informatik-Artikel, je spezieller desto besser, sind zwar recht informativ aber dorch recht weit weg von blauen und grünen Bapperln. Das Problem ist, dass der Artikel aus dem Schreibwettbewerb kommt und nicht vom Hauptautor angemeldet wurde. Dem großteils neu entstandenen Artikel fehlt dadurch etwas die Reifezeit und die fachliche Diskussion. Gerade bei diesem Thema gehen die Meinungen in Informatik oft etwas auseinander..

Aus meiner Sicht ist es unglücklich das Konzept der Vererbung in der Informatik in "Vererbung (Programmierung)" und den noch nicht vorhandenen Artikel "Vererbung (Künstliche Intelligenz)" zu trennen. Auch bei Unterschieden in Details ist die Grundidee die gleiche und deshalb sollte es besser EIN Aritkel "Vererbung (Informatik)" werden. Was mir im Artikel noch aufgefallen ist:

• Einleitung: "Diese können eine Erweiterung oder eine Einschränkung der ursprünglichen Klasse sein." Erst sehr viel später wird erklärt, dass die Einschränkung sich auf Subtypen bezieht, die Erweiterung auf eine Erweiterung der Funktionalität (neue Methoden)
• Diagramme besser noch etwas Größer - die Schrift MUSS lesbar sein.
• "Überschreiben von Methoden" wird benutzt, bevor es erklärt wird.
• "Prüfe Fahrerlaubnis()" nur dem der es eh schon weiß wir klar, warum das eine Methode sein muss
• Wenn das Beispiel Rechteck->Quadrat (auch wenn es in der Literatur oft vorkommt) kein gutes Beispiel ist, sollte man ein besseres Beispiel nehmen ..
• ist es Abschicht das Smalltalk nur am Rande und nur bei der Mehrfachvererbung erwähnt wird? Wäre doch ein ganz nettes Beispiel für die Trennung zwischen Deklaration und Implementierung
• auch Eiffel kommt nur am Rande vor
• Die Kurzassung von Kovarianz und Kontravarianz versteht man nur, wenn man den Hauptartikel zuvor gelesen hat.
• Insgesamt wären noch mehr Diagramme zur Verdeutlichung der Inhalte schön
• Der Artikel springt zu oft zwischen den betrachteten Programmiersprachen hin und her. Wer die grundlegende Philosophie dieser Sprachen nicht kennt, wird sich schwer tun hier Zusammenhänge zu verstehen
• Unterschiede bei der Vererbung in Programmiersprachen im expliziten (Java etc) und impliziten (PHP etc) Datentypen.
• Automatische Typumwandlung bei der Vererbung wird kaum betrachtet.
• Die letzten spezielle Kapitel sind in den Kurzfassungen kaum verständlich und könnten auch in einem Absatz mit Verweisen auf die jeweilgen Spezialartikel zusammen gefasst werden.

Gesamtsicht: Ohne Zweifel lesenswert aber zum grünen Bapperl sollte er noch etwas reifen. Grüße --HelgeRieder 10:07, 25. Apr. 2009 (CEST)

Danke für Deine detaillierte und kompetente Durchsicht, Deine Anerkennung und die vielen Anregungen.

• Vererbung (KI) in diesen Artikel: Ich hatte darüber nachgedacht. Aus meiner Sicht sprechen zwei Dinge dagegen: 1. Dieser Artikel tut sich mit dem v.a. durch die Sprachvielfalt verursachten Spagat schon schwer genug, da ist es nicht hilfreich, den Bogen noch weiter zu spannen. 2. Die Vererbung in der KI hat mit der der Programmierung mMn nicht viel mehr gemein, als dass sich Eigenschaften eines Vorgängers beim Nachfolger wiederfinden, die Analogie geht also nicht weit (wenn überhaupt) über die zur Vererbung (Biologie) hinaus.
• Diese können eine Erweiterung oder eine Einschränkung der ursprünglichen Klasse sein., Detaillierung in der Einleitung: Ich halte den Versuch diesen Widerspruch in der Einleitung bereits aufzulösen nicht für angebracht, da die Einleitung ohnehin an der Grenze des Machbaren ist. Zudem ist es ja nicht ganz so einfach, wie Du es darstellst, die Erweiterung kann ja durchaus in der Ergänzung von Attributen (nicht nur neue Methoden) bestehen und es ist dann eine Frage des Blickwinkels (wie später im Artikel erläutert).
• Diagramme größer: Habe zwei jetzt größer dargestellt. In meiner Konfiguration ist die Schrift nun lesbar. Bei Dir nicht?
• "Überschreiben von Methoden" wird verwendet bevor es erklärt wird.: Ehrlich gesagt wird "Überschreiben" überhaupt nicht im Artikel erklärt. Es ist verlinkt. Ich sehe es auch nicht als Aufgabe des Artikels an, Grundbegriffe der OOP zu erklären. Das wäre uferlos.
• Beispiel Rechteck/Quadrat: Es kommt mMn aus zwei Gründen zurecht in der Literatur häufig vor: 1. Es ist anschaulich; 2. Es lassen sich viele Dinge daran erläutern. Und ganz falsch ist es ja nicht, es ist eine Frage des Blickwinkels.
• Smalltalk kommt in der Tag ein wenig kurz (gemessen an der historischen Bedeutung, gemessen an seiner aktuellen Bedeutung allerdings nicht, siehe hier). Es wird vertreten durch seinen Nachfolger Ruby. Mir ist nicht ganz klar, worauf Du mit "Trennung zwischen Deklaration und Implementierung" hinaus willst.
• Eiffel kommt nur am Rande vor: Na ja, gemessen an seiner Bedeutung (sowohl historisch als auch aktuell) ist Eiffel eindeutig überrepräsentiert. Dies ist auch in der Literatur so und hängt sicherlich an der Person Bertrand Meyer. Ich konnte ihn mal persönlich kennenlernen und ich teile fast alle seiner Standpunkte bzgl. OOP, dass sich Eiffel nie durchsetzen konnte ist mW auf seine kompromisslose Haltung zurückzuführen, was die Hoheit über die Sprachdefinition anbelangt.
• Kontravarinaz und Kovarianz: Ich habe den Abschnitt überarbeitet, vielleicht ist es er jetzt verständlicher.
• Mehr Diagramme zur Verdeutlich wären schön: Sicher. Hättest Du eine konkrete Idee?
• Der Artikel springt zu oft zwischen den Programmiersprachen: Die Gliederung geht primär einzelne Aspekte der Vererbung durch und beleuchtet dann, welche Sprachen in dieser Hinsicht Besonderheiten aufweisen. In Lehrbüchern ist manchmal der umgekehrte Ansatz zu finden, d.h. die Gliederung erfolgt primär nach der Sprache und dann nach den einzelnen Aspekten. Dies wäre für den Artikel aber sehr nachteilig, da das mit erheblich mehr Redundanz verbunden ist (die in den Büchern fast gewollt ist, da ein Entwickler meist ohnehin nur eine Sprache betrachtet). Ich hatte mal überlegt, ob es sinnvoll sein könnte, dem allgemeinen Artikel sprachspezifische Versionen der verbreitetsten Sprachen zur Seite zu stellen (also Vererbung (C++), Vererbung (Java und C#) etc.). Bin aber unschlüssig, das wäre dann schon sehr nahe am Lehrbuch.
• Statische vs. dynamische Typisierung, Typumwandlung: Hier sollte unbedingt was ergänzt werden, das hatte ich bisher übersehen (hier muss natürlich auch Smalltalk erwähnt werden). Wird auch "nur" ein Überblicksabschnitt (es gibt ja Dynamische Typisierung etc). Werde mich in den nächsten Tagen an die Arbeit machen.
• Kurzfassungen der letzten speziellen Kapitel kaum verständlich: Das wäre natürlich schade. Der Artikel versteht sich grundsätzlich ja als Überblicksartikel. Ziel ist es demnach, hier zumindest einen Eindruck zu vermitteln, um was es geht. Ich werden die Formulierungen prüfen, wenn Du konkrete Vorschläge hast, gerne. Ich halte allerdings nichts davon aufzugeben und auf eine reine Schlagwortliste zu reduzieren.

Danke nochmals, wäre angenehm, wenn der Reifungsprozess wie bei einem guten Wein abliefe, einfach eine Weile in den Keller damit....--Cactus26 10:06, 28. Apr. 2009 (CEST)

 Info: - Habe nach Anregung von Helge den Abschnitt "Typkonvertierung bei statischer Typisierung" ergänzt.--Cactus26 16:58, 28. Apr. 2009 (CEST)

 Pro - Obwohl ich Wikipedia schon lange nutze, ist dies mein erster aktiver Beitrag. In so weit möchte ich mich gleich für evtl. Formfehler entschuldigen.

Ich benutze Wikipedia in zwei Situationen:

• Ich möchte einen mir neuen Begriff einordnen lernen.

Die vorliegende Einleitung erfüllt diese Aufgabe sehr ausgewogen, indem sie

• die Vererbung auf das Wesentliche reduziert
• und verständlich innerhalb verwandter Themenbereiche einordnet.

• Ich möchte einen umfassenden Überblick über ein mir neues oder bereits bekanntes Thema gewinnen. Dabei erwarte ich, dass der Artikel

• möglichst alle relevanten Aspekte enthält und mir die Vertiefung eines Aspekts durch Verweise auf weiterführende Lektüre erleichtert.

Dem Autor ist der Balanceakt zwischen Vollständigkeit und Kompaktheit gut gelungen. Auch beim Einsatz von Verweisen wurde ein angemessenes Mittelmaß gefunden. Einziger Kritikpunkt - wie schon von anderen angemerkt: Details zum Speicherabbild einer Objektinstanz hätte ich in diesem Artikel nicht erwartet.

• besprochene Aspekte unter Zuhilfenahme von Beispielen soweit veranschaulicht, dass ich die dahinter liegenden Problemstellungen erkennen und auf dieser Basis weiter recherchieren kann:

Die gewählten Beispiele erfüllen diesen Zweck voll und erleichtern zusammen mit der kompakten Sprache das Verständnis der komplexen Zusammenhänge. Natürlich kann ich den hier geäußerten Wunsch nach noch besseren Beispielen nachvollziehen, ist er mir doch aus der Lektüre kommerzieller Literatur bestens bekannt. --Lokomoko 18:43, 02. Mai 2009

Mittlerweile  Pro: einige Punkte verändert, einige Bedenken ausgeräumt, und bei einigen wenigen Punkten habe wir einfach eine unterschiedliche Sicht auf die Dinge. Aber das ist bei einem Begriff, der in unterschiedlichen Kontexten recht unterschiedlich verwendet wird normal. --HelgeRieder 21:01, 3. Mai 2009 (CEST)

insgesamt  Pro, auch wenn ich einige Sonderaspekte eventuell in einem solchen Hauptarteikel weggelassen hätten. Ich überschaue aber das Thema nicht in allen Verästelungen. Das Problem der Wartbarkeit ist angesprochen wird aber in Zukunft bei einigen zentralen Klasse, die von vielen Projekten gemeinsam benutzt werden vermutlich noch einiges an Kopfzerbrechen bringen, da hier die Koordinierungsaufwände erheblich infolge der Vererbung ansteigen können. --Wmeinhart 23:20, 4. Mai 2009 (CEST)

 Neutral Inhaltlich in Ordnung, leswenswert sicherlich, aber mit "exzellent" tue ich mir schwer. Dazu wirken die Unterkapitel recht lose, es fehlt der rote Faden. Da ich aber keinen besseren Vorschlag habe, werde ich der Kandidatur nicht entgegenstehen.--Avron 16:06, 6. Mai 2009 (CEST)

Der Artikel ist in dieser Version mit 9  Pro und 4  Kontra nicht exzellent. Die Contra-Stimmen
sagen, dass dem Artikel der rote Faden gänzlich fehlt, es kommt kein Lesefluss auf. Er sollte aber
lesenswert sein. --MEWRS Zigarre gefällig? 19:54, 11. Mai 2009 (CEST)

Anmerkungen zur Exzellenz-Kandidatur 2009/05

Konzept des Artikels und der fehlende rote Faden

Ich unterstelle, dass sich vorwiegend folgende Leser für den Artikel interessieren:

1. Leser, sich weder mit Programmierung noch Objektorientierung näher befassen und die wissen möchten, was denn die Informatiker unter "Vererbung" verstehen
2. Leser, die sich in der Programmierung ein wenig auskennen, die aber von Objektorientierung kaum Ahnung haben und die wissen wollen, wozu die Vererbung gut sein soll
3. Fachleute in OOP, die wissen wollen, was es bei der Vererbung so alles gibt

Hauptsächliche Zielgruppe des Artikels ist die dritte Gruppe. An die erste Gruppe richtet sich die Einleitung und mit Abstrichen das Beispiel, dann dürfte es nicht mehr machbar sein. Für die zweite Gruppe ist der Abschnitt "Anwendung der Vererbung" direkt nach dem Beispiel vorne im Artikel platziert. Nach diesem Abschnitt dürfte es auch für diese Gruppe schwer werden.

Der Artikel richtet sich also bewusst nicht an Leser, die die objektorientierte Programmierung (OOP) erlernen wollen. Für diese ist die Vererbung ja nur ein Aspekt, diese sind mit einem allgemeinen Artikel oder Buch über OOP besser bedient. Da die dritte Gruppe Hauptzielgruppe des Artikels ist, wird dieses Thema nicht nur für eine Programmiersprache dargestellt, sondern übergreifend (was für Einsteiger sicherlich nicht ideal ist und sie überfordert).

Einen roten Faden hat der Artikel nicht, zumindest nicht durchgängig, das stimmt. Das liegt mMn hauptsächlich daran, dass der Artikel ja nicht die gesamte OOP rekapitulieren will, sondern eben nur die Aspekte beleuchtet, bei denen die Vererbung eine besondere Rolle spielt und diese sind eben teilweise etwas zusammenhanglos.

--Cactus26 16:58, 26. Jun. 2009 (CEST)

Beispiel Fahrzeugvermietung / PruefeFahrerlaubnis

Was sind die Kriterien für ein gutes Beispiel:

• Es sollte möglichst viele Aspekte abdecken
• Es sollte leicht verständlich sein (d.h. die Aufgabenstellung des Beispiels sollte nicht selbst abstrakt sein und Verständnisschwierigkeiten bereiten)
• Es sollte praxisrelevant sein

Die Literatur bietet mMn nicht gerade berauschende Beispiele. Aber auch das Beispiel des Artikels hat so seine Probleme. In Wahrheit wird vermutlich keine Fahrzeugvermietung einen derartigen Aufwand betreiben, die Fahrerlaubnis eines Kunden zu überprüfen. Aber man kann es sich zumindest vorstellen (die Entwickler, die ich dazu befragt habe, konnten es ganz gut). Schön ist auch die einfache, klare Schnittstelle der Methode PruefeFahrerlaubnis. Problematisch ist aber tatsächlich, dass die Klasse "Fahrerlaubnis" an sich ein wenig im dunkeln bleibt. Auch riecht das ganze fast ein wenig nach multiple dispatch, d.h. die Logik müsste, wenn man es perfekt macht, eigentlich sowohl in der Klassehierarchie Fahrzeug als auch in der Klassenhierarchie Fahrerlaubnis abgewickelt werden. In der Praxis wird man sich das aber kaum antun. Die Klassen, die das für ein Unternehmen hauptsächlich Relevante abdecken, tragen die Hauptlast der Implementierung. Das ist für eine Fahrzeugvermietung eindeutig die Klasse Fahrzeug. Eigentlich will das Beispiel diese Problematik gar nicht adressieren, sie hat wenig mit dem eigentlichen Thema zu tun, es lässt sich nur nicht vermeiden. Es stört meiner Erfahrung nach aber auch nur wenige. Ein Beispiel, das das dargestellte Problem nicht hat, aber sonst die gleichen Vorteile bietet, wäre natürlich schön. Ich kenne bisher nur keins.

--Cactus26 16:58, 26. Jun. 2009 (CEST)

Verbesserungsvorschläge, Lesenswertkandidatur Juni 2009

• Das Intro und das Beispiel des ersten Abschnitts sollten ohne Allgemeinplätze auskommen, für Laien verständlich sein und die Sache mit dem Mut zur Vereinfachung auf den Punkt bringen, der Rest kann Fachkundige ansprechen und differenzierter sein. „Grundlegendes Konzept“, „ist von Bedeutung“ , „ist in frühen Phasen des Softwareentwurfs von Bedeutung“ oder „ wichtige neue Perspektiven eröffnet“ sind leider inhaltslose Floskeln, die in einem Introtext insbesondere unangebracht sind. Warum von Bedeutung usw. sollte stattdessen mitgeteilt werden.
• Auch vor Erfindung von Vererbung und OOP wurde schon „Vererbung“ in der Softwareentwicklung praktiziert. Man hat beispielsweise vorhandene Software genommen, kopiert und für neue Zwecke angepasst. Wurde dann in der Ursprungssoftware was geändert, ging der Softwareentwicklungsprozess für die Weiterverwender von vorn los. Vererbung formalisiert das und automatisiert das - das ist ein Kernaspekt. Es ist formalisiert in den Klassenbibliotheken definiert, was verwendet wurde, was verändert wurde und was ergänzt wurde. „Die Vererbung dient dazu, aufbauend auf existierenden Klassen neue zu schaffen.“ Diese Formulierung ist zu schwach. Vererbung dient in der Kernmotivation dazu, die Abhängigkeiten von verwendetem und neuem Code zu formalisieren, um den Prozess von Weiterentwicklung und Fehlerbeseitigung über alle Abhängigkeiten hinweg zu automatisieren, bei Vermeidung von Coderedundanz. Der Artikel stellt dabei auftauchende Detailprobleme da, ohne erst einmal deutlich zu machen, dass das Problem durch Vererbung prinzipiell gelöst ist. Also: In herkömmlicher Technik kann ein Softwaremodul so wie es ist verwendet werden, oder man handelt sich ein Updateproblem ein, wenn man es verändert und damit vom Ursprung abkoppelt. Bei Einsatz von OOP mit Vererbung kann die Ursprungssoftware in Form der vererbenden Klassen ergänzt und verändert werden, die Updateprobleme reduzieren sich auf Spezialfälle.
• Das wichtige Wort Polymorphismus kommt im Textteil des Artikels zu kurz. Für die Rezipienten von Wikipedia, meist Laien auf dem Gebiet der Softwareentwicklung, sollte der Unterschied herkömmlicher Techniken zu Vererbungstechniken in der Leistungsfähigkeit klarer und OMA-tauglich dargestellt werden. Ein Kirschbaum ist nicht der Stamm vom Apfelbaum, die Blätter vom Zwetschenbaum und eine neue Frucht. Das wäre Modultechnik. Der Kirschbaum ist eine grundsätzlich andere Erscheinungsform der Untergattung Obstbaum der Gattung Baum. Die Gemeinsamkeiten der sehr unterschiedlichen Erscheinungsformen von Bäumen liegen in tiefer verborgenen Bauplänen und Vererbungsketten. Anders als die Natur kann die Softwaretechnologie in den Basisklassen und abgeleiteten Klassen der Vererbungsstammbäume neue Eigenschaften implementieren, die alle Nachfahren dann sofort erben. Das macht die Mächtigkeit der Technologie aus. „Hat eine große Bedeutung“ ist mir da zu oberflächlich, der Text vermittelt den Clou der Sache der gängigsten Vererbungstechnik imho nicht.
  • Beispiel 1: Bei den Fahrzeugen des Beispiels im Artikel muss man nach der Erfindung der GPS-Navigation nicht in vielen Klassen einbauen, ob das Fahrzeug damit ausgerüstet ist, vielmehr sucht man die geeignete Vererbungsklasse für die einmalige Implementierung und LKWs, PKWs, PKWs von BMW, BMW5er ….. und alle weiteren abgeleiteten Klassen haben es dann. Das sollte der Laien-Leser dann auch als Kernaspekt der Leistungsfähigkeit verstehen.
  • Anderes OMA-taugliches Beispiel: Wird eine neue Technik erfunden, beispielsweise Touchscreens, muss man nicht an unzähligen Softwareobjekten der grafischen Benutzeroberfläche wie Menüs, Aktionsschalter, Listenfelder, Radio-Buttons, …. Änderungen anbringen, sondern der gemeinsame Vorfahre in der Klassenbibliothek erhält die Funktionalität des Reagierens auf Touch-Ereignisse. Komplexität und Vielfalt wird reduziert, Redundanz vermieden. Werden Touch-Ereignisse in einer zentralen Vererbungsklasse für grafische Bedienobjekte wie Mausclicks behandelt, ist darauf aufbauende Software touchscreen-kompatibel, ohne jemals dafür getestet und konzipiert gewesen zu sein und ohne jede Anpassungsprogrammierung.
• Die Kritik an dieser Technologie wird im Artikel nicht auf den Punkt gebracht. Formulierungen wie „Es gibt auch Verwendungen der Vererbung, die nicht als sinnvoll angesehen werden.“ sind schwammig. Das Problem ist: Es gibt keine systematischen Methoden, die in einem ingenieursmäßigen Verfahren zu leistungsfähigen Klassenbibliotheken mit einem inneren Vererbungszusammenhang führen. Vieles hängt von der Kreativität und Inspiration der Softwarearchitekten ab. Die Leistungsfähigkeit auf der einen Seite wird erkauft mit hohen Ansprüchen an die Architektur, ohne dafür zielführende Vorgehensmodelle zu haben.
• Interfaces finden verschiedene Verwendung, insbesondere als eine zur Vererbung komplementäre Technik. In dieser Bedeutung sind sie im Artikel ein Defizit.--Hgn-p 11:11, 29. Jun. 2009 (CEST)

Danke für Dein Feedback. Ich habe es durchgesehen, Antworten und Reaktionen zu den einzelnen Punkten werden etwas dauern. Aufgefallen ist mir, dass Du mich an einigen Stellen auf Dinge hinweist, die mir wohl zu selbstverständlich waren, als das ich sie weiter ausgeführt hätte. Das ist sicher hilfreich. Es fällt mir aber nicht ganz leicht, diese Anregungen umzusetzen, so dass der Artikel ausgewogen bleibt, sich nicht verzettelt und nicht zu umfangreich wird. Ich werde es versuchen, dauert aber ein bisschen.--Cactus26 12:46, 29. Jun. 2009 (CEST)

Nun habe ich Deine Punkte bearbeitet:

• "Inhaltslose Floskeln" in der Einleitung: Na ja, so ganz ohne Inhalt sind sie ja nicht, "unkonkrete Aussagen" wäre bei vielleicht passender gewesen und selbst das trifft bei einigen Deiner zitierten Beispiele mMn nicht zu. Das "grundlegende Konzept", "wichtige, neue Perspektiven" etc. muss zu Beginn der Einleitung erstmal für sich stehen, sonst würde die Einleitung sich völlig verzetteln. Dir kommen solche Aussagen möglicherweise deshalb inhaltslos vor, weil sie oft unbegründet gebraucht werden. Hier sind sie aber gerechtfertigt und die Begründung liefert der Artikel. Bei "wichtige neue Perspektiven eröffnet" steht das wesentliche Beispiel ("komponentenbasierte Entwicklung") direkt dahinter.
• Copy&Paste als "Vererbung" vor der OOP: Aufgrund dieses Hinweises habe ich die Einleitung ergänzt. Das war mir wohl zu selbstverständlich. Weiterhin habe ich diesen Hinweis, dass bei nachträglicher Erweiterung der Basisklasse die Spezialisierung profitiert, ergänzt.
• Auch Dein nächster Absatz hebt darauf ab, dass Die Vererbungsbeziehung in der OOP im ggs. zur biologischen Vererbung eine fortdauernde Beziehung ist. Im habe Deinen GPS-Vorschlag im Beispiel ergänzt. Ich hoffe, dass damit der Aspekt nun klar genug wird. Das Beispiel mit dem Touchsreen halte ich für ein hervorragendes Beispiel für Polymorphie, erst in zweiter Linie für Vererbung.
• Apropos Polymorphie: Du wünscht Dir mehr darüber hier. Sicher sind Vererbung und Polymophie zwei eng verzahnte Konzepte. Dennoch hat Polymorphie zurecht einen eigenen Artikel. Mehr darüber hier zu verlieren, würde diesen Artikel immer mehr zu einem über OOP allgemein machen.
• Kritik an Vererbung, nicht auf den Punkt gebracht: Zunächst einmal: Es gibt auch Verwendungen der Vererbung, die nicht als sinnvoll angesehen werden.: Dieser Satz wird ausführlich mit Beispielen konkretisiert, ist also nicht schwammig. Deine hier dargestellten Aspekte (möchte ich mal zusammenfassen mit "es gibt kein Patentrezept") betreffen OOP allgemein, wenn nicht sogar die Programmierung allgemein. Solche Ausführungen hier finde ich zu weitgehend. Die Kritik an der Vererbung konkret findet sich hauptsächlich im Abschnitt "Vererbung im Kontext der Softwarewartung"
• Interfacevererbung (Du meinst doch Interfaces im Sinne von JAVA?) ist nicht komplementär zur Vererbung. Mag sein, dass man das aus JAVA-Sicht so sehen kann, aber jede Form der Interface-Vererbung ist in weniger restriktiven Sprachen wie z.B. C++ problemlos abbildbar. Diese Interfaces sind halt eine Spezialität von JAVA (und C#), was sie zugegebenermaßen aufgrund der Verbreitung schon wesentlich macht. Aber es ist doch schon einiges dazu im Artikel. Was sollten denn für Besonderheiten der Interface-Vererbung noch erwähnt werden?

Noch mal Danke für Dein ausführliches Feedback. Auch wenn ich Deine Meinung nicht in allen Punkten teile, haben Deine Hinweise den Artikel sicher wieder ein Stück weitergebracht.--Cactus26 09:43, 30. Jun. 2009 (CEST)

Wenn du dir mal das Intro des Artikels Masern anschaust, dann wirst du denke ich einräumen, dass da Laien wie Fachleute gleichermaßen angesprochen werden. Wenn hingegen jemand ratlos ist, in welchem Zusammenhang Informatiker von Vererbung sprechen und warum sie sich dieses Wortes bemächtigen, wird das Intro dieses Artikels fürchte ich nicht befriedigend sein. Da der Laie den Begriff Vererbung vermutlich aus der Biologie und dem Güterrecht kennt, sollte man sowohl den Grund der Verwendung dieses Wortes für eine Softwaretechnologie als auch den wesentlichen Unterschied deutlich machen. Im Güterrecht und in der Biologie handelt es sich um einen einmaligen Vorgang, in der Informatik um einer dauerhafte Beziehung zwischen Erber und Vererber; Vererbung ist ein permanent wiederholbarer Vorgang in der Informatik. Ich versuche mich nach der KLA mal an einem variierten OMA-tauglichen Introtext oder einem kleinen Abschnitt am Artikelbeginn über die Begriffsverwendung Vererbung in der Informatik.

Dto. werde ich nach der KLA zum Thema Interfaces, Polymorphie und dem grundlegenden Problem der Konstruktion geeigneter Klasenbibliotheken mit einem inneren Vererbungszusammenhang ein paar kleinere Änderungen beisteuern. Eine tabellarische Übersicht, welche Programmiersprache welche Vererbungsmechanismen unterstützt, scheint mir auch ganz sinnvoll.

Die KLA läuft ja zu Recht auch so gut. Spätere Ergänzungen von mir kannst du entspannt abändern oder revertieren, wenn sie dir für eine erneute KEA nicht zielführend erscheinen. Momentan habe ich zu wenig Zeit, um während der KLA einen Beitrag mit Substanz zu liefern und diesen mit dir zu diskutieren. Ich habe das Thema bei der KEA leider verpasst. Grüsse --Hgn-p 16:09, 30. Jun. 2009 (CEST)

Es erstaunt mich, dass Dir die Einleitung so missfällt. Diese ist nach diversem Feeback insbesondere während des SW-Review in dieser Form entstanden und ich bin recht zufrieden damit. Ich finde, sie kann mit "Masern" durchaus mithalten, wobei die Ausgangslage weit schwieriger ist (Masern kennt zumindest jeder und ist weit weniger abstrakt). Der Hinweis, dass die Vererbungsbeziehung bei der Programmierung dauerhaft ist, ist ja jetzt dank Deines Hinweises enthalten. Viel Verbesserungspotential sehe ich da nicht, ich werde selbst noch mal einen Laien-Test durchführen.

Polymorphie möchte ich in diesem Artikel nicht breiter auswalzen. Natürlich ist der Artikel Polymorphie derzeit in keinem sonderlich schönen Zustand. Diesen anzugehen, ist sicher ein ähnliches Projekt wie dieses hier (ich würde Dich dabei unterstützen, wenn Du das machen würdest). Aber mir würde es nicht gefallen, wenn jetzt als Notlösung dieser Artikel nebenbei das auch noch abhandelt, dann wie gesagt, ist es ein Artikel über OOP und nicht mehr über Vererbung.

Bei den Interfaces sollte man bedenken, dass das "nur" JAVA und C# betrifft. Insofern würde ich es hier auch nicht unendlich detaillieren wollen, schaue mir aber Verbesserungsvorschläge unvoreingenommen an. Wir sollten halt aufpassen, dass der Artikel nicht zu riesig wird. Viel Spielraum sehe ich da nicht mehr. Bei so einem allgemeinen Thema ist immer das Problem, dass irgendwer meint, sein spezieller Aspekt kommt hier zu kurz. Aber wenn man alle Wünsche befriedigt, ist man irgendwann bei 200k.

Auf Deine Übersicht, welche Programmiersprache welche Vererbungsmechanismen unterstützt, bin ich gespannt. ich freue mich auch darüber, dass Du mir offensichtlich die redaktionellen Entscheidungen überlässt. Ich würde das zwar in dieser Situation an Deiner Stelle auch so halten, selbstverständlich ist das aber nicht, ich habe das auch schon anders erlebt. Manchmal dauert es etwas länger mich von manchen Dingen zu überzeugen, aber Du kannst mir glauben, dass ich nicht aus reiner Rechthaberei etwas ablehnen werde. Viele Grüße --Cactus26 15:07, 1. Jul. 2009 (CEST)

Lesenswert-diskussion vom 26.6. - 3.7.2009 (erfolgreich)

Der Artikel zu einem der Kernkonzepte der Objektorientierung hatte im Schreibwettbewerb Anfang dieses Jahres den 6. Platz in seiner Sektion erreicht und hatte im April/Mai bereits als exzellenter Artikel kandidiert, wurde aber vom Auswerter als nicht exzellent eingestuft. Seit dieser Zeit habe ich einen Abschnitt "Persistenz und Datenbanken" ergänzt, der mMn noch fehlte. Zu den Hauptkritikpunkten der damaligem Kandidatur habe ich auch ein paar Gedanken auf der Diskussionsseite zusammengestellt.--Cactus26 17:01, 26. Jun. 2009 (CEST)

•  Pro Ich finde ihn gut geschrieben und verständlich. Lesenswert ist er auf jeden Fall. Kleine Anmerkung: Das Gelb der UML Diagramme ist sehr heftig – entfärbt fände ich besser; Die Reihenfolge von Einzelnachweisen–Anmerkungen–Weblinks fände ich als Weblinks–Anmerkungen–Einzelnachweisen besser. -- blunt. 19:23, 26. Jun. 2009 (CEST)

Es freut mich sehr, dass Du den Artikel verständlich findest. Bei der Farbe hatte ich aus Bequemlichkeit die Standardfarbe des verwendeten Tools belassen. Habe nun mal selbst eine Farbauswahl getroffen, hoffe es sagt dir zu. Zur Reihenfolge der hinteren Abschnitte: Für die Reihenfolge "Literatur, Einzelnachweise, Weblinks" habe ich mich als Standard entschieden, nicht zuletzt deshalb, da ich bei den Einzelnachweisen häufig einen Bezug zur Literatur gibt (ich wiederhole in den REFs die Literaturtitel nur teilweise) ist es vorteilhaft, diese beiden direkt beieinander zu haben und auch Anmerkungen nicht dazwischenzuschieben. --Cactus26 10:50, 28. Jun. 2009 (CEST)

Die Farben sind besser geworden und das andere Geschmackssache. Gruß -- blunt. 17:50, 1. Jul. 2009 (CEST)

• Pro - Ich fand ihn bereits damals exzellent - und sehe entsprechend auch hier kein Hindernis (natürlich als Laie) -- Achim Raschka 21:00, 26. Jun. 2009 (CEST)
•  Pro - mehr als lesenswert! --Succu 08:46, 27. Jun. 2009 (CEST)
•  Pro Ein beachtlicher und ordentlicher Artikel. Wenn man bedenkt, dass das eine der wichtigsten Technologien unserer Zeit ist und sieht, wie wenig dazu Ende Februar 2009 in Wiki vorhanden war, kann man dem Hauptautor nur für seine Arbeit zur Füllung einer beschämenden Lücke in Wiki danken. Meine Verbesserungsanregungen habe ich auf die Diskussionsseite des Artikels gestellt. Verbesserungsvorschläge --Hgn-p 11:15, 29. Jun. 2009 (CEST)
•  Pro Der Artikel ist wirklich sehr gut aufgebaut und vor allem sprachlich extrem gut gelungen. Ich habe mal noch ein paar Tippfehler korrigiert. Allerdings wäre ich dafür, die Späte Bindung noch zu erklären, denn das ist momentan nicht der Fall. Das ist aber für Lesenswert vielleicht nicht sooo wichtig, für Exzellent sollte es aber wichtig sein!! Außerdem würde ich mir wünschen, für den ersten Satz im Abschnitt Zusammenspiel der Methoden in der Klassenhierarchie eine Begründung zu lesen (also warum soll häufig nur Funktionalität ergänzt und die Implementierung der Basisklasse weiterhin genutzt werden?).--Stegosaurus Rex 18:58, 29. Jun. 2009 (CEST)

Ich danke Dir für Dein nettes Feedback und v.a. auch für Deine vielen Korrekturen (finde es fast unglaublich und es ist mir etwas peinlich, wie viele Fehlerchen noch im Artikel waren). Die Erläuterung, warum oft für spezialisierende Methoden die Nutzung der Basisklassenimplementierung angebracht ist, habe ich ergänzt. Das Late Binding würde ich aber näher bei Polymorphie sehen. Sicher scheinen bisher schon einige Aspekte der Polymorphie hier durch, die Konzepte sind eng verflochten, aber mehr sollte es mMn auf keinen Fall werden, sonst platzt der Artikel auseinander und wird zu einem Artikel über OOP.--Cactus26 08:20, 30. Jun. 2009 (CEST)

•  Pro --Grim.fandango 20:42, 29. Jun. 2009 (CEST)
•  Pro Inhaltlich, sprachlich, und strukturell überzeugend --GDK Δ 12:54, 30. Jun. 2009 (CEST)
•  Pro Schon nach dem knappen Durchfallen bei der Exzellenzkandidatur hätte man den Artikel direkt als lesenswert auszeichnen können. (Ich denke, trotz Beteiligung am Review kann ich hier mitstimmen). 80.146.91.94 16:37, 30. Jun. 2009 (CEST)
•  Pro Umfassend, gut formuliert -- Jörgens.Mi ^Diskussion 06:18, 2. Jul. 2009 (CEST)

 Pro Lesenswert ist der Artikel auf jeden Fall. (Wobei ich mit der Gliederung nach wie vor ein paar Probleme habe) Ansonsten ist mir folgendes aufgefallen:

• an manchen Stellen würde ich mir Code-Beispiele wünschen z. B. Schnittstellenvererbung
• "Persistenz und Datenbanken" der Titel ist etwas missverständlich. Konkreter wäre "Persistenz in Datenbanken" -- Avron 08:45, 2. Jul. 2009 (CEST)

"Persistenz in Datenbanken" habe ich geändert (urspr. dachte ich "und", weil die Serialisierung kurz erwähnt wird, aber das ist wohl Quatsch). Code-Bsp. für Schnittstellenvererbung: Ich denke darüber nach, ob mir hier ein sinnvolles Bsp. einfällt. Man müsste schon zwei verschiedene Implementierungen eines Interface darstellen, dass das ganze was hergibt. Vielleicht lässt sich damit ja auch hgn-p's Wunsch abdecken, die Interface-Vererbung mehr zu detaillieren.--Cactus26 17:44, 2. Jul. 2009 (CEST)

Der Artikel in dieser Version ist Lesenswert mit 10   Pro. --Vux 02:33, 3. Jul. 2009 (CEST)

Gliederungsvorschlag

• Beispiel
• Anwendungen der Vererbung
• Varianten der Vererbung von Typ und Implementierung
• Zusammenspiel der Methoden in der Klassenhierarchie
• Sonderprobleme

Mehrfachvererbung

Kovarianz und Kontravarianz

Datenkapselung im Rahmen der Vererbung

Typkonvertierung bei statischer Typisierung

Programmiersprachen mit zentraler Basisklasse

Persistenz in Datenbanken

• Vererbung in besonderen Anwendugsgebieten

Vererbung im Kontext der Softwarewartung

Vererbung bei prototypenbasierter Programmierung

Mal ein Vorschlag von mir, bestimmt nichts komplett ausgegrorenes. Aber vielleicht etwas worauf man aufbauen kann.-- Avron 14:17, 3. Jul. 2009 (CEST)

Danke. Ich schau mir das mal in Ruhe an. Ich werde jetzt erstmal allerdings voraussichtlich eine Woche nicht online sein, dauert also ein bisschen.--Cactus26 14:39, 3. Jul. 2009 (CEST)

Mit etwas Abstand kann ich Deinem Vorschlag viel abgewinnen. Ich konnte irgendwie nicht über meinen Schatten springen und dachte bisher "Kovarianz und Kontravarianz" müsste unbedingt nach "Varianten der Vererbung von Typ und Implementierung" kommen, da es dazu einen Bezug hat. Die von Dir weiter vor platzierten Abschnitte sind aber weit wichtiger. Ich habe auch nicht das Gefühl, dass der Artikel durch die neue Gliederung nicht mehr schlüssig ist. Die Zusammenfassung von "Vererbung im Kontext der Softwarewartung" und "Vererbung bei prototypenbasierter Programmierung" habe ich nicht umgesetzt, da das mMn eigentlich nichts miteinander zu tun hat, zudem halte ich die Wartung doch für so bedeutend, dass ich sie nicht herabstufen möchte.--Cactus26 10:25, 10. Aug. 2009 (CEST)

Ich finde es jetzt auf jeden Fall aufgeräumter. Man kann sicherlich lange darüber philosophieren, was das die beste Aufteilung ist.--Avron 08:39, 17. Aug. 2009 (CEST)

Sehe ich auch so. Die Herabstufung einzelner ins Detail gehender Abschnitte macht die Sache zumindest etwas übersichtlicher. Danke.--Cactus26 09:55, 17. Aug. 2009 (CEST)

Kein ordentliches Für und Wider

Der Artikel stellt meiner Meinung nach mehr oder minder das Java-Konzept von einfacher, öffentlicher Vererbung, Interfaces und zentraler Basisklasse als Höhepunkt der Sprachentwicklung dar. Er wirkt eher wie ein Auszug aus einem Java-Lehrbuch als wie ein lesenswerter enzyklopädischer Artikel. Eine objektivere und spezifischere Auseinandersetzung mit den Themen fehlt in dem Artikel.
Bei mehrfacher Vererbung wären beispielsweise diese Punkte zu erwähnen:
-Die Fehlen von implementierten Methoden in Interfaces löst zwar das Namensproblem, ist aber eher syntaktisches Salz. Die signatures in g++ oder die Interfaces in Vala ermöglichen solches Verhalten
-Jedes Objekt-Layout für mehrfache Vererbung hat verschiedene Vor- und Nachteile. Beispiele:
"Normales" C++-ABI-layout: This-pointer adjustments machen der Laufzeitumgebung das Leben schwer, es gibt einige zusätzliche Felder.
Inlined layouts funktionieren zusätzlich nicht mit getrennter Kompilierung und brauchen auch viele zusätzliche Felder.
Beim zweidimensionalen bidirektionalen layout ist wiederum getrennte Kompilierung nicht möglich, ein Feld zur Typidentifikation wird in jedem Fall benötigt.
Beim field-dispatcher oder auch beim Zugriff nur über Methoden (wie in Ruby) gibt es ein großes Overhead.
Bei mehrfacher Vererbung gibt es also kein ideales Objekt-Layout
-Das Diamond-Problem ist dagegen eher unwichtig, schließlich ist es mit einer Zeile Code stets schnell gelöst.
Zentrale Basis-Klassen:
-erzeugen nun mal ein Overhead
-werden für einfache Strukturen mit Werte-Semantik ebenso wenig gebraucht wie VTables
-D unterscheidet dabei zwischen "struct" und "class"
Private und öffentliche Vererbung:
-Die Existenz sollte erwähnt werden
-Private Vererbung ist in Zusammenhängen, in denen Polymorphismus keine Rolle spielt, eine einfache Lösung für viele Probleme, die beispielsweise in Java nur durch endlose Delegationen gelöst werden
Alternativen zur mehrfachen Vererbung:
-D bietet mit einer Kombination aus Interfaces und mixins ein sehr flexibles Konzept an
-g++ bietet mit Signatures eine selten genutzte mächtigere Alternative zu Interfaces
-Interfaces erlauben kein policy-based design

Überarbeitung (auch hinsichtlich NPOV) ist hier erforderlich.
--Chricho 15:11, 27. Sep. 2009 (CEST)

Danke für Dein Feedback. Ich bin gerade an anderen Baustellen zu Gange, komme aber darauf zurück, bitte etwas Geduld. Viele Grüße --Cactus26 08:12, 28. Sep. 2009 (CEST)

Der Artikel beschränkt sich auf eine endliche Zahl Programmiersprachen. Dass dabei von Dir genannte Sprachen bzw. Dialekte wie g++ oder Vala und deren Konzepte nicht vorkommen ist sicherlich in bestimmter Hinsicht schade. Allerdings ist die Bedeutung dieser Sprachen (zumindest derzeit) doch deutlich geringer als der im Artikel erwähnten Sprachen. Eine Beschränkung bei den erwähnten Sprachen halte ich für nötig, damit der Artikel noch halbwegs verständlich bleibt. Etwas unklar ist mir, wie Du den Artikel unterstellen kannst, er Stelle Java "als Höhepunkt der Sprachentwicklung" dar. Da solltest Du noch mal etwas genauer hinschauen, beispielsweise stellt der Artikel klar, dass Java keine durchgängige Trennung von Interface- und Implementierungsvererbung unterstützt, was Java-Programmierer häufig anders sehen (nebenbei: Java gehört nicht zu meinen persönlichen Favoriten bei den Programmiersprachen, mir scheint Du hast eine gewissen Java-Phobie, was ich in gewisser Hinsicht sogar teile, versuche da ein wenig gegenzusteuern). Die Kriterien für die Sprachen, die ich in diesem Artikel vorstelle bzw. erwähne, waren folgende:

• Welche Sprachen werden in Literatur, die sprachübergreifend ist und Vergleiche zwischen objektroientierten Sprachen enthält, erwähnt?
• Wie verbreitet sind die Sprachen (ein Anhaltspunkt dabei)?
• Haben die Sprachen historische Bedeutung?

Java ist derzeit eindeutig die verbreitetste Sprache. Deshalb spielt sie im Artikel eine zentrale Rolle.

Zu Deinen einzelnen Punkten:

• Mehrfachvererbung: Die Punkte, die Du ansprichst, sind größtenteils technischer Natur und ein Problem für den Entwickler des Compilers oder für die Laufzeitumgebung. Das Diamond-Problem ist dagegen ein konzeptuelles Problem, das bei Anwendungsdesign und -entwicklung relevant ist. Deine Aussage "schließlich ist es mit einer Zeile Code stets schnell gelöst" macht mich stutzig. Hast Du es wirklich verstanden? Die technischen Probleme bei Mehrfachvererbung sehe ich nicht in diesem Artikel nicht, es gibt für Mehrfachvererbung ja einen separaten Artikel und selbst da weiß ich nicht, ob man in diese Detailebene gehen sollte.
• Zentrale Basisklasse: Hier verstehe ich nicht, was Du mir sagen willst. Hier geht es weniger um die Unterscheidung von primitiven Typen und Klassentypen. Ich halte es mehr für eine Philosophie- als für eine Overhead-Frage, ob eine Sprache eine zentrale Basisklasse anbietet (eine zentrale Basisklasse verführt dazu, diese aus Bequemlichkeit in Schnittstellen an Stelle eines sauberen Designs zu verwenden).
• Private und öffentliche Vererbung: Wird im Artikel erwähnt und auch dass Java das nicht kann ("Reine Implementierungsvererbung"), mehr halte ich nicht für nötig.
• Alternativen für Mehrfachvererbung: Würde ich in diesem Artikel nicht weiter detaillieren wollen, sondern im Artikel Mehrfachvererbung selbst. Allerdings wäre dabei mein Fokus aus o.g. Gründen wieder auf Java

--Cactus26 13:57, 5. Okt. 2009 (CEST)

Ich finde einfach, dass der Artikel immer auf das Standard-Java-Konzept abzielt, ohne Alternativen zu nennen. Hab den Kram nicht bei Mehrfachvererbung reingeschrieben, weil ich denke, dass der dortige Kram auch hier enthalten ist. Zentrale Basisklassen sind eine Overhead-Frage, da z.B. das Ducktyping à la STL meist genau das selbe bringt. Ich habe gerade keine Zeit. Werde darauf zurück kommen. Das mit privater Vererbung habe ich übrigens übersehen. g++ ist definitiv verbreitet, Vala brachte ich nicht als ein Beispiel für etwaige ganz andere Konzepte, sondern nur als weiteres Beispiel für Sprachen, in denen Interfaces Implementierungen erlauben. Das Diamond-Problem halte ich neben einem Sprach-Problem (Möglichkeiten zur Steuerung, in C++ z.B. virtual, using...) auch für ein Compiler-Problem, schließlich ist es eine Frage des Objekt-Layouts, ebenso wie bei this-pointer-adjustments. --Chricho 11:52, 10. Okt. 2009 (CEST)

Um es noch mal klar zu machen: Dass Java im Artikel eine bedeutende Rolle spielt ist nicht etwa opportunistisch, weil es die Sprache ist die ich am meisten mag oder kann, sondern einfach der Verbreitung und Bedeutung dieser Sprache geschuldet. Und es kommen durchaus andere Konzepte zur Sprache, nur vielleicht nicht diese, die Du Dir wünschen würdest. Ich weiß nicht, ob C++ Templates heute noch eine derart große Bedeutung haben, dass sie im Artikel unbedingt erwähnt werden müssten, auch wenn Du anscheinend eine Vorliebe für sie hast.

• Zu g++: Dieser Compiler mag zwar eine gewisse Verbreitung haben, es gibt aber noch nicht einmal einen Artikel in der deutschen WP über diesen Compiler und dessen C++-Dialekt, insofern wäre Erwähnung hier wirklich völlig unangebracht.
• Das Diamond-Problem spielt sicher auch bei Implementierung des Compilers und Laufzeitsystems eine Rolle, wichtig ist mir eben, dass es im Ggs. zur Pointer-Artihmetik eben auch konzeptionell bei Anwendungsentwicklung relevant ist.
• Ich möchte Dich bitten, ohne Diskussion keine größeren Änderungen am Artikel vorzunehmen. Ich habe sehr viel Arbeit in diesen Artikel investiert und zudem ist der Artikel auch vielfach bewertet und kritisiert worden, d.h. Meinungen vieler sind hier schon indirekt eingeflossen. Auch muss man sich bewusst sein, dass der Artikel nicht noch unendlich größer werden sollte. Weitere, tiefer gehende Besonderheiten der Vererbung sehe ich eher bei den einzelnen Sprachen als hier. Dieser Artikel kann nur einen Überblick geben und die Themen anreißen, damit er zumindest noch einen gewissen "roten Faden" aufweist (siehe Kritik oben). muss er sich auch auf eine gewisse Grundmenge erwähnter Sprachen beschränken.
• "Overhead" bei Delegation als Ersatz für private Vererbung: Mag sein, dass es einen Overhead gibt, dieser ist aber im Vergleich zum Code-Aufwand nicht der Rede wert. Dass der Funktionsaufruf dynamisch erfolgt, stimmt für C# beispielsweise nicht unbedingt. Was Du mit "zusätzliche Referenzen" meinst (Plural?), ahne ich nur, eine Referenz auf das Delegationsobjekt impliziert das Konzept der Delegation, die Referenz auf die Basisklasse entfällt dafür, also warum zusätzlich?
• Duck-Typing ist ein Aspekt, den man tatsächlich noch im Artikel erwähnen könnte. Ich hatte es bei Bearbeitung des Artikel überlegt, mich dann aber doch dagegen entschieden. Zu beachten sind dabei aber zwei Dinge: 1. Duck-Typing ist eigentlich keine Vererbung mehr, es ist ein konkurrierendes Konzept. Es sollte deshalb nur kurz erwähnt werden, nicht mehr. Zudem hat es einen eigenen Artikel. 2. Es gibt durchaus kritische Stimmen zu diesem Konzept.

--Cactus26 10:33, 12. Okt. 2009 (CEST)

• Also große Änderungen habe ich sicherlich nicht vorgenommen und habe ich auch nicht einfach so vor ;)
• Delegation: Eine Referenz auf das Objekt und eine Referenz auf die Typinformation innerhalb des Objekts (in Java eine zusätzliche Referenz auf ein Class-Objekt)
• Duck-Typing: Ich dachte an die statische Template-Variante, und die funktioniert (zumindest in der Praxis bei gut designten Bibliotheken wie der STL) genauso gut, wie wenn man in Java bestimmte Interfaces (wie Iterator) benutzt, ist nur schneller (sieht man einmal von zusätzlichen Funktions-Instanzen ab)
• g++: Tatsächlich, dabei gibt es sogar Artikel zum GNU Java Compiler (dessen Verbreitung geringer sein sollte) und zum GNU Fortran Compiler. Aber immerhin wird g++ fast immer da in der Wikipedia erwähnt, wo C++ kompiliert werden soll
• Diamond: Ich finde man kann damit leben, dass das möglich ist, man muss sich nur überlegen, was man genau will. Ich für mich sehe die Probleme bei mehrfacher Vererbung jedenfalls eher in der Compiler/ABI-Anlage und evtl. der Performance, wohingegen man mit den Steuerungsmöglichkeiten, die man z.B. in C++ hat immer gut klarkommen sollte. In Script-Sprachen wie Python oder Scheme sind die Probleme wohl geringer. (ich wüsste zumindest niemanden, der sich um eine Scheme-ABI oder Objekt-Speicher-Layout in diesen Sprachen kümmern würde)
• Templates: Klar habe ich eine Vorliebe dafür :D Da weder generische Programmierung noch Duck-Typing, Policy-Based-Design o.ä. erwähnt werden, denke ich, sie müssen an dieser Stelle nicht erwähnt werden. Zu deiner Frage nach der Bedeutung: Ich denke, im C++/D-Alltagsgeschäft denke ich, dass sie hauptsächlich wie Generics für Container verwendet werden. Ansonsten werden generische Algorithmen in Standard-Fällen oft benutzt (sortieren etc.) sowie als kleiner Helfer beim Umgang mit Containern. Und dann gibt es eben noch ein paar "Hyper-Anwendungen" wie Boost (wird hier und da allerorts genutzt), Loki oder sigc++ (wird z.B. bei Gnome genutzt). Vermutlich steigt die Nutzung eher an (besserer Compiler-Support...), beläuft sich aber in einem sehr geringen Rahmen. Aber das ist ja eigentlich Offtopic.
• Zur Verbreitung: Java ist vermutlich bei neuen Projekten vorne, insgesamt sind aber die Bedeutungen von C, C++, aber auch Cobol oder Fortran, nicht zu unterschätzen. Denk an System-Software, Riesen-Projekte wie KDE, Gnome, Mozilla, GNU oder die meisten Compiler und Interpreter. Und diese Projekte sind sicherlich auch nicht inaktiv. (zumindest wenn ich auf meinen Computer schaue, findet sich so gut wie kein Java oder C# ;))

--Chricho 12:58, 14. Okt. 2009 (CEST)

• Deine Änderungen: Nein, was Du bisher geändert hast, ist völlig ok. Ich hatte anfangs nur Angst, Du könntest den gesamten Artikel auf den Kopf stellen, darüber hätte ich mich nicht gefreut.
• g++: Der Microsoft-Compiler dürfte schon ein ernsthafter Konkurrent sein. Aber wie auch immer. Ich würde mich über einen Artikel g++ und dabei gut zusammengestellte Details über die Spracherweiterungen freuen (insbesondere die oben von Dir erwähnten Signatures, also eine Zusammenfassung von diesem). Wäre das nichts für Dich?
• Diamond-Problem, Mehrfachvererbung: Beim Diamond-Problem ist ja auch interessant, welche Lösungen die Sprachen (die richtige Mehrfachvererbung unterstützen) dafür überhaupt anbieten. Dein technischer Fokus auf das Thema ist interessant. Hier würde es zu weit führen, aber im Artikel Mehrfachvererbung halte ich es durchaus interessant, das Binärspeicherabbild beispielsweise von C++ mal zu skizzieren. Hättest Du Lust dazu?
• Templates: Meine Einschätzung ist natürlich subjektiv, auch wenn ich mich um Objektivität bemühe. Ich hatte schon den Eindruck, dass die Zahl der Veröffentlichungen über Generische Programmierung eher abgenommen haben. Vielleicht erwähne ich Templates, wenn ich etwas über Duck-Typing ergänze (Btw.: Der Artikel Duck-Typing erwähnt die statisch getypte Variante der C++-Templates nicht, auch hier könntest Du mal Hand anlegen...)
• Programmiersprachenverbreitung: Cobol und Fortran sind ja gottseidank außen vor, da sie nicht objektorientiert sind ;-) C++ wird im Artikel ja gewürdigt. Bei den erwähnten Sprachen hat auch eine Rolle gespielt, welche Sprachen in der Literatur, die sich mit dem Thema OOP sprachübergreifend befasst, erwähnt werden.

Viele Grüße --Cactus26 09:25, 15. Okt. 2009 (CEST)

Also würdest du sagen, es wäre sinnvoll, im Artikel Mehrfachvererbung einmal zu zeigen, wofür der überhaupt da ist? Klingt in Ordnung, um die Uhrzeit mache ich jetzt aber nichts mehr. ;)
Liebe Grüße --Chricho 01:34, 17. Okt. 2009 (CEST)

So kann man es auch ausdrücken, Du hast mich durchschaut ;-) --Cactus26 08:27, 17. Okt. 2009 (CEST)

Empfohlene Tiefenbeschränkungen

<aus Benutzer Diskussion:Sebastian.Dietrich hierher verschoben>

Hallo Sebastian, danke für Deinen Beitrag. Ich habe ihn in den Wartungsabschnitt umgezogen und etwas umformuliert. Allerdings halte ich nichts von Aussagen einer fixen, fest vorgegebenen sinnvollen Schachtelungstiefe, auch wenn es Leute gibt, die solche Ratschläge in die Welt setzen. Eine Obergrenze von 4 bis 6 ist definitiv Unsinn, sehr viele (sehr gute) Klassenbibl. weisen intern bereits eine höhere Schachtelung auf. Der wahre Kern des Ratschlags ist, dass man immer abwägen muss, wenn man eine Zwischenschicht einzieht, was das in Relation zur Komplexitätssteigerung bringt. Tiefer verschachtelt ist nicht unbedingt besser, manche Entwickler schießen in ihrer Begeisterung dann über das Ziel hinaus. Wenn Du Lust hast, detaillierter zu diskutieren, kann ich Dir gern meine Telefonnummer geben.--Cactus26 (Diskussion) 06:57, 2. Aug. 2012 (CEST)

<ende>

Hi Cactus! Ich denke eine Diskussion darüber macht auf der Diskussionsseite des Artikels mehr Sinn.

Ich persönlich halte viel von derartigen Aussagen. Derartige Aussagen helfen, dass Leute nicht mehr behaupten können ihre 20-Ebenen Hierarchie wäre state-of-the-art. Jede Vererbungshierarchie (auch die von sehr guten Klassenbibliotheken) die mehr als z.B. 6 Hierarchieebenen hat ist verdammt schwer zu warten (& auch zu verstehen). Ohne Zahlen zu nennen und nur "weniger ist weniger komplex" bringt meiner Erfahrung nach nichts.

Aber egal was ich oder du persönlich davon halten. In der Literatur werden diese Zahlen genannt und darum sollte dieser Abschnitt drinnen bleiben. Ich habe ihn jetzt wieder an der Stelle reingegeben, wo du auch den anderen Abschnitt hingeschoben hast. --Sebastian.Dietrich ✉ 08:59, 2. Aug. 2012 (CEST)

• Ich habe grundsätzliche Bauchschmerzen mit derlei kategorischen und pauschalen Aussagen, insbesondere wenn konkrete Zahlen festgelegt werden.
• Es ist immer kontextabhängig; die Umstände des Einzelfalls sind zu beachten.
  • Es kann sein, dass 4 benutzerdefinierte Ebenen eine sinnvolle Obergrenze für eine konkrete Anwendung sind. Darüber können aber sieben vorgegebene Ebenen im System-Konzept liegen, bis es von einem Basis-Object ausgeht.
• Es gibt auch Leute, die herumlaufen und verbreiten, jedes Unterprogramm/Methode/Funktion mit mehr als 50 Zeilen sei schlecht und müsse unbedingt gelöscht werden und die Programmierer wären Vollidioten.
  • Es gibt in der Tat Anwendungsbereiche, wo jede Methode mit 1–3 Statements auf andere Methoden und Eigenschaften verweist. Fein.
  • Es gibt in der numerischen Mathematik, Physik und Ingenieurwissenschaften algorithmisch orientierte Unterprogramme mit selbst 500 Statements, die Dutzende weitere Unterprogramme aufrufen und völlig korrekt und nachvollziehbar programmiert sind; jede Aufteilung in Fitzelchen-Methoden mit zehn Statements und 52 Aufrufparametern würde Chaos bewirken.
• Man kann erwähnen, dass in der Literatur die genannte Aussage vertreten wird.
• Sinnvoller ist der Hinweis, dass keine unnötigen Ebenen in das ursprüngliche Design hineinkonzipiert werden sollen.
  • Im Laufe einer mehrjährigen Weiterentwicklung kann es etwa zwecks Kompatibilität zu anderen Datenmodellierungen erforderlich werden, dass zusätzliche Abstraktionsebenen eingezogen werden müssen.
  • Die Empfehlung mit numerischer Angabe hilft dann keinem weiter.
  • So what?
• Solche Forderungen sind nett für akademische Theoretisiererei; wenn reale Produkte über zehn Jahre vielfach wachsen, sind sie wenig hilfreich.

Viele Grüße --PerfektesChaos 11:17, 2. Aug. 2012 (CEST)

Naja derzeit steht ja ohnedies nur "werden in der Literatur Zahlen von 4 bis 6 genannt." - also keinerlei POV oder Empfehlung.

Wie bei jeder Metrik gibts natürlich (wenige) Situationen wo deutlich höhere Zahlen als angebracht angesehen werden. Und wie bei jeder Metrik wirst Leute finden, die einfach aus Faulheit/Unwissenheit mehr als diese Grenze immer noch für gut erachten.

Meine persönliche Erfahrung aus der Praxis ist, dass wenn keine Zahlen genannt werden die Ergebnisse deutlich schlechter werden, als wenn Zahlen genannt werden. Das ist dann oft auch ein Grund warum Projekte an Komplexität scheitern bzw. unwartbar werden. Darum sind für meine Praxis Zahlen aus der Literatur wichtig - und die möchte ich in der Wikipedia inkl. Literaturangaben finden. Ich gehe davon aus, dass es anderen auch so geht. Aussagen wie "weniger ist besser als mehr" reicht für die Praxis (& natürlich auch Theorie) einfach nicht.--Sebastian.Dietrich ✉ 17:56, 2. Aug. 2012 (CEST)

Literatur zur Softwareentwicklung gibt es viele und "Empfehlungen" ebenfalls, die sich auch nicht selten widersprechen. Alt ist auch schon der Wunsch nach "harten" Kriterien ("if-Verschachtelung nie mehr als 3 Ebenen" gab es schon in den1970er Jahren), im Moment scheint es aber so etwas wie eine Metrik-Mode zu geben. Der Wunsch des Managements die Qualität der Software messen zu können ist verständlich und es gibt Autoren, die diesen Wunsch bedienen. Aber es ist unverantwortlich, harte Kriterien für etwas zu definieren, wo keine hingehören. Es ist richtig, dass solche harten Kriterien wohl mehr bewirken, als der Versuch, sich dem eigentlichen Problem zu stellen. Ich habe nicht selten Fälle erlebt, wo Methoden geteilt wurden, um nicht gegen die Regel ("Eine M. darf nicht mehr als x Zeilen haben") zu verstoßen. Mit dem Resultat einer aufgeblasenen internen Schnittstelle. Damit wird das ursprüngliche Ziel konterkariert. Der Code wird unverständlicher, nicht selten werden außerdem bei solchem "Metrik-Refacturing" Fehler eingebaut.

Das eigentliche Problem, Vererbung möglichst nur dann anzuwenden, wann es angebracht ist, ist sehr vielschichtig. Wann ist Aggregation besser, wann ist es sinnvoll, eine Zwischenebene einzusparen und wann kann man auf eine Vererbung schlicht verzichten und die Aufgabe dem Verwender der Klasse überlassen? Wir sind uns einig, dass das im Rahmen des Artikels nicht vermittelbar ist. Es ist ja auch nicht die Intention der Wikipedia, Wikipedia ist kein How-To. Dies gilt aber auch für die aus dem eigentlichen Problem kondensierten harten Kriterien.

Mit diesem Argument und auch, weil der Standpunkt von Benutzer:PerfektesChaos in allen wesentlichen Punkten mit meinem übereinstimmt, werde ich diese Empfehlung wieder aus dem Artikel entfernen. Ich möchte Dich bitten, wenn Du damit nicht einverstanden bist, bei WP:3M (oder anderswo) eine weitere Meinung einzuholen.--Cactus26 (Diskussion) 07:30, 3. Aug. 2012 (CEST)

Hätte mir gewünscht, dass das zuerst ausdiskutiert wird und dann erst gelöscht. --Sebastian.Dietrich ✉ 08:10, 3. Aug. 2012 (CEST)

Ich verstehe, wenn Du persönlich was gegen solche Metriken hast und fürchte dass ich Dich auch nicht überzeugen kann, dass die sehr wohl sinnvoll sind und den Code wartbarer (und nicht wie Du schreibst unwartbarer) machen.

Darum geht es hier aber nicht. Es geht darum, dass diese Metriken existieren (da sind wir und ja einig) und deshalb mMn in der Wikipedia aufgeführt werden sollten (da sind wir uns nicht einig). Dass es wie Du sagst viel Literatur zur Softwareentwicklung gibt und ebenfalls auch viel "Empfehlungen", ist doch gerade ein Beleg dafür dass diese Informationen in der WP erwähnt werden sollten. Dass die Informationen sich auch nicht selten widersprechen stimmt vielleicht für andere Metriken, in diesem Fall aber sicher nicht (Du wirst wohl kein Buch/Artikel finden, wo Vererbungshierarchien von mindestens 7 Ebenen empfohlen werden). Und auch wenn sich diese Informationen widersprechen, so gehört diese Information (nämlich dass es widersprüchliche Erkenntnisse dazu gibt) erst recht in die Wikipedia.

Ich halte das Thema Softwaremetriken für zu wichtig, um konkrete Metriken zu verschweigen. Darum rufe ich jetzt WP:3M an. --Sebastian.Dietrich ✉ 08:10, 3. Aug. 2012 (CEST)

3M: Auch ich halte so eine pauschale Festlegung auf 4-6 Vererbungsgenerationen für nicht haltbar, da diese Tiefe häufig schon im BasisSprachumfang ausgeschöpft wird (von den darauf aufsetzenden Frameworks mal ganz zu schweigen). Mir liegen die Quellen nicht vor, aber bist Du sicher, dass hier überhaupt die gesamte Vererbungstiefe gemeint ist und nicht nur die innerhalb einer Software-Schicht?

Im Sinne der Theoriedarstellung könnte man diese Zahlen natürlich trotzdem in den Artikel aufnehmen, jedoch muss dann erkennbar sein, dass es sich hierbei keinesfalls um eine allgemein akzeptierte Regel handelt, sondern um Einzelmeinungen, deren Inhalt in der Praxis (s.o.) häufig widerlegt wird. IMO dürfte es übrigens müssig sein, im Sinne einer Beweislastumkehr, Belege zu fordern, die genau dieser These widersprechen, da ja nicht jede derartige Behauptung überhaupt genug Wogen schlägt, um prominenten fachlichen Widerspruch zu ernten. --Martin Kraft (Diskussion) 10:55, 3. Aug. 2012 (CEST)

Damit wäre ich einverstanden. Mir ist nur wichtig, dass im Artikel Zahlen genannt werden (inkl. Ref auf Literatur). Wobei ich nicht damit einverstanden wäre diese als Einzelmeinungen abzutun, die in der Praxis häufig widerlegt werden - das ist unbelegte POV und mMn unrichtig. Google liefert immerhin 8,4 Mio Treffer bei "depth inheritance tree" - alle die ich bisher gelesen habe nennen entweder keine Zahlen und sagen nur "weniger ist besser" oder nennen Zahlen zwischen 4 und 6 ohne auf Gesamt vs. pro Schicht einzugenen - ich kann da gerne noch weitere Aussagen mit Zahlen suchen.

Vorschlag zur Gestaltung des Satzes: "In der Literatur werden als empfohlene Obergrenzen der Tiefe einer Vererbungshierarchie Zahlen von 4 bis 6 genannt. (ref) Eine Beschränkung auf derartige Tiefen ist in der Praxis jedoch umstritten. (ref)". Ich hoffe für das zweite ref findet sich auch was. Was meint ihr? --Sebastian.Dietrich ✉ 18:58, 4. Aug. 2012 (CEST)

Wie oben schon angesprochen, dürfte es schwierig sein, eine Quelle zu finden die dieser These widerspricht, weil sich wohl kaum jemand hinsetzt, um Bücher oder Fachartikel über Faustregeln zu verfassen, die er selbst für Unsinn hält. Widersprechende Praxisbeispiel gibt es jedoch zu Hauf: In ActionScript3 z.B. gehört die wichtigste Anzeigeklasse Sprite (auf der jeder Entwickler seine eigenen Anzeigeklassen aufbaut) bereits zur 6. Vererbungsgeneration. Und wenn man wie Flex einsetzt, gehört dort eine Standard-Komponente wie z.B. spark.components.Image zur 10. Vererbungsgeneration – ohne dass eine einzige dieser Klassen selbst entwickelt worden wäre.

Ehrlich gesagt, fällt es mir immer schwerer zu glauben, dass sich diese Faustregeln tatschlich auf die gesamte Vererbungstiefe beziehen?! Falls aber (wie ich vermute) nur die Vererbungshierarchie innerhalb eines Moduls bzw. einer Programmschicht gemeint sind, muss das unbedingt dazugeschrieben, weil die Information sonst unvollständig, irreführen oder schlicht falsch ist.

Hast Du eigentlich die angebenen Quellen vorliegen, so dass Du uns mal den größeren Sinnzusammenhang zitieren könntest? --Martin Kraft (Diskussion) 22:18, 4. Aug. 2012 (CEST)

Wie die meisten QS Metriken hat DIT (depth of inheritance tree) positiven/negativen Einfluss auf einige Eigenschaften der Software. Bei DIT überwiegen die negativen, darum wird durch die Bank vor hohem DIT gewarnt. Nimm z.B. die Klasse spark.components.Image - inkl. ererbter hat sie ca. 200 public Attribute ca. 140 Methoden und kann ca. 120 Events auslösen - ein Monster. Ich möchte so eine Klasse nicht verwenden müssen. Was haben sich die Entwickler nur dabei gedacht - sicher nicht "composition over inheritance" was jedem Entwickler seit Design Patterns ein Begriff sein sollte.

Du wirst sicher noch viele andere Praxisbeispiele finden - das heisst aber nicht, dass diese Metrik nicht existiert und es dafür keine Vorgaben gibt. Ich hab jetzt alle ca. 3200 Klassen der Java Klassenbibliothek durchgeschaut - da gibts nix > DIT 6, und die wenigen (ca. 10) sind allesamt Klassen, die man ausserhalb der Klassenbibliothek nicht verwenden kann. Das belegt nur dass man bei Java mehr auf gutes Design oder DIT geachtet hat als bei Flex, aber nicht, ob 4, 6, 10 oder 1000 empfohlen werden.

Es geht mir nicht darum ob 4, 6, 10 oder 1000 die richtigen Zahlen sind, sonder nur darum, dass die in der Literatur genannten Zahlen in der Wikipedia auch genannt werden. Bitte um Gründe warum diese Metrik inklusive in der Literatur genannte Zahlen NICHT in der WP genannt werden darf (und nicht POV oder irgendwelche Frameworks mit enorm tiefen Vererbungshierarchien).

Hier wie gewünscht die Zitate aus den Quellen plus ein paar mehr:

• Basili, Briand, Melo: "A Validation of Object-Oriented Design Metrics as Quality Indicators" [1] (das wurde nicht gelöscht, da hier keine konkreten Zahlen genannt wurden): Depth of Inheritance Tree of a class (DIT) was shown to be very significant (p = 0.0000) overall. As expected, the larger the DIT, the larger the probability of defect detection
• Arthur J. Riel OO Design Heuristics: Heuristic 5.5 - In practice, inheritance hierarchies should be no deeper than an average person can keep in his or her short-term memory. A popular value for this depth is six. - Several projects' developers used the "deeper is better" philosophy when designing their object-oriented systems, only to find implementors getting lost in their deep inheritance hierarchies (which, in the case studies, were between 12 and 17 levels in depth). These developers redesigned their systems to take a less refined collection of abstractions with inheritance hierarchies that were only five to seven levels in depth. All projects' developers found these depths to be better. Like the heuristic involving the width of containment hierarchies, the number six is widely regarded as the number of items the average person can keep in short-term memory.
• Steve McConnell: A Practical Handbook of Software Construction: Avoid deep inheritance trees - Object oriented programming provides a large number of techniques for managing complexity. But every powerful tool has its hazards, and some object oriented techniques have a tendency to increase complexity rather than reduce it. In his excellent book Object-Oriented Design Heuristics, Arthur Riel suggests limiting inheritance hierarchies to a maximum of six levels (1996). Riel bases his recommendation on the “magic number 7±2,” but I think that’s grossly optimistic. In my experience most people have trouble juggling more than two or three levels of inheritance in their brains at once. The “magic number 7±2” is probably better applied as a limit to the total number of subclasses of a base class rather than the number of levels in an inheritance tree. Deep inheritance trees have been found to be significantly associated with increased fault rates (Basili, Briand, and Melo 1996). Anyone who has ever tried to debug a complex inheritance hierarchy knows why. Deep inheritance trees increase complexity, which is exactly the opposite of what inheritance should be used to accomplish. Keep the primary technical mission in mind. Make sure you’re using inheritance to minimize complexity.
• Visual Studio hat dafür ein Warning - eingestellt auf DIT > 4 (http://msdn.microsoft.com/en-us/library/ms182213.aspx) --Sebastian.Dietrich ✉ 03:21, 5. Aug. 2012 (CEST)

Nochmals Vorschlag zur Gestaltung des Satzes: "In der Literatur werden als empfohlene Obergrenzen der Tiefe einer Vererbungshierarchie Zahlen von 4 bis 6 genannt. (ref) Eine Beschränkung auf derartige Tiefen ist in der Praxis jedoch umstritten.". mMn kann der zweite Satz ruhig auch ohne ref drinnen stehen bleiben - vielleicht findet sich aber ein Artikel darüber, dass Refactoring für DIT Reduzierung kontraproduktiv ist. Was meint ihr? --Sebastian.Dietrich ✉ 18:58, 4. Aug. 2012 (CEST)

Ich finde schön, dass Du die sachliche Ebene so gut wie nicht verlässt und um einen Kompromiss bemüht bist. Ich fürchte aber, ein wesentlich weiteren Kompromiss als diesen (Basili, Briand, Melo) zu machen, widerspricht meiner Überzeugung doch sehr.

Es wurden bereits viele Aspekte genannt, warum eine sinnvolle Tiefe der Vererbungshierarchie von zahlreichen Faktoren abhängt (noch nicht alle, denke ich). Die Nennung einer festen Zahl halte ich außerdem für verantwortungslos, da Wikipedia manchmal verkürzt und opportunistisch zitiert wird (siehe diese Beispiel zu Südtiroler Schutzhütten). Beim Stichwort "Kurzzeitgedächnis", das ich in einer der Quellen als Begründung aufgeschappt habe, fällt mir beispielsweise ein, dass es von entscheidender Bedeutung ist, wie klar die Semantik der Klassen ist (wie klar kann man aus dem Klassennamen ableiten, was die Klasse leistet?).

Ein wesentlicher unklarer Aspekt ist, wie Marin und PerfektesChaos aufzeigen, auf was sich diese Beschränkung eigentlich bezieht. Auf die gesamte Hierarchie halten wir für unmöglich. Auf was denn dann? Auf eine Schicht? Das wirft die Frage auf: Was ist eine Schicht? Dein .Net Beispiel lässt vermuten, dass Du diesen Aspekt bislang zu wenig betrachtet hast. Dort steht nämlich "This rule limits analysis to hierarchies in the same module.". Das heißt im selben Sourcefile. Das ist lächerlich, das macht ohnehin niemand. Das zeigt auch, dass das eine Placebo-Implementierung ist. (vermutlich um zu ermöglichen, dass das über die Auswahl des Entwicklungswerkzeugs entscheidende Management im Spreadsheet den Punkt "Unterstützt DIT" abhaken kann).

Mal unabhängig davon, dass solche Zahlen mMn unsinnig sind. Wenn man solche Zahlen nennen würde, müsste man auch erläutern, wie sie zu verstehen sind und wie man zu ihnen kommt. Dort scheinen mir auch die Quellen nicht ganz einig, das sprengt den Rahmen sicherlich, darüber müsste man Bücher schreiben. Außerdem fallen mir folgende offene Fragen ein:

• bezieht sich die Aussage auf die komplette Vererbungshierarchie oder auf "Schichten" (s.o.)?
• Programmiersprache?
• Mehrfachvererbung?
• Unterschieden von Schnittstellen- und Implementierungsvererbung?
• Object dabei oder nicht? Ist das Limit bei Sprachen mit/ohne Object unterschiedlich?

--Cactus26 (Diskussion) 08:47, 6. Aug. 2012 (CEST)

Ich gebe Dir in allen Punkten recht: DIT ist nicht eindeutig definiert (bzw. überall unterschiedlich eindeutig definiert). All die offenen Fragen sind tatsächlich offen (bis auf mMn 2): DIT ist (wie alle anderen Komplexitätsmetriken auch) programmiersprachenunabhängig und auf den Gesamtcode meiner Applikation/Library/Framework beschränkt (egal wie die externen Frameworks/Libraries aussehen & egal wieviele Module/Schichten sie hat). D.h. Ableitung einer API-Klasse egal welches DITs = immer DIT 2.

Meiner Erfahrung nach interessiert das Management solche Zahlen überhaupt nicht. Solange die Features abgenommen werden ist die technische Qualität & Wartbarkeit eine Eigenschaft die man in der Managementebene nicht überprüfen möchte. Solche Zahlen werden ausschliesslich von einigen wenigen Entwicklern verwendet um zu wissen wo ihr Code Schwachstellen hat.

Genau diese Leute brauchen aber Zahlen an denen sie sich orientieren können. Bei anderen Metriken ist auch nicht exakt definiert wie genau sie zu berechnen sind. z.B. Lines of Code mit/ohne Kommentar/Leerzeilen oder sogar Anzahl Statements. Dennoch halten sich Millionen von Entwicklern an LOC Metriken und wissen dass z.B. Methoden mit 100 LOC kaum wartbar sind.

Ohne Zahlen sind alle Aussagen wie "weniger ist besser als mehr" irrelevant weil 20 ist auch besser als 30. Man kann ja zu der Metrik (genauso wie bei LOC) dazuschreiben, dass es Unterschiede bei ihrer Errechnung gibt. --Sebastian.Dietrich ✉ 09:23, 6. Aug. 2012 (CEST)

Das Interesse des "Management" (welches) würde ich als Argument nicht heranziehen. Oftmals besteht außer an der (schnellen) Abnahme und den damit verbundenen Margen keinerlei Interesse an der Art und Weise einer Umsetzung eines Softwareprojektes. --84.137.75.155 12:51, 12. Aug. 2012 (CEST)

3M Sofern einschlägige Literatur Tiefenbeschränkungen empfiehlt kann diese auch genannt werden. Wenn diese Beschränkungen kontraproduktiv sind und entsprechende einschlägige Literatur zu diesem standpunkt existiert, kann dies ebenfalls erwähnt werden. --84.137.75.155 12:35, 12. Aug. 2012 (CEST)

Wie oben beschrieben..

• ist zum Einen nicht klar, worauf sich die in der "einschlägigen Literatur" genannte Tiefenbeschränkung bezieht (gesamte Vererbungstiefe, Vererbung innerhalb einer Softwareschicht/eines Moduls).
• und zum Anderen ist es IMHO die Aufgabe des Erstellers, eine solche Hypothese nicht nur aufzustellen, sondern auch für ihren Beweis zu sorgen. Widerlegungen/Gegenbeweise wird es ja nur dann geben, wenn die These überhaupt als relvant betrachtet wird.

Vielleicht sollte man deshalb im Sinne von Wikipedia:Keine_Theoriefindung die Aufführung von Sekundärliteratur fordern. Also von Quellen, die nicht ihrerseits irgendwelche Metriken in den Raum stellen, sondern die dazu vorhanden Hypothesen sichten, analysieren, einordnen und ggf. veri- oder fazifizieren?! --Martin Kraft (Diskussion) 13:38, 12. Aug. 2012 (CEST)

Das letztere "im Sinne von Wikipedia:Keine_Theoriefindung die Aufführung von Sekundärliteratur fordern" hatte ich im Sinn.

Dann wär's wohl an denen, die gerne diese Tiefenbeschränkungen in den Artikel aufnehmen möchten, mal nach Sekundärliteratur zu forschen, die sich mit diesem Thema beschäftigt ;) -Martin Kraft (Diskussion) 21:50, 12. Aug. 2012 (CEST)

--84.137.78.122 21:34, 12. Aug. 2012 (CEST)

Ich denke wir reden von unterschiedlichen Dingen. Du redest davon, dass du für eine Aussage wie "Vererbungshierarchien müssen auf X beschränkt werden" Sekundärliteratur benötigst. Dieser Satz steht aber gar nicht zur Diskussion. Es geht um den Satz "In der Literatur werden als empfohlene Obergrenzen der Tiefe einer Vererbungshierarchie Zahlen von 4 bis 6 genannt." Also nicht um eine Theorie, sondern um eine Tatsache. Die ist belegt durch die 2 Literaturangaben. WP:TF ist hier gar nicht das Thema. --Sebastian.Dietrich ✉ 22:27, 12. Aug. 2012 (CEST)

Nimm z.B. den Satz "Folgende Anwendungskontexte (für Vererbung) werden empfohlen oder tauchen in der Praxis auf:[4][5]" in Vererbung_(Programmierung)#Anwendungen_der_Vererbung. Niemand spricht hier von WP:TF weil es ebenso wie oben keine Theorie, sondern eine Tatsache ist, dass diese Anwendungskontexte empfohlen werden. --Sebastian.Dietrich ✉ 22:35, 12. Aug. 2012 (CEST)

Der entscheidende Punkt ist mMn nicht, ob hier nun OR vorliegt oder nicht. Formal läge mMn bei Nennung einer Zahl kein OR vor, da es ja tats. einige Quellen gibt, wie Sebastian demonstriert hat, die so etwas verbreiten. Die entscheidenden Punkte sind mMn folgende:

• die Quellen widersprechen sich
• es nicht klar, auf was sich diese Zahlen beziehen (s.o. Schicht, Sprache etc,)
• ohne die Begründung, wie man zu den Zahlen kommt (z.B. "Kurzzeitgedächtnis") und einer Erläuterung, wie sie zu verstehen sind, sind sie unbrauchbar (s.o., "opportunistisches Zitieren")

Die Nennung der Zahlen würde also zusätzliche ausführliche Erläuterungen erfordern. Dies würde mMn doch ein wenig gegen WP:WWNI, Punkt 9 verstoßen (kein Ratgeber). Auch der Artikel Lines of Code nennt keine Zahl für die "sinnvolle" Zeilenzahl einer Methode/Prozedur (was ich richtig finde, da hier das gleiche Problem vorläge). Mein Kompromissvorschlag wäre folgender: Solche Zahlen können in einem auszubachenden Artikel Softwaremetrik (oder ggf. auch anderes verwandtes Lemma) genannt werden. Dort hätte man den Vorteil, dass man die erforderliche ausführliche "Gebrauchsanleitung" nur einmal machen müsste, auch bei der Widersprüchlichkeit ließen sich vielleicht Synergieeffekte erzielen. Im Gegenzug bleiben die Artikel zu den Sprachelemeten dafür "metrikfrei".--Cactus26 (Diskussion)

Vorschlag finde ich prinzipiell gut. Meine Befürchtung ist nur, dass das dann eher zu einer "Liste von Softwaremetriken" ausartet und hunderte Metriken ohne Berechnung, Widersprüchlichkeit etc. einfach nur gelistet werden. Aber mit einem geeigneten Lemma wär das ganze sicher machbar. Allein - mir fällt kein Lemma ein unter dem man all die Qualitäts-Produkt-Metriken von Software vereinen könnte --Sebastian.Dietrich ✉ 22:18, 15. Aug. 2012 (CEST)

Lemma

Vererbung ist kein Konzept der Programmierung, auch nicht der objektorientierten Programmierung, sondern der Objektorientierung. Vererbung wird in (objektorientierter) Analyse, Design und Test genauso verwendet wie bei der Programmierung. Vorschlag: Lemma in Vererbung (Objektorientierung) umzubenennen. Diskussion darüber bitte unter Wikipedia:Redaktion Informatik/Qualitätssicherung#Schnittstelle (Programmierung) --Sebastian.Dietrich ✉ 16:16, 9. Sep. 2012 (CEST)

Nichts dagegen, im Gegenteil, ich halte Vererbung (Objektorientierung) für das klar bessere Lemma. Als ich begann mich mit dem Artikel zu befassen, war das Lemma schon Vererbung (Programmierung), mir gefiel das zwar nicht so sehr, aber ich fand es nicht so wichtig. Aber bei Schnittstelle ist die Sachlage mMn deutlich anders und alles andere als klar.--Cactus26 (Diskussion) 14:12, 10. Sep. 2012 (CEST)

Auffälliges, 2014-05-28

1. , wobei die Beziehung zwischen ursprünglicher und neuer Klasse dauerhaft ist — Ist an der Stelle noch unverständlich, dazu noch vager Begriff Beziehung.

2. Eine neue Klasse kann dabei eine Erweiterung oder eine Einschränkung der ursprünglichen Klasse sein. — gegen Liskov?

3. Neben diesem konstruktiven Aspekt dient Vererbung auch der Dokumentation von Ähnlichkeiten zwischen Klassen, was insbesondere in den frühen Phasen des Softwareentwurfs von Bedeutung ist. — Dokumentation ist missverständlich wegen Softwaredokumentation, was eine ganz enge andere Bedeutung hat, die auch noch ziemlich bekannt sein dürfte.

Außerdem ist es doch eher so: Klassen mit Ähnlichkeiten, also sachlich zusammengehörige Klassen werden in einer Klassenhierarchie nahe zusammen eingeordnet, eine Hierarchie, die dann im Nachhinein ihre Ähnlichkeit ganz natürlich auch dokumentiert. In der frühen Phase ist aber dieses sachliche Zusammenführen das Wichtige und nicht das spätere Zusammenzeigen.

4. die Umkehrung hiervon Generalisierung, was ein vorwiegend auf die Modellebene beschränkter Begriff ist. — Vage durch Kombination vor relativierendem und scharfem Begriff. Welcher Laie versteht Modellebene? Und stimmt das überhaupt? Man kann schließlich auch ohne jede Nutzung von formalen Modellierungsmethoden sinnvoll diskutieren, ob nicht bestimmte Klassen sozusagen unter einen Hut kommen sollten.

5. In der Unified Modeling Language (UML) wird eine Vererbungsbeziehung durch einen Pfeil mit einer dreieckigen Spitze dargestellt, der von der abgeleiteten Klasse zur Basisklasse zeigt. Geerbte Attribute und Methoden werden in der Darstellung der abgeleiteten Klasse nicht wiederholt. — Details, hier zu früh, da erst die Begriffserklärung ansteht und noch nicht der technische Blick auf ein Werkzeug.

6. Abgeleitete Klasse und Basisklasse stehen typischerweise in einer „ist-ein“-Beziehung zueinander. – Is-a übersetzt, das nennt man den schon Kundigen Erläuterung bringen. Vielleicht ungefähr so: Wenn die Basisklasse sozusagen eine Gattung von Objekten bestimmt, so die abgeleitete Klasse eine Untergattung davon.

7. 6-mal eigentlich im Artikeltext. Ein unschönes Beispiel:

Es gibt auch Verwendungen der Vererbung, die nicht als sinnvoll angesehen werden. Beispielsweise dürften für eine Klasse Person die Spezialisierungen WeiblichePerson und MännlichePerson in den wenigsten Fällen zweckmäßig sein und bei der Modellierung der eigentlich relevanten Aspekte eher behindern.

für offenbar überschießende Relativierung. Besser knapper und bestimmter, à la:

Zuviel an Vererbung kann auch schaden. Eine Klasse Person etwa auf Unterklassen WeiblichePerson und MännlichePerson zu spezialisieren, ist meist unnütz. Der Aufwand hierfür stört dann nur die Modellierung wichtigerer Aspekte.

--Silvicola ^Disk 02:42, 28. Mai 2014 (CEST)

Verständnisfrage

Für mich als Nichtprogrammierer tauchte beim ersten Beispiel eine Verständnisfrage auf. Ist ein Navigationssystem nicht eher ein Attribut als eine Methode? --UlliW (Diskussion) 09:18, 28. Mai 2014 (CEST)

HatNavigationssystem ist hier eine triviale Methode mit booleschem Rückgabewert: ja (es hat eines) / nein (es hat keines).

Für die wirkliche Nutzung des Navigationssystems per Software gäbe es dann andere Methoden. Entweder in einer Klasse für Navigationssysteme – dann bräuchte die Klasse Kraftfahrzeug noch eine Methode sagen wir GibNavigationssystem, mit der man ggf. ein Softwareobjekt einer Klasse, die eingebaute Navigationssysteme repräsentiert, abfragen kann, um dann dieses wiederum sagen wir mit Starte, SprichLauter, Beende usw. zu nutzen – oder diese Methoden sind in der Klasse Kraftfahrzeug selbst angelegt und leiten dann letztlich auch auf solche fremden Methoden durch.

Dass HatNavigationssystem nicht einfach nur ein Attribut ist, sondern als boolesche Methode angelegt, ist wohl eine Vorsichtsmaßregel mit Hinblick auf ein technisches Manko vieler Programmiersprachen, daran fehlt es meist. Hinter einer Methode von Kraftfahrzeug kann man, von außen gesehen, problemlos umbauen, ohne dass also Klassen, die Kraftfahrzeug nutzen, selbst neu angepasst oder auch nur kompiliert werden müssten. Aber mit der Zeit könnte HatNavigationssystem komplizierter werden und nicht mehr als einfaches Attribut zu realisieren, sondern Logik brauchen, und dann ist die Hölle los.

Man stelle sich vor, eines Tages gibt es Multifunktionsgeräte für Autos, die als Teil auch ein Navigationssystem enthalten. Dann gibt es die Konstellation, dass ein Kraftfahrzeug selbst unmittelbar kein Navigationssystem besitzt, aber indirekt über ein eingebautes Multifunktionsgerät eines nutzen kann. Die Abfrage auf Nutzbarkeit eines Navigationssystems, die mit HatNavigationssystem eigentlich gemeint ist, kann man, wenn das eine Methode ist, in der leicht korrigieren, indem man in ihr einfach eine Weiche einbaut: Wenn das Kfz selber eines hat, dann ja, sonst wenn es ein Multifunktionsgerät hat, dann dessen Abfrageergebnis nehmen. Diese Änderung kann man strikt lokal in Kraftfahrzeug vornehmen, ohne Auswirkung auf Nutzungsklassen. Im Attributfall müsste man aber in diesen, und das können viele sein, die Attributnutzung auf die Nutzung der neu dieses ersetzenden Methode umstellen, nachdem man sie in Kraftfahrzeug nachgerüstet hat. Die neue Klasse Kraftfahrzeug bricht dann ihren alten Vertrag, man kann nach der Änderung nämlich (tunlichst!) ein altes Attribut nicht mehr abfragen, das heißt für die Programmierer aller nutzenden Klassen Zwangsarbeit zur Anpassung.

Das führt natürlich vom Thema hier zu weit ab.

--Silvicola ^Disk 14:01, 28. Mai 2014 (CEST)

Beispiel: Ein Quadrat ist ein spezielles Rechteck?

Ich finde es nicht gut, dass initial gleich ein Beispiel gezeigt wird, welches das Liskovsches Substitutionsprinzip verletzt. Das kann dazu führen, dass sich gerade Anfänger dieses Beispiel zum Vorbild nehmen (auch wenn im folgenden Text dazu steht, das diese Implementierung oft ungünstig ist).

Aus meiner Sicht wäre es analog zum Kreis-Ellipse-Problem besser, gleich die programmiertechnisch "richtige" Definition als Beispiel im UML-Diagramm zu zeigen: Ein Rechteck ist ein spezielles Quadrat, dessen Seiten unterschiedlich lang sind.

--178.212.255.2 16:38, 28. Mai 2014 (CEST)

Irreführende Einleitung

Die Einleitung "Die Vererbung (englisch inheritance)" ist nicht ganz korrekt. "To inherit" heißt nicht "vererben", sondern "erben". Vielleicht sollte man darauf hinweisen, daß es sich hier nicht um die englische Übersetzung des deutschen Wortes handelt, sondern daß im Englischen das Gegenteil verwendet wird. (nicht signierter Beitrag von 188.98.78.193 (Diskussion) 16:44, 28. Mai 2014 (CEST))

Das OOP-Konzept Vererbung heisst im Englischen inheritance, das ist Fakt und korrekt. Es würde etwas zu weit führen, in der Einleitung eine sprachübergreifende linguisitsche Unterscheidung der Aktiv-/Passiv-Begrifflichkeiten zu führen. Gruß --Cvf-ps^Disk_+/− 23:01, 28. Mai 2014 (CEST)