basisklasse für nur eine klasse/ unübersichtlich viele scriptzeilen

[hgseib]

das ist das 'normale'
BasisTier
TierHund extend BasisTier
TierKatz extend BasisTier
eine basisclasse beinhaltet die gemeinsamkeiten für unterschiedliche klassen

manche klassen wachsen einfach ins unermessliche (unübersichtlich viele scriptzeilen), dann teile ich halt thematisch und lasse voneinander erben, obwohl es dann nicht eine basisklasse für mehrere ist, denn jeder braucht unbedingt alles:
ich meine z.b. sowas:
BasisIrgendwas
IrgendwasThemaA extend BasisIrgendwas
ThemaAThemaB extend IrgendwasThemaA
ThemaBThemaC extend ThemaAThemaB

hoffe ihr versteht was ich meine :-)
so, jetzt wüsste ich gerne wie ihr sowas händelt, vor und nachteile von diesen verfahren. danke.

[Omega Psi]

Delegation und Aggregation sind da denke ich die Zauberwörter. In Patterns ausgedrückt wären es die Visitor und Composite Patterns zum Beispiel, wenn ich dich richtig verstanden habe.

[hgseib]

hmmm, ich sehe es noch nicht

angenommen eine klasse 'avatar' hat 10 methoden.. alles ok, dann werden es 50, dann 100, dann ... alle avatare haben und benötigen alle methoden. es ist immer noch alles ok, nur das listing dieser klasse ist unübersichtlich lang geworden.
also eine aufteilung wegen der übersichtlichkeit beim programmieren, nicht wegen der logig oder struktur.

jetzt könnte man diese 100 methoden in z.b. x klassen aufteilen und jeder avatar erzeugt sich davon je eine (habe ich probiert, gefällt mir in der praxis nicht so gut).
oder der avatar erbt.

diese '100 methoden' sind nur der rest, der einfach zusammen gehört und sich nicht logisch abspalten lässt.
auch das erben macht eigentlich keinen sinn, weil's keine logische unterteilung gibt. es ist nur die frage: wie teile ich ein langes listing.

[Martin Kraft]

Hier hilft IMHO das OO-Prinzip:

Ziehen sie die Komposition der Vererbung vor!

Um bei dem Tier-Beispiel von oben zu bleiben, heißt das, dass man nicht alle denkbaren Eigenschaften (Farbe, Größe, Kopfform, Anzahl der Gliedmaßen...) und Methoden (laufen, atmen, fressen, schlafen, kacken...) in das Tier selbst integrieren sollte, sondern das Tier nur andere Klassen kombiniert, die Eigenschaften und Methoden enthalten. Diese Klassen beschreiben dann quasi die Teile (Organe, Gliedmaßen...) während das Tier das Ganze ist.

Ein Anwendungsbeispiel hierfür findet man in der FlashPlayer-API z.B. bei der Klasse DisplayObject. Diese verwaltet ihre Transformationseigenschaften ja auch nicht selbst, sondern enthält einen Instanz der Klasse Transform, die wiederum die Detailinformationen an die Instanzen diverser anderer Klassen deligiert (ColorTransForm, Matrix, etc.).

[mildesign]

generell solltest du dich an "composition over inheritance" halten.

Bei Spiele solltest du dir mal die PushButton Engine anschauen. Die ist open source und somit sehr gut als Inspirationsquelle geeignet.

[Martin Kraft]

Ich war so frei, diesen Thread nach Softwarearchitektur und Entwurfsmuster zu verschieben. Wenn so ein Thema nicht hierhin gehört, welches dann?!

[mildesign]

ZaaTV » Blog Archive » Understanding Components in PushButton Engine

[hgseib]

Zitat von mildesign

generell solltest du dich an "composition over inheritance" halten.

jaja, ich mache ja alles was man mir sagt, nur .. ich hätte gerne gewusst warum. der grosse 'aha'-moment ist bei mir noch nicht angekommen.
und nur weil alle es machen und alle es für gut empfinden .. so hat's mal ein paar jahrhunderte lang hexenverbrennungen gegeben, bis einer gesagt hat: eigentlich doch eine uncoole idee ...
dass das mit der risterrente in die hose geht (also für die einzahler) hatte ich auch schon vorher gewusst. und dass das mit den energiesparlampen nicht so weit her sein kann auch .. sorry, bin halt ein ewiger zweifler. ewig auf der suche nach dem 'noch besseren'.

