Vererbung und Klassenhierarchien

[Wikinger75]

Hallo Leute.
Ich habe jeweils eine oder auch mehrere Fragen zur Vererbung und Klassenhierarchie. Ich fasse mich einfach mal kurz und liste auf.

- Wann machen Vererbungen Sinn?
- Wann entsteht eine Hierarchie wie bsp. in den C++-Streams aus der std?
- Wann sollte man eine Bibliothek oder gar ein Framework bauen? Also Gründe dafür.
- Was sollte man beim Bau eigener Bibliotheken oder gar Frameworks beachten? (Das Einzigste was mir einfällt und was ich nicht machen würde sind gigantisch große DLL's wie bei wxWidgets, usw.)

Ich weiß, dass eine Klasse möglichst klein sein sollte und nur ihren zweck erfüllen sollte, da Monsterklassen meist sowieso zu nicht viel führen, was aber genau an diesen auszusetzen ist, wüste ich auch nicht. Ebenso merke ich, dass bei kleineren Klassen die Vererbung mehr Sinn macht, wegen der Erweiterung, da man nicht alles neu schreiben muss, sondern übernehmen kann. Gehört zwar nicht direkt zum Thema, aber ist mir grade so eingefallen ;).

Mfg Wikinger75!

[drakon]

Wikinger75 schrieb:

[list]- Wann machen Vererbungen Sinn?

Man kann solche Fragen nicht so generell beantwroten. Vor allem nicht, wenn du sie sprachübergreifend anschaust. In Java wird z.B viel eher vererbt, als bei C++.
Grundsätzlich ist es sinnvoll (öffentliche) Vererbung zu benutzen, wenn man eine ist-ein Beziehung ausdrücken und ggf. das auch durch Polymorphie nutzen möchte. Mann kann sie auch benutzen, wenn man die Wartbarkeit von ähnlichem Code erhöen möchte. Allerdings erhöt das auch die Abhängigkeiten. Ob Vererbung wirklich Sinn macht muss man denke ich oft im Einzelfall entscheiden.

- Wann entsteht eine Hierarchie wie bsp. in den C++-Streams aus der std?

Wenn man Vererbung einsetzt?! - Verstehe denke ich die Frage nicht ganz.

- Wann sollte man eine Bibliothek oder gar ein Framework bauen? Also Gründe dafür.

Wenn du gewisse Module erstellen kannst, welche du in mehreren Projekten benutzen kannst (oder dir zumindest vorstellen kannst, dass du das einmal tun wirst).

- Was sollte man beim Bau eigener Bibliotheken oder gar Frameworks beachten? (Das Einzigste was mir einfällt und was ich nicht machen würde sind gigantisch große DLL's wie bei wxWidgets, usw.)

Modularität ist denke ich ganz wichtig. Also biete Teile, welche nicht zusammengehören nicht gemeinsam an. Allerdings ist es schwer zu sagen, in wiefern du da etwas trennen kannst. Z.B ist ja die Standardbibliothek auch in gewissen Teilen unabhängig. Du kannst da ja lediglich einen Header benutzen ohne jeglichen anderen Overhead (je nachdem, was die Datei sonst noch so braucht).

Ich weiß, dass eine Klasse möglichst klein sein sollte und nur ihren zweck erfüllen sollte, da Monsterklassen meist sowieso zu nicht viel führen, was aber genau an diesen auszusetzen ist, wüste ich auch nicht. Ebenso merke ich, dass bei kleineren Klassen die Vererbung mehr Sinn macht, wegen der Erweiterung, da man nicht alles neu schreiben muss, sondern übernehmen kann. Gehört zwar nicht direkt zum Thema, aber ist mir grade so eingefallen ;).

Mfg Wikinger75!

Monsterklassen sind in dem Sinne nicht gut, weil sie die logische Trennung, welche durch OOP vermittelt werden möchte zunichte macht. Stell dir vor du treibst es ganz wild und machst eine main Klasse, wo alles drin steht (alle Funktionen und alle Datenobjekte). Toll da hast du nix draus gewonnen.

Man sagt, dass eine Klasse eine Aufgabe haben sollte. Klar kann man das nicht immer perfekt umsetzen, aber prinzipiell sollten verschiedene Anwendungsgebiete getrennt werden.

[fr33g]

Wikinger75 schrieb:

- Wann machen Vererbungen Sinn?

