QRoo hat geschrieben:Wäre es nicht sinnvoll HotChick als Mutterklasse zu lassen um dann die Elemente Intellekt, Maße und an HotChickChild zu vereerben?
Aber HotChick und HotChickChild sind doch funktional identisch, oder? Die Frage ist eher, wo wir überall HotChicks brauchen. Am Pool z. B. ganz klar. Aber ja auch noch anderswo, so dass wir das evtl. anders machen sollten. Z. B. könnten wir Pool, Beach, Bar usw. von LeisureActivities erben lassen und zu denen die Chicks private via friend (oder als nested Class, uah) hinzutun. Dann kriegen wir sie gratis bei jedem Freizeitgebäude hinzu und keiner kann sie uns klauen
QRoo hat geschrieben:Naja ne andere Möglich haben wir ja nicht. Überlege doch mal die auswirkungen wenn wir unser chick public machen
Stimmt schon. Wir müssten das HotChick vom Pool-Objekt instanziieren lassen. Dann hätten wir's immer dabei und kein andrer könnte sich ein HotChick bauen
Wäre es nicht sinnvoll HotChick als Mutterklasse zu lassen um dann die Elemente Intellekt, Maße und an HotChickChild zu vereerben?
Wie willst du Intellekt weitervererben, wenn HotChick selbst es nicht hat?
Vielleicht sollte Chick die Basisklasse sein, für HotChick eine zu erstellen, halte ich für unnötig.
Das bringt doch nur Codebloat. Was haben Woman und HotChick schon gemein? Die paar Äußerlichkeiten können wir dank multiple Inheritance ja problemlos hinzupacken.
Das bringt doch nur Codebloat. Was haben Woman und HotChick schon gemein? Die paar Äußerlichkeiten können wir dank multiple Inheritance ja problemlos hinzupacken.
Stimmt woman und Hotchick passt nicht. wir könnten aber eine Basisklasse EMU einrichten von der wir Hotchick ableiten. Die Frau die EMU ist ist einfach auf die ein oder andere Weise Hot . Methoden und Elemente können ja dann nach belieben in der abgeleiteten Klasse Hiotchick ergänzt werden.
an HotChickChild zu vereerben?
Aber ich soll jetzt ja programmieren 
. Methoden und Elemente können ja dann nach belieben in der abgeleiteten Klasse Hiotchick ergänzt werden.