also bitte: kann mir einer echte, überzeugende gründe nennen, warum (in so einem fall !!!) das vererben schlechter oder besser ist, als lauter klassen?

[Omega Psi]

Nehmen wir mal die Avatar Klasse, was soll sie alles können?

[Martin Kraft]

Zitat von hgseib

also bitte: kann mir einer echte, überzeugende gründe nennen, warum (in so einem fall !!!) das vererben schlechter oder besser ist, als lauter klassen?

Die Fragen hast Du doch eigentich schon selbst beantwortet?!

• Eine einzelne Klasse macht dann keinen Sinn, wenn man so viele Eigenschaften und Methoden hat, dass das Ganze unübersichtlich wird und die Wartung erschwert. Wenn sie also einfach zu groß ist.
  
  
• Vererbung macht dann keinen Sinn, wenn es keine Begründung für sie gibt und keine vernünftige Ahnenfolge entsteht. Die Klassen in der Vererbungshierachie also quasi austauschbar werden und man beim Programmieren dauernd zweifet, in weche Klasse die aktuelle Information nun grade gehört.
  
  Vererbung ist ja auch nicht immer nur praktisch. Die Tatsache, dass man immer nur eine Klasse beerben darf, hindert einen z.B. daran Funktionalitäten anderer fertiger Klassen zu übernehmen.

Wenn man Klassen einfach kombiniert, statt sie erben zu lassen, ist man IMHO viel freier im Aufbau, kann häufiger auf fertige Module zurückgreifen und diese dann z.B. auch zwischen einzelnen Instanzen austauschen. Wenn Du z.B. die Bewegungsinformationen Deiner Spielfigur in einer Klasse kapselst und deren Instanz als Eigenschaft in der Figuren-Klasse verwaltest, kannst Du diese Bewegung einfach auf ein andere Figur übertragen.

[Omega Psi]

Ohne zu wissen, was eine Klasse machen soll, weiss man nicht, wie man sie refaktorieren kann.

[malthoff]

Durch Vererbung hast Du unglaublich starre Strukturen. Ändert sich oberhalb der Hierarchie etwas wirkt sich das auf ALLE unteren Strukturen aus. Und das ist nicht nur der Sinn sondern auch die Falle bei Vererbung.

Die Tatsache, dass durch den Aufbau mit Komponenten die Anzahl der Klassen durchaus extrem steigen kann, lässt einen zu Beginn an der Sinnhaftigkeit zweifeln. In der Anwendung kommt dann die Einsicht.

Du siehst, wie sich plötzlich Teile der Anwendung kapseln lassen und das bedeutet nicht nur Übersichtlichkeit in der Struktur, sondern auch mental eine ganz andere Fokussierung. War es vorher die Gesamtstruktur, die Du im Kopf haben musstest, ist es jetzt plötzlich ein spezielles Detail (Bewegungsmodul), auf welches Du dich konzentrieren kannst. Du möchtest, dass der Hund bei jedem zweiten Schritt hüpft? Dann erstelle eine neue Klasse die nur dieses Verhalten beschreibt und steck es mit in dein package von gesammelten Bewegungsverhalten. Den Hund selbst, oder alle anderen Tiere interessiert das nicht - sie bekommen ihr Verhalten "eingesteckt" und wissen nur, DAS sie sich bewegen müssen.

Das heisst, die Klasse Tier bleibt, einmal so geschrieben, dass entsprechende Verhalten als Objekt "eingesteckt" werden können, von weiteren Änderungen unberührt.

Eines der meist genannten Prinzipien von OOP ist "encapsulate what varies", also "kapsel die Dinge, die sich ändern". Vererbt werden sollten nur Dinge, die sich nicht ändern. Das macht doch, wenn man drüber nachdenkt, einen ganz warmen Magen, oder?

[mildesign]

warum soll Composition besser ist als Vererbung:

-Testbarkeit:
kleine Einheiten sind leichter zu testen da für einen Test weniger Abhängigkeiten zu erfüllen sind.

-Wiederverwendbarkeit
"Think Lego vs Pledo"

durch definierte Schnittstellen kannst du dir aus deinen Bestand an "Bausteinen" die nötigen und passenden raussuchen und musst keinem Ballast aus der Vererbung mitschleppen.

