Vererbungstiefe OOP

Grundsätzliche Frage zum Klassenaufbau/hierarchie:

In meinem Unternehmen gibts eine kaufmännische Software.
Die Verschachtelungstiefe einiger Klassen geht über 7 Ebenen.

A erbt von B von C von D ...erbt von G (BaseClass)

Ich habe gelesen und bin auch selber der Meinung, dass mit Vererbung
sparsam umgegangen werden sollte.

Auf der einen Seite werden die Klassen natürlich übersichtlicher, auf der anderen Seite
blickt man bei einer bestimmten Verschachtelungstiefe ja gar nicht mehr durch.

Wie seht ihr das. Bis zu welcher Tiefe schachtelt ihr. Setzt ihr Vererbung durchgängig ein oder verzichtet ihr an manchen Stellen darauf?

Vereben ja, aber nicht bis zum Exzess.
Wenn A von B ableitet, dann muss man immer den Satz "A ist B" widerspruchslos formulieren können. Ein üblich genanntes Beispiel: Du kanns einen Klasse Quadrat von Rechteck ableiten, da die Formulierung "Quadrat is ein Rechteck" Sinn macht. Wenn du jetzt aber denkst, Quader könntest man von Quadrat ableiten (ist ja irgendwie auch was qadratisches), so stimmt die Aussage "Quader ist ein Quadrat" nicht mehr.

In solchen Fällen gibt es andere Beziehungen, die durchaus mehr Sinn machen und wesentlich flexibler sind. In diesem Zusammenhang seien Design Patterns genannt. Eine recht gute Einführung findest du z.B. hier

Vielleicht kannst du mal namentlich deine 7 Klassen schreiben, daraus kann man eventuell schon was ableiten.

Hallo wickedcsharper

Grundsätzlich sollte die Vererbungstiefe so niedrig wie möglich gehalten werden.
Aber natürlich kann es mehr Sinn machen, zwei Vererbungsstufen zu haben, oder 3, als ein riesen Aufwand um das zu vermeiden, weil es eben die beste Lösung ist.

Aber für Vererbungen über 4, 5 Ebenen kann (sollte) man schon mal den Sinn hinterfragen.

Der Hintergrund ist:
Die Komplexität steigt, aber sie sinkt auch, vermeindlich.
Mit vermeindlich ist scheinbar gemeint und damit, das die Klassen die von einer anderen erben, ja schlanker und übersichtlicher aussehen.

Sind die aber nicht, wenn man alles über sie wissen will, sondern genau im Gegenteil: Von unübersichtlich bis zu unüberschaubar oder von so hoher Komplexität, das man es nicht mal mehr verstehen, geschweige denn erklären kann.

Beschäftige dich daneben noch mit Design Patterns.
Als mögliche Alternativen und in vielen Fällen besser, intuitiver als Vererbung, aber nicht immer, gibts: Aggregation, Komposition und das auf diverse Arten. Schau mal in die Richtung.

Gruss Peter

Hallo,

<- bedeutet hier erbt von

Rechnung <- RechnungBasis <- VorgangmitWarenkorb <- VorgangmitBetrag <- VorgangmitAdresse <- VorgangPrintable <- VorgangBase

sieht schon komisch aus.

Die Software hat 420 Zeilen Quellcode. Kann man hier überhaupt noch was verbessern?

Hallo wickedcsharper,

letztlich kommen wir hier zu dem gleichen Ergebnis wie in Querverbindungen zwischen Klassen - OOP, nämlich dass du dich erstmal selbst in OOP einlesen musst. Ein Buchvorschlag habe ich schon in dem anderen Thread gemacht.

Dass man weiß, dass Vererbung eine IST-EIN-Beziehung ist, rechte ich mal zu den absoluten Grundlagen.

Trotzdem noch kurz zur eigentlichen Frage: Die Anzahl der Vererbungsstufen ist in meinen Augen kein (vorrangiges) Kriterium. Wenn man Vererbung auf echte IST-EIN-Beziehungen beschränkt, dann wird auch die Vererbungstiefe ganz natürlich begrenzt. Anderseits ist PrintPreviewDialog auch auf der siebenten Vererbungsstufe, ohne dass dadurch etwas unübersichtlich ist, weil es eben überall echte, nachvollziehbare Spezialiserungen sind

System.Object
   System.MarshalByRefObject
     System.ComponentModel.Component
       System.Windows.Forms.Control
         System.Windows.Forms.ScrollableControl
           System.Windows.Forms.ContainerControl
             System.Windows.Forms.Form
              System.Windows.Forms.PrintPreviewDialog

herbivore