Get und Setmethoden wirklich sinnvoll?

Hallo!

Ich habe 8 Variablen in einer Klasse und mit Get und Set Methoden würde das so aussehen:

// Set methods
		void IncreaseMana(int m)	 { mana      += m; };
		void IncreaseStrength(int s) { strength  += s; };
		void IncreaseHitpoints(int h){ hitpoints += h; };
		void IncreaseDexterity(int d){ dexterity += d; };

		void SetMana(int m)	    { mana      = m; };
		void SetStrength(int s) { strength  = s; };
		void SetHitpoints(int h){ hitpoints = h; };
		void SetDexterity(int d){ dexterity = d; };

		void IncreaseMaxMana(int m)	    { maxMana      += m; };
		void IncreaseMaxStrength(int s) { maxStrength  += s; };
		void IncreaseMaxHitpoints(int h){ maxHitpoints += h; };
		void IncreaseMaxDexterity(int d){ maxDexterity += d; };

		void SetMaxMana(int m)	   { maxMana      = m; };
		void SetMaxStrength(int s) { maxStrength  = s; };
		void SetMaxHitpoints(int h){ maxHitpoints = h; };
		void SetMaxDexterity(int d){ maxDexterity = d; };

		// Get methods
		int GetMana()     { return(mana);      };
		int GetStrength() { return(strength);  };
		int GetHitpoints(){ return(hitpoints); };
		int GetDexterity(){ return(dexterity); };

		int GetMaxMana()     { return(maxMana);      };
		int GetMaxStrength() { return(maxStrength);  };
		int GetMaxHitpoints(){ return(maxHitpoints); };
		int GetMaxDexterity(){ return(maxDexterity); };

Das ist doch fast genau das gleiche als wenn ich sie gleich public mach oder nicht?!

Es sagt ja auch (hoffentlich) keiner, dass du grundlos irgendwelche getter und setter anbieten sollst, sondern nur, wenn jemand, der die Klasse benutzt, sie auch wirklich braucht.

Von der Geschwindigkeit her nimmt sich das nichts, d.h. mit Zugriffsmethoden wird Dein Programm nicht langsamer (ich lasse mich gerne korrigieren).

Der ganze Aufwand hat aber den Vorteil, dass Du als Programmierer genau weisst, wann und wo Deine Variablen von ausserhalb der Klasse geändert werden. Wären die Elemente public, so kann im Prinzip an jeder Stelle Deines Programms die entsprechende Variable geändert werden.

Ich hoffe, das klingt nicht zu kompliziert.

Sovok

ausserdem kannst du überprüfen/verhindern dass ungültige werte gesetzt werden

// 0 - 100
void SetHitpoints(int h)
{
assert ( h>= 0 && h<=100 ); 
hitpoints = h; 
};

Gut dann lass ichs erstmal so wie es ist. Ich fand nur das die Klasse exterm aufgebläht wird

Wenn ich wirklich der einzige bin der die Klasse benutzt, wäre es bei solchen einfach fällen nicht "besser" die variablen public zu machen?

Oder immer strikt OOP-konzeptmäßig denken?

Jester

Wichtig ist vor allem auch der Punkt den Optimizer hat anklingen lassen: man braucht nicht für alles getter und setter.
Daß Du abfragen mußt, wieviel Mana Dein Charakter (oder was auch immer) noch hat seh ich noch ein. Also: get reinbauen. Daß Du das hingegen setzen mußt ist mir nicht klar. Zu Beginn hat er vielleicht volles Mana... okay, das kann der Konstruktor machen. Wenn er jetzt was zaubern will, dann ginge das auch einfach so:

charakter.zaubere(spruch);

Das wirkt den spruch und zieht das Mana ab. Keine Notwendigkeit das selbst zu machen. Die Variable wird also vermutlich keinen setter brauchen. Zumindest nicht dafür.

Überleg Dir also genau was Du brauchst, bzw. mach's einfach so:
mach einfach immer nur das rein was Du wirklich brauchst. Wenn Du später mal merkst, daß Du doch irgendwo direkt zugreifen mußt: der setter/getter ist schnell geschrieben. Aber schieb es so lange auf wie Du noch nicht weißt, ob Du's brauchst. Du wirst Dir automatisch gedanken machen, ob man's nicht auch anders lösen kann und damit oft zu besserem Design finden. Das Problem mit get/set ist, daß sie wenig Abstraktion bieten. Klassen, bei denen alle Variablen mit set/get erreichbar sind degenerieren schnell zu einer Art Container von Variablen mit ein paar Hilfsfunktionen.

MfG Jester

Danke für die Tipps!

Bis jetzt sind alle sinnvoll, SetMana (die anderen auch) werden verwendet wenn der Charakter z.B. einen Trank trinkt der dann das Mana auf 0 setzt, Stärke auf 20 usw.. Hier fällt mir gerade auf das die get und set methoden doch praktisch sind