Den Mehraufwand an Konfiguration der ein kombiniertes Objekt gegenüber einem Objekt welches über eine Vererbung erstellt wurde erzeugt, kannst du über Patterns wie Builder oder Factory wieder abfangen. Eine Vererbung hingegen bleibt starr.

[sebastian]

Zitat von Martin Kraft

Hier hilft IMHO das OO-Prinzip:

Ziehen sie die Komposition der Vererbung vor!

Korrekt!

Zitat von Omega Psi

Ohne zu wissen, was eine Klasse machen soll, weiss man nicht, wie man sie refaktorieren kann.

Korrekt!

Man kann keine universell gültige Antwort für alle Fälle geben, je nach
Anforderung machen unterschiedliche Strukturen Sinn.

Aber natürlich macht es in den aller meisten Fällen Sinn die Komposition
vorzuziehen. Nur darüber hinaus kann man die Struktur ja auch noch
optimieren. Dazu benötigt man dann aber doch konkretere Infos.

[hgseib]

so schaun mir mal:
gehen wir mal davon aus, das ich (sehr unwarscheinlich) nicht total blöde bin, mir also dinge wie vererben und klassen anlegen rudimentär bekannt sind ;-) und das mich kein 'man macht das so' interessiert sagte ich, ebenso das ich soweit sinnvoll bereits basisklassen und eigenständige klassen geschaffen habe. ich sagte, ich rede vom rest. mich hätte überzeugt, wenn beispiele zeigen würden, das z.b. der speicherbedarf extrem grösser würde oder die verarbeitungzeiten messbar länger werden oder irgend sowas.

mal willkürlich und unvollständig rausgegriffen (ohne namensnennung, manche leute fühlen sich schnell persönlich angegriffen, das will ich aber doch garnicht). ich suche handfeste gründe für und wieder:
- "Durch Vererbung hast Du unglaublich starre Strukturen" ist klar und gehört zum grundwissen jeden programmierers, da brauchen wir eigentlich nicht drüber reden. dennoch danke für den beitrag. solche und ähnliche argumente gibts hier einige, die seien sinngemäss hiermit auch behandelt: der grund, warum zwischen fussfessel und knie kein weiteres gelenk ist könnte der sein, dass ein zusätzliches gelenk an dieser stelle nicht benötigt wird. würde es gebraucht bzw. wäre es sinnvoll, dann wäre da eins.
- "Aber natürlich macht es in den aller meisten Fällen Sinn die Komposition vorzuziehen." wieso ist das natürlich? gibts dafür gründe? zum 'warum' wollte ich ein paar konkrete argumente hören.
- "Vererbung macht dann keinen Sinn, wenn es keine Begründung für sie gibt und keine vernünftige Ahnenfolge entsteht." ja, das ist mein dilemma! der 'rest' ist weder zum erben noch für abspaltbare klassen so recht geeignet. natürlich kann man so oder so .. aber so richtig glücklich bin ich bisher mit noch keiner lösung. ich suche noch. darum hier mein beitrag, neue ideen zu bekommen.
- "Wiederverwendbarkeit". ach sorry, das ist so wie politiker die von nachhaltigkeit, glaubwürdigkeit, schnellstmöglich und umfassend faseln. 90% von all dem was ich programmiere kann ich nicht wieder verwenden, weils einmalige sonderfälle sind (bin kein fliessbandarbeiter). es gibt eine handvoll sachen, die brauche ich immer wieder (deshalb machen die einen grossen teil der programme aus, aber nicht von dem was ich programmiere), diese pflege und hege ich. für den rest (die 90% meiner arbeit) ist das echt unsinnig.
- "Testbarkeit" ja, das wäre ein argument, wenn es denn für was spräche? ist vererben besser testbar oder zusätzliche klassen und wenn, warum? somit ordne ich auch das zum allgemeinwissen jedes programmierers ein, ist aber für eine entscheidunghilfe für hier nicht relevant?
- "in welche Klasse die aktuelle Information nun grade gehört" gilt für basisklassen von denen ich erbe genauso wie für eigenständige klassen. ich suche nach unterschiede, nicht nach gemeinsamkeiten ;-)

mein resume:
ich sehe, es ist glaubenssache (manche sind von ihrem glauben sehr überzeugt) und eine lösung für mich nicht in sicht.
danke für alle beiträge und links. ich habe alles gelesen bzw. bin noch dabei.