Ganz einfach, sobald eine ist-ein-Beziehung eintrifft.
Dies ist zumindest der Fall bei public Vererbung.
Ich finde es macht Sinn, wenn du jetzt zum Beispiel ne allgemeien Klasse hast wie Fahrzeug. Kurz gesagt ein Fahrzeug kann sich fortbewegen.
Dann gibts zum Beispiel Auto, dass kann auf der Straße fahren, Flugzeug kann fliegen und und und....
Wird aber normal auch in jedem guten C++ Einsteigerbuch erklärt;-)

Wikinger75 schrieb:

- Wann entsteht eine Hierarchie wie bsp. in den C++-Streams aus der std?

Was genau meinst du??? Verstehe ich grade nicht. Std ist ja ein Namespace.
Also sieht man ja so eine hierarchie wie bei den C++ Streams entsteht eben wenn man viele Klassen hat, die eben ziehmlich Abstrakt anfangen und immer spezialisierter werden.
Sieht man ja, die ganze Qt-Bibliothek ist ja so ne Hierarchie.

Wikinger75 schrieb:

Wann sollte man eine Bibliothek oder gar ein Framework bauen? Also Gründe dafür.

Ist jetzt nicht böse gemeint, würde mir das gleiche empfehlen, aber ich glaube noch lange nicht, da es für das was du jetzt kannst( vermute ich einfach mal von den fragen her ) bisher ja genug bibliotheken gib wie boost Qt und und und...
Ne aber allgemein gesagt würde ich sagen, wenn du jetzt zum Beispiel in ner Firma arbeitest und etwas sehr oft benötigt wird, dann kann man dafür ja ne Bibliothek erstellen, die dann jeder nutzen kann.

Ich hoffe ich konnte dir etwas helfen;-)

Gruß freeG

EDIT:
Neeeiiin ich war mal wieder zu langsam:D hab ich doch tatsächlich 7 Minuten gebraucht um diesen Post zu erstellen

[volkard]

fr33g schrieb:

Wikinger75 schrieb:

- Wann machen Vererbungen Sinn?

Ganz einfach, sobald eine ist-ein-Beziehung eintrifft.

Dazu zwei Beispiele aus realen Lehrbüchern:

class BubbleSort:public Sortierverfahren
Wertung: Jetzt bin ich ein trauriges Programmierbärchen. Zum Vererben brauchts irgendwie Objekte. Jedes Bubbelsort-Objekt ist ein Sortierverfahren-Objekt. Und Funktionen sind auch keine guten Kanditaten, um daraus Klassen zu machen. Alles unrund.

class Papabär: public Bär
Wertung: Selten so gelacht. Klar ist ein Papabär ein Bär, aber soll ein Bär seine Klassenzugehörigkeit ändern, wenn er Kinder kriegt? Die hier betrachteten Sprachen machen das nicht mit.

class Kreis: public Punkt
Wertung: Außerhalb jeder Diskussion, weil keine IST-EIN-Beziehung vorliegt.

[fr33g]

Ja gut der Satz war zu pauschal gesagt, aber drunter hab ich ja auch ein kleines Beispiel gemacht;-)

[l'abra d'or]

volkard schrieb:

class Papabär: public Bär
Wertung: Selten so gelacht. Klar ist ein Papabär ein Bär, aber soll ein Bär seine Klassenzugehörigkeit ändern, wenn er Kinder kriegt? Die hier betrachteten Sprachen machen das nicht mit.

Ist das Selbe wie
class Maserati : public Auto
Die "Ist-Ein"-Beziehung bezieht sich hier eher auf "Maserati ist ein Auto-Objekt" und sollte nicht über Vererbung sondern Instantiierung gelöst werden.
Auto* maserati = new Auto;
Baer* papaBaer = new Baer;
usw.

[SeppJ]

l'abra d'or schrieb:

volkard schrieb:

class Papabär: public Bär
Wertung: Selten so gelacht. Klar ist ein Papabär ein Bär, aber soll ein Bär seine Klassenzugehörigkeit ändern, wenn er Kinder kriegt? Die hier betrachteten Sprachen machen das nicht mit.

Ist das Selbe wie
class Maserati : public Auto
Die "Ist-Ein"-Beziehung bezieht sich hier eher auf "Maserati ist ein Auto-Objekt" und sollte nicht über Vererbung sondern Instantiierung gelöst werden.
Auto* maserati = new Auto;
Baer* papaBaer = new Baer;
usw.

Ein Maserati ist aber immer ein Auto und immer ein Maserati. Von daher passt public-Vererbung beim Maserati schon. Dem Papabaer-Beispiel würde eher einer Klassenhierarchie Fahrendes_Auto: public Auto und Stehendes_Auto: public Auto entsprechen. Hier hat man zwar formal eine ist ein Beziehung, trotzdem ist dies aus den von Volkard genannten Gründen ein schlechtes Design, weil die Geschwindigkeit eines Autos oder die Kinderzahl eines Bären Eigenschaften(sprich: Member) dieser Klassen sind und keine neuen unveränderlichen Klassen für sich selbst bilden.

[l'abra d'or]

Und welche Eigenschaften kommen bei einem Maserati speziell hinzu, die ein Auto nicht hat, und die sich auch nicht hinter den zukaufbaren Extras die ein normales Auto bietet (MP3-CD-Wechsler, Xenon-Scheinwerfer, getönte Scheiben, 500PS-Motor, ...) verstecken?
Ich denke das einzige was einen Maserati von einem anderen Auto unterscheidet ist dessen Produktion. Die Produktion eines Baer-Objektes hingegen läuft immer gleich ab Und der Zufall entscheidet, ob dabei ein PapaBaer, MamaBaer, oder vllt. sogar ein PapaMamaBaer entsteht.

// edit:
Ich will dir nicht widersprechen, eher zeigen, dass es nicht immer leicht ist zu entscheiden, ob man Vererbung BRAUCHT oder eben nicht. Wenn für eine Anwendung entscheidend ist, einen Maserati speziell anzusprechen, weil dessen spezielle Eigenschaften benötigt werden (k.A. wann, vllt. bei einer Autorennsimulation), dann macht es vllt. Sinn Maserati eine eigene Klasse zu geben.
Der übliche Hintergedanke "programmieren sie eine Autoverwaltung" rechtfertigt eine eigene Klasse "Maserati" nicht, da man beliebig Autos hinzufügen können muss und da Marke und Modell nur Eigenschaften sind. Wenn das Hinzufügen einer neuen Marke nur über einen Patch des Entwicklers möglich ist, gute Nacht

[SeppJ]

l'abra d'or schrieb:

Und welche Eigenschaften kommen bei einem Maserati speziell hinzu, die ein Auto nicht hat, und die sich auch nicht hinter den zukaufbaren Extras die ein normales Auto bietet (MP3-CD-Wechsler, Xenon-Scheinwerfer, getönte Scheiben, 500PS-Motor, ...) verstecken?
Ich denke das einzige was einen Maserati von einem anderen Auto unterscheidet ist dessen Produktion. Die Produktion eines Baer-Objektes hingegen läuft immer gleich ab Und der Zufall entscheidet, ob dabei ein PapaBaer, MamaBaer, oder vllt. sogar ein PapaMamaBaer entsteht.

Du kannst aus einem anderen Auto keinen Maserati machen, egal wieviel du zukaufst. Und du kannst einem Maserati auch nicht die Eigenschaft nehmen, ein Maserati zu sein, egal wieviel du an dem Auto veränderst. Und diese Eigenschaft ist entscheidend, warum Maserati eine eigene Klasse von Auto ist, aber Papabär keine Unterklasse von Bär.

Und zu deiner Frage: Willst du wirklich erklärt haben, woran man Automarken unterscheidet? Kleiner Tipp: Es ist nicht das Zubehör...

[SeppJ]

Jetzt hast du editiert, während ich geantwortet habe.

l'abra d'or schrieb:

// edit:
Ich will dir nicht widersprechen, eher zeigen, dass es nicht immer leicht ist zu entscheiden, ob man Vererbung BRAUCHT oder eben nicht. Wenn für eine Anwendung entscheidend ist, einen Maserati speziell anzusprechen, weil dessen spezielle Eigenschaften benötigt werden (k.A. wann, vllt. bei einer Autorennsimulation), dann macht es vllt. Sinn Maserati eine eigene Klasse zu geben.
Der übliche Hintergedanke "programmieren sie eine Autoverwaltung" rechtfertigt eine eigene Klasse "Maserati" nicht, da man beliebig Autos hinzufügen können muss und da Marke und Modell nur Eigenschaften sind. Wenn das Hinzufügen einer neuen Marke nur über einen Patch des Entwicklers möglich ist, gute Nacht

