Klassen, Unterklassen Vererbung

Mann ist jetzt eine Eigenschaft von Mensch?
Die Säugetier Class ist aber schon richtig

Langsam. Lass mal bitte die Instanziierungen (diese As New-Zeilen) weg. Die kommen später und haben in den Klassen erstmal überhaupt nix verloren. In den Klassen geschrieben, bedeutet das nämlich automatisch eine Hat-Beziehung. Und Mensch hat "kein" Mann oder Frau, Genauso hat Hund keinen Dackel. Also: Lösch die gezeigten Zeilen, in denen As New steht.

Schau Dir nochmal Zeile#8 an. Das mag zwar erstmal prinzipell stimmen, aber damit sagst Du, dass ein Säugetiewr ein Haar hat. Das muss dann natürlich noch abgewandelt werden, aber ich will EdR nicht in seiner Erklärung vorgreifen. Behalt es aber erstmal im Hinterkopf.
Das mit Rüde und Hündin ist wie bei Mann und Frau. Es sind also Spezialisierungen von …?

Warum wird hier eigentlich dauernd Friend benutzt? Das ist für deine Anwendungen wirklich irrelevant. Beschränke dich auf Public/Private und Protected. Außerdem bin ich ein Säugetier und habe keine Gebärmutter

Wird aber besser. Guck deine Klasse Mann hat immer noch einen Member Mann. Also sich selbst ???
Beim Hund und Mensch hast du es richtig.
Aber irgendwie sieht die Klasse Hund jetzt genauso aus wie die Klasse Mensch, da sollte uns also noch ein Unterschied einfallen, damit die Nutzung beider Klassen gerechtfertigt ist, (doppelter Code und so..)

Ansonsten ists halt noch nicht vollständig

Gonger96 schrieb:

Warum wird hier eigentlich dauernd Friend benutzt? Das ist für deine Anwendungen wirklich irrelevant

Ich benutze in erster Linie für meine Klassendeklarationen Friend. Wie es andere machen, ist mir pupe. Bei meinen DLLs natürlich Public, aber meine Endprogramme sollen keine API zur Verfügung stellen, daher kein Public, sondern Friend. Ist das Deiner Meinung nach für Amlie in ihrer jetzigen Lernphase irrelevant oder siehst Du generell Friend als irrelevant?

Na angenommen man könnte Mensch und Hund wirklich nicht weiter unterscheiden, dann wird halt eine Klasse davon gestrichen. Brauchst dann nicht.

Man könnte aber



Oder wie ich es tuen würde wenn man es abstrakt versteht, aber da kommen mir wieder die Tierschützer in die Quere.


Das sind immer so viele Klassen, nur meist nicht selbst geschrieben. Jedes Objekt hat irgendwo eine Klasse hinter sich stehen.

Wenn hier gerade die Grundsätze der Vererbung besprochen werden, finde ich es eher verwirrend.
In einer Anwendung (exe) benutze ich public. Friend ist eher sinnvoll bei Bibliotheken für etwaige Helferklassen oder Funktion die zwar in der Assembly genutzt werden, in der öffentlichen Schnittstelle aber nichts zu suchen haben.

Ich würde es wirklich erstmal bei public, protected und private belassen. Außerdem ist der Name nicht so toll. Das C# internal macht genau das was es heißt: Die Funktion ist Assembly-intern. Friend verwechsel ich immer mit C++ friend, was wieder etwas vollkommen anderes ist.

Haudruferzappeltnoch schrieb:

Mensch und Hund wirklich nicht weiter unterscheiden

Als Unterscheidungsmerkmal hätte ich an "Sprache" gedacht (wobei ich mir unter "Sprache" etwas vorstellte, was aus Worten besteht).
Natürlich kann man nachträglich alles mögliche noch hinzufügen: (Unterscheidungs-)Merkmale so gut wie vererbende und erbende Entitäten.
Aber ich würde vorschlagen, bei den gegebenen Begriffen zu bleiben, und nicht zu versuchen, eine vollständige Kladistik zu erstellen.

Ich bin mit was anderen nicht zufrieden:

VB.NET-Quellcode

1. Public Class Säugetier
2. Inherits Wirbeltier
3. Friend Lunge As Lunge
4. End Class
6. Public Class Mensch
7. Inherits Säugetier
8. Friend Haar As Haar
9. End Class
11. Public Class Hund
12. Inherits Säugetier
13. Friend Haar As Haar
14. End Class

unzufrieden in zweifacher Hinsicht:
Erstens erben Hund und Mensch ihre Behaarung vom Säugetier.
Zweitens hat ein Säugetier viele Haare.
Es liegt also eine Hat-Beziehung vom BeziehungTyp3 vor. Das modelliert man durch eine Auflistung, zB so:

---