Nachher setz ich noch Stärke auf 20 und MaxStrength ist aber 15

Nein, ist nicht sinnvoll. Du sagst dem Charakter trinkTrank().
Diese Methode fragt den Trank wievielManaLieferstDu() und erhöht entsprechend. Dabei berücksichtigt sie auch noch das Maximum, was der Charakter aufnehmen kann.
Lass die Klasse Charakter ihre Variablen selber manipulieren und nicht von außen.

Stimmt

Jester

Das ist genau das was ich meine. Nicht erst die getter/setter rein und dann losprogrammieren... da geht alles wunderbar einfach und ist auch sehr sinnvoll (es geht ja so einfach). Wenn man aber jedesmal, wenn man gern nen getter hätte den erst schreiben muß, dann überlegt man sich auch, ob man den wirklich braucht. Soweit kommt man garnicht, wenn man ihn schon hat. Da ist das obj.getBlablabla() schon getippt bevor man angefangen hat zu denken. (zumindest isses bei mir manchmal so)

RHBaum

Wenn ich wirklich der einzige bin der die Klasse benutzt, wäre es bei solchen einfach fällen nicht "besser" die variablen public zu machen?

Oder immer strikt OOP-konzeptmäßig denken?

Wenn die Welt schwarz weiss waer, waer ja alles so einfach ....

Fuer mich: wenn ich die "Zeit" habe, dann mach ichs auch sauber.

und das mit der einzige der die klasse benutzt .... es stimmt sicher in 90% der faelle fuer alle Hobbyprogrammierer .... aber die koennten auch ganz anderen schmutz machen, ohne dass es auffaellt ...
Aber Falls dein Projekt mal erfolg hat, vielleicht sogar finanziell, und du dein Programmierteam aufstocken willst, wirst du Dir so sehr wuenschen, die Zeit rueckgaengig machen zu koennen ....

Nen Grossteil aller Projecte in komerziellen Umfeld bgginnen eigentlich mich nem Hack-Programm, was mal irgendeiner, im idealfall wars sogar nen programmierer, "gehackt" haben .... , das das Project dann irgendwann mal neu aufgesetzt wird, ist auch klar, der unterschied ist meisst nur, wieviel man vom code weiterverwenden kann, und auch vom design ... oder ob von dem ursprung wirklich nur die idee verwendet werden kann.
Glaub mir Getter/ Setter spielen da ne nicht ganz unwesentliche Rolle.

Nen anderer aspect ist ... du kommst plotzlich drauf, das du mit einem Thread nimmer hinkommst, und musst deine klassen selber oder jeden zugriff threadsicher macher . Das ist der punkt, wo du von diesen Sachen anfaengst zu traeumen

Meine Regel die ich bisher noch nie bereut habe, Solange keine anderen gruende dagegen sprechen :
Members immer Private in Klassem ! Und auf bedarf eben setter und getter verwenden, auch wenn es um vererbung geht .....
Sinds einfache dinge die nur ne Variable durchschleifen, dann im kopf definieren, notfalls koennt man sich auch mit makros behelfen (was aber eigentlich pfui ist) :p

Das einzige argument was manansatzweisse gegen nen saueberes design anhoeren koennte, ist manchmal der zeitfaktor ... aber das ist eher nen sehr Betriebswirtschaftliches thema ...
Viele projekte brauchen schnelle "erfolge" um ueberhaupt ins rollen zu kommen, bei setter und getter ist der zeitgewinn durch weglassesn aber minimal ... ausserdem wuerde ich die ersten Versionen eines solchen progjektes ned als Programm sondern eher als prototyp bezeichnen ... Aber dafuer gibts allerdings auch Sprachen mit denen man schneller entwickeln kann ....

Ciao ...

flammenvogel

Ich schließe mich meinen vorrednern an, getter und setter bringen dir nur etwas wenn eine der folgenden Kriterien zutrift:

1. verhindern willst das die Variabel geändert wird
2. das ungültige Werte gesetzt werden
3. das die Variabel in einem anderenem Typ/Format ausgegeben wird (von char nach int)
4. wenn niemand die Variabel lesen soll (was praktisch nie vorkommt).

Bei deiner Mana geschichte trift schon punkt 2 zu, damit du verhinderst das die Mana über Mana max oder unter null gesetzt wird. (<- Je nachdem was du machst gibt das dann auch mal ne division durch null, was ärgerlich ist).

Dann muss man sich noch überlegen ob es sinvoll ist ein setter und einen getter zu haben, aber das thema wurde oben ja schon angesprochen.

flammenvogel schrieb:

4. wenn niemand die Variabel lesen soll (was praktisch nie vorkommt).

Ui, damit wär ich aber vorsichtig.