Da haste Recht, das ist dann eine Frage des Designs, ob man was braucht und was man nicht braucht. Wie du selbst erkannt hast, kommt das auf den speziellen Anwendungsfall an. Trotzdem gibt es sinnvolles und weniger sinnvolles Design: Die Aufspaltung der Klasse Auto in einzelne Modelle ist, wie du schon gesagt hast, selten sinnvoll, da die in der Praxis interessanten Eigenschaften allen Autos gemeinsam sind (Autos sind nun einmal primär Gebrauchsgegenstände und alle für den gleichen Zweck gefertigt). Vielleicht sollte man die Diskussion daher auf ein kontroverseres Themengebiet (geometrische Figuren?) verlagern. Aber da wir glaube ich sowieso einer Meinung sind, gibt es auch gar nichts zu diskutieren.

[Wikinger75]

Gut. Danke Leute.
War mir bei vielen Sachen unsicher, doch das Meiste hab ich mir schon richtig vorgestellt.

Wird aber normal auch in jedem guten C++ Einsteigerbuch erklärt;-)

Das wars auch, doch ich war noch bisl. unsicher

Ist jetzt nicht böse gemeint, würde mir das gleiche empfehlen, aber ich glaube noch lange nicht, da es für das was du jetzt kannst( vermute ich einfach mal von den fragen her ) bisher ja genug bibliotheken gib wie boost Qt und und und...
Ne aber allgemein gesagt würde ich sagen, wenn du jetzt zum Beispiel in ner Firma arbeitest und etwas sehr oft benötigt wird, dann kann man dafür ja ne Bibliothek erstellen, die dann jeder nutzen kann.

meine C++ Kenntnisse sind durchaus Stabil genug, doch ich konnte mir nie wirklich eine sinnvolle Anwendung für die OOP vorstellen.

Man sagt, dass eine Klasse eine Aufgabe haben sollte. Klar kann man das nicht immer perfekt umsetzen, aber prinzipiell sollten verschiedene Anwendungsgebiete getrennt werden.

Das muss ich mir merken :D.

Mfg Wikinger75

[l'abra d'or]

fr33g schrieb:

Wikinger75 schrieb:

Wann sollte man eine Bibliothek oder gar ein Framework bauen? Also Gründe dafür.

Ist jetzt nicht böse gemeint, würde mir das gleiche empfehlen, aber ich glaube noch lange nicht, da es für das was du jetzt kannst( vermute ich einfach mal von den fragen her ) bisher ja genug bibliotheken gib wie boost Qt und und und...
Ne aber allgemein gesagt würde ich sagen, wenn du jetzt zum Beispiel in ner Firma arbeitest und etwas sehr oft benötigt wird, dann kann man dafür ja ne Bibliothek erstellen, die dann jeder nutzen kann.

Ich arbeite jetzt in keiner Firma, versuch aber trotzdem immer Komponenten in einem Projekt, die anderweitig nützlich sein können im Projekt "fassbar" auszugliedern, sprich das kommt in ein eigenes Verzeichnis. Wenn das wächst, wird es als shared library gelinkt und irgendwann (wenn es sich als stabil und nützlich erweist) separat weiterentwickelt.

Ein Framework hast du übrigens schon, wenn du mehrere Klassen hast, die in ihrer Abhängigkeit verwoben sind, also einzeln keinen Sinn machen und so auch nicht funktionieren. Sowas hat man schnell :p

[Nexus]

l'abra d'or schrieb:

Ich arbeite jetzt in keiner Firma, versuch aber trotzdem immer Komponenten in einem Projekt, die anderweitig nützlich sein können im Projekt "fassbar" auszugliedern, sprich das kommt in ein eigenes Verzeichnis.

Geht mir genau gleich. Code-Wiederverwendung ist was Gutes, deshalb sollte man entsprechend generisch und sauber programmieren, falls man in Betracht zieht, eigene Klassen und Funktionen in weiteren Projekten einzusetzen.

[Dravere]

Nexus schrieb:

l'abra d'or schrieb:

Ich arbeite jetzt in keiner Firma, versuch aber trotzdem immer Komponenten in einem Projekt, die anderweitig nützlich sein können im Projekt "fassbar" auszugliedern, sprich das kommt in ein eigenes Verzeichnis.

Geht mir genau gleich. Code-Wiederverwendung ist was Gutes, deshalb sollte man entsprechend generisch und sauber programmieren, falls man in Betracht zieht, eigene Klassen und Funktionen in weiteren Projekten einzusetzen.

Abgesehen davon ist es eine gute Übung. Wie ging das schon wieder?
Was Fritzchen nicht lernt, lernt Fritz nimmer mehr.

Grüssli