Ansonsten, für die Intention des Spiels: Vererbung und Komposition zu verstehen, ist es egal, ob Friend oder Public deklariert wird.
Tatsächlich gibts noch ca 10 weitere Möglichkeiten, wie man deklarieren könnte, aber lassen wirs doch erstmal so wies ist - ist doch nicht falsch.

---

Also die Aufgabe ist noch nicht erledigt.
Und sie ist nur erledigt, wenn auch alle vorgegebenen Begriffe richtig eingeordnet sind.
Also nur Teile des Listings zu posten reicht nicht, weil die Klassen beziehen sich aufeinander, und wenn was fehlt wird es quasi sinnlos (und zB der Compiler kompilierts nicht).

Amelie schrieb:

Erstens erben Hund und Mensch ihre Behaarung vom Säugetier.
Also doch wieder einzeln machen?

Keine Ahnung, was du meinst mit: "einzeln machen"?
Aber so oder so: Ist doch sonnenklar, was für das Klassen-System daraus folgt, wenn gesagt wird: Hund und Mensch erben ihre Behaarung vom Säugetier.

Amelie schrieb:

Friend Haare As List(Of Haar) ist das nicht nur eine spezielle Art von: Friend Haar As Haar

Tja, das ist ein Problem mit der Mehrdeutigkeit der natürlichen Sprache.
Mit "Haar" meinte ich "einzelnes Haar", und nicht Haar im Sinne von "Kopfbehaarung beim Menschen".
Und von den einzelnen Haaren hat ein Säugetier numa viele.

Fell = Ansammlung von Haaren -> ein Fell ist per Definition = viele Haare, von daher braucht ein (Fell)Tier nur ein Fell.
Haar = (normalerweise) ein einzelnes Haar; ein Mensch hat nach der Definition viele Haare, von daher braucht die Klasse eine Sammlung von Haaren; oder alternativ nur eine Haarpracht - das entscheidest Du selbst. Es muss nur schlüssig sein.

VaporiZed schrieb:

Es muss nur schlüssig sein.

Isses aber nicht. Wie gesagt: Mensch und Hund erben die Behaarung von Säugetier!
Daraus ergibt sich klar, in welcher Klasse die List(Of Haar) anzusiedeln ist.

Und wie ebenfalls gesagt: Solange das Klassensystem nichtmal die bislang gegebenen Begriffe korrekt abbildet, lass uns nicht mit Einführung weiterer Begriffen verzetteln.

Erweitern kann man immer noch, wenn das gegebene Material erstmal stimmig ist.
(obwohl "Haarpracht" und "Fell" da nicht meine Favoriten wären)

Jo, ich finde, so passts, und nun fällt mir nix mehr rechtes noch zu sagen ein.
Vlt. Zusammenfassung: OOP orientiert sich an der realen Welt, und erschafft ein Modell von Wirklichkeit.
Also Objekte der Wirklichkeit werden miteinander in Beziehung gesetzt.
Es gibt zwei grundlegende Arten von Beziehung
Ist-Beziehung - Vererbung
Hat-Beziehung - Komposition
Die Hat-Beziehung ist nochmal unterteilbar in "Hat genau ein" und "Hat viele"

Es sind ganz einfach verständliche Sätze, mit denen eine Beziehung ausgedrückt wird:
A ist B
A hat B
A hat viele B

Mensch ist Säugetier
Mensch hat Sprache
Säugetier hat viele Haare

Sowas kann man 1:1 in der Code-Architektur abbilden. Diese Abbildung von einfachen Sätzen in Code ist auch umkehrbar. Wenn ich Code sehe (oder im ObjectBrowser angucke), dann kann ich die entsprechenden Sätze bilden und erkennen, ob die Architektur stimmig ist oder nicht.


Jo, dassis glaub der Kern von OOP. Naja, einer der Kerne, es gibt noch weitere ganz grundlegende Konzepte. Oder vlt. ist das - Vererbung und Komposition - der innerste Kern, der aller-innerste, und weitere Konzepte sind unbedingt auch zum Kern zu zählen, nur vielleicht ein ganz klein wenig weniger innerlich.
Naja - da fängt ganz schnell das Streiten wieder an, und die Leuts kommen mit zig weiteren Dingen an, die iwie eingeordnet werden müssen, um der Konfusion zu entgehen.

---

Auch zu sagen bleibt noch, dass selbstverfasster Code nur ganz selten Vererbung implementieren muss. Fast immer ist die Architektur über Komposition aufzubauen, also A hat B liegt vor, oder A hat viele B.
(Das kennste ja noch aus deim Ampel-Programm)

Amelie schrieb:

Wie mache ich das dann in der Klasse richtig?

Da sind wir wieder beim Punkt. In welcher Klasse? Wie ist der Name? Gilt eine hat Beziehung: Klasse hat Booleans? Das ist quasi dein Design jetzt, keine Tiere mehr.

Die Form, die du hast ist eine Klasse und die hat Controls, zu den Controls zählen z.B. auch die Buttons (Vererbung), die bleiben da besser auch.