OOP klasse nicht viel mehr als ein container, wie mit Methoden umgeben
-
Hallo,
ich habe eine Klasse Wand die ein vector voller Haken besitzt, Wand ist nicht viel mehr als ein spezialiesierter Conatainer.
Haken besitzt Methoden wie "void setSchild(string name)". Jetzt frage ich mich, soll Wand eine Methode bekommen "void setSchild(size_t index, string name)" oder soll Wand nur eine Methode "Haken & getHaken(size_t index)".
Der zweite Weg ist natürlich viel weniger Schreibarbeit aber das muss ja nix heißen.
Vererbung kommt nicht in Frage.
Wenn Wand eine setSchild Methode bekommt habe ich natürlich viel mehr Macht, Wand kann kontrolieren was mit den Haken passiert (aber vielleicht muss Wand das garnicht?).
Ich habe keine Erfahrung wie ich die Vor- und Nachteile gewichten soll.
Wie geht ihr damit um?Danke
-
Ich entscheide danach, ob es wirklich nur ein Container ist, den ich zB. wie ein Array anfassen möchte, oder ob es eine "richtige Klasse" ist, die die Programmlogik beeinflusst.
In deinem konkreten Beispiel, würde das vielleicht auf eine HakenList mit getHaken() hinauslaufen, die dann wiederum intern von einer Wand-Klasse benutzt wird, welche nach aussen hin nur eine BildÄnhängen-Methode anbietet.
PS: Hacken hat man am Fuß, du meinst Haken
-
getHaken ist IMHO logischer, weil du ansonsten mit setSchild den Haken und die Wand zu sehr miteinander verbindest.
-
Mach einfach erstmal irgendeine Sache und schau Dir an wie der weitere Code das ganze nutzt.
Wenn Du feststellst, daß Du später oft Infos aus der Wand abfragst um Dir dann nen Haken zu holen und den zu manipulieren, dann pack solche Operationen in die Wand-Klasse rein.
-
kingruedi schrieb:
getHaken ist IMHO logischer, weil du ansonsten mit setSchild den Haken und die Wand zu sehr miteinander verbindest.
ja darüber denke ich die ganze zeit nach, ob das nicht ein problem werden könnte
DrGreenthumb schrieb:
Ich entscheide danach, ob es wirklich nur ein Container ist, den ich zB. wie ein Array anfassen möchte, oder ob es eine "richtige Klasse" ist, die die Programmlogik beeinflusst.
In deinem konkreten Beispiel, würde das vielleicht auf eine HakenList mit getHaken() hinauslaufen, die dann wiederum intern von einer Wand-Klasse benutzt wird, welche nach aussen hin nur eine BildÄnhängen-Methode anbietet.
ich habe mich jetzt dafür entschieden wand eine setSchild methode zu geben, das ganze ist eine art testunit deswegen brauche ich viele orte wo ich logen kann
Jester schrieb:
Mach einfach erstmal irgendeine Sache und schau Dir an wie der weitere Code das ganze nutzt.
Wenn Du feststellst, daß Du später oft Infos aus der Wand abfragst um Dir dann nen Haken zu holen und den zu manipulieren, dann pack solche Operationen in die Wand-Klasse rein.
hört sich eingentlich ganz vernünftig an, man verbraucht wahrschienlich beim überlgen welcher weg besser ist mehr zeit als wenn man den code umschreibt