Methoden der Basisklasse TEILWEISE übernehmen
-
Ich habe zwei Klassen:
Sprite (Bildchen) und Rect (Rechteck).
Die Sprite-Klasse soll alle Methoden von Rect erben außer setWidth() und setHeigth, weil die durch die größe des geladenen Bildchens festgelegt sind.(Nebenbei: Brauchen rein-virtuelle Klassen Konstruktor und/oder Destruktor?)
-
könntest privat erben, und alles was mitsoll mit using wieder reinlassen,
baer meist ist sowas rumgefrickel und es gibt bessere wege
-
obbba schrieb:
(Nebenbei: Brauchen rein-virtuelle Klassen Konstruktor und/oder Destruktor?)
Zumindestens einen virtuellen Destruktor solltest du im Regelfall allen Klassen verpassen die als Basisklasse dienen.
obbba schrieb:
Die Sprite-Klasse soll alle Methoden von Rect erben außer setWidth() und setHeigth,...
Ich würde sagen: falsches Design. Mehrere Möglichkeiten:
a) Du verpasst beiden Klassen eine gemeinsame Basisklasse und leitest davon ab
b) Du nutzt Komposition und verpasst deiner Spreiteklasse als Member ein Rect
c) Du nutzt private Vererbung (Siehe Treb)cu André
-
ich würd auf komposition setzen, ist meiner meinung nach die sauberste und übersichtlichste lösung.
-
Also "ein Sprite HAT ein Rechteck"?
Dann muss ich aber immer schreiben "mySprite.rect.x" statt "mySprite.x".
Ich sag ja nicht "Das Rechteck vom Bild soll an die Position 123,33." sondern "Das Bild soll nach 123,33".Ich werde eine Klasse "ResizableRect" einfügen und bei dem bisherigen Rect die set-Methoden für Breite und Höhe wegmachen.
-
obbba schrieb:
Dann muss ich aber immer schreiben "mySprite.rect.x" statt "mySprite.x". Ich sag ja nicht "Das Rechteck vom Bild soll an die Position 123,33." sondern "Das Bild soll nach 123,33".
Der Direkte Variablenzugriff ist in den meisten Fällen in OOP ohnehin nicht erwünscht. Wenn du per Methoden arbeitest, und wir einfach mal annehmen das Rect eine SetX/GetX Methode hatte, würdest du dem Sprite ebenso eine verpassen und intern auf das Rect weiterleiten.
Unter berücksichtigung der in OO üblichen Datenkapselung wäre es dann ein mySprite.SetX(123) im vergleich zu einem rect.SetX(123)...
cu André
-
Ich werde eine Klasse "ResizableRect" einfügen und bei dem bisherigen Rect die set-Methoden für Breite und Höhe wegmachen.
rofl
ja, mach das. tolles design (<---- SARKASMUS)
-
teilweises erben widerspricht doch eigentlich dem sinn der objektorientieren programmierung?
-
Fachmann schrieb:
teilweises erben widerspricht doch eigentlich dem sinn der objektorientieren programmierung?
Nein, es widerspricht dem Sinn des Erbens...
-
hustbaer schrieb:
Ich werde eine Klasse "ResizableRect" einfügen und bei dem bisherigen Rect die set-Methoden für Breite und Höhe wegmachen.
rofl
ja, mach das. tolles design (<---- SARKASMUS)Mömömö
Dann halt nicht. War ja nur ein Vorschlag.
pumuckl schrieb:
Fachmann schrieb:
teilweises erben widerspricht doch eigentlich dem sinn der objektorientieren programmierung?
Nein, es widerspricht dem Sinn des Erbens...
Also im Unterricht hatten wir den "Stack" von der "verknüpften Liste" abgeleitet. Kann aber sein, dass das nur der Einfachheit halber war.
-
Hi,
ein Pixel-Bild ist im Allgemeinen ein Rechteck (bei gängigen Formaten), im Speziellen hat es eine gefüllte Fläche. Wenn ich mich also nur auf diese zwei Klassen und deren Logik beschränken müsste, würde ich Rect als Eltern- und Sprite als Kindklasse entwerfen. Demnach muss ein Bild auch in der Lage sein, seine Größe zu ändern. Dafür gibt es ja auch einen eienen Konstruktor.
Gruß
