Unterklasse wenn nur Attribute geerbt werden?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
T.T. Kreischwurst
User
Beiträge: 52
Registriert: Dienstag 2. Februar 2016, 10:56

Hi Leute,

habe eine sehr allgemeine Frage zum Design: ist es schlechter Stil, eine Unterklasse zu einer Klasse zu erstellen, wenn die Unterklasse lediglich diverse Attribute der Oberklasse Erben soll, aber keine von deren Methoden benötigt?

Konkretes Beispiel: Ich will eine Tabelle aufbauen, in die Textitems per drag and Drop gezogen werden können. Dazu habe ich bisher eine Klasse "Tabelle", deren wie wichtigstes Attribut ein tkInter Canvas Objekt ist. Dann zwei weitere Klassen "Rechteck " und "Text", die Aktionen rund um den Tabellenaufbau und den Text vornehmen. Beide interagieren zwangsläufig sehr eng mit der Tabellenklasse, da z.B. die Rechtecke irgendwie auf die Canvas gemalt werden müssen (die Tabelle besteht aus lauter Rechtecken). Jetzt frage ich mich, ob es sauber wäre, diese beiden Klassen einfach die benötigten Attribute von Tabelle Erben zu lassen. Ansonsten müsste ich das Objekt herumreichen.
BlackJack

@T.T. Kreischwurst: Vererbung ist eine „ist-ein(e)“-Beziehung. Ist ein Rechteck eine Tabelle oder ist ein Text eine Tabelle? Ich würde sagen nein, eine Tabelle hat/enthält Rechtecke und Texte, das ist also Komposition oder Aggregation und keine Vererbung.

Zumal ich nicht sehe was Dir Vererbung in diesem Fall bringen soll. Du erbst ja von einer Klasse und nicht von einem konkreten Exemplar das bereits Attributwerte besitzt‽
T.T. Kreischwurst
User
Beiträge: 52
Registriert: Dienstag 2. Februar 2016, 10:56

OK, das leuchtet ein. Ich hatte auch Bedenken, denn eigtl. nutzt es nicht viel... Konkrete Werte würde ich in diesem Fall sogar erben können, da __Init__ von Tabelle Methoden aufruft, die einige Instanz-Attribute setzen.
__deets__
User
Beiträge: 14529
Registriert: Mittwoch 14. Oktober 2015, 14:29

Generell ist Komposition (hat-ein) der Vererbung (ist-ein) vorzuziehen. Das man dabei auch mal mehr Argumente an den Konstruktor uebergeben muss ist ein verschmerzbares Uebel, das mit besserer Testbarkeit und Kompositionierbarkeit belohnt wird.
T.T. Kreischwurst
User
Beiträge: 52
Registriert: Dienstag 2. Februar 2016, 10:56

__deets__ hat geschrieben:Generell ist Komposition (hat-ein) der Vererbung (ist-ein) vorzuziehen
Das finde ich interessant, denn es läuft eigtl. Dem entgegen, was man in der Literatur (für Anfänger) so liest. Da heißt es meistens (sinngemäß): Vererbung ist der Hammer. Nutze sie.
Ich fand das beim Entwerfen/überarbeiten meines aktuellen Projekts teils sehr schwer umzusetzen, was dann zu bisweilen komischen Konstrukten geführt hat.
BlackJack

@T.T. Kreischwurst: Das ist vielleicht ein Missverständnis. Vererbung *ist* der Hammer. Und man sollte sie auch nutzen. Halt nur dort wo sie Sinn macht, und nicht auf biegen und brechen überall Vererbungshierarchien sehen und umsetzen wollen. :-)
__deets__
User
Beiträge: 14529
Registriert: Mittwoch 14. Oktober 2015, 14:29

Vererbung ist nuetzlich. Aber gerade in Python zB weniger wichtig als in statisch typisierten Sprachen - Stichwort Ducktyping. Ich muss nicht von einer Basisklasse erben, um ein Objekt an einer Stelle einsetzen zu koennen, das eine Instanz einer andere Klasse erwartet. Liskov-Prinzip sollte natuerlich trotzdem gelten.
Antworten