spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich habe den Eindruck, dass die Leute bei dieser Diskussion immer davon ausgehen, dass einmal geschriebener Code in Stein gemeiselt sei. Aber das ist Quatsch. Wenn man halt eine Var hinter einen Getter/Setter stecken muss, dann ändert man das halt und korrigiert alle Zugriffe, die einem der Compiler als Fehler auswirft. Erledigt.

In gewisser Dosis sind Getter/Setter ne feine Erfindung. Wenn ich aber manche Klasse sehe, die jede Membervar als Getter und Setter durchreicht, dann hätte es auch eine schlichte Struktur getan.

Zitat von »Cookiezzz«

Und was ist, wenn du erst den Wert einfach setzt und sich dann später rausstellt, dass eine Wertprüfung doch sinnvoll wäre? Dann kann man den kompletten Code umschreiben.
Man sieht, damit sind wir nicht weitergekommen und diese Diskussion wird noch weitere 10 Seiten andauern.
Ich denke ob man Getter/Setter jetzt verwendet ist Teil des persönlichen Stils. Beides hat Vor- und Nachteile.

Ich fasse es sogar noch kürzer als Schrompf: Wenn so viel Code davon abhängt, dass das Umschreiben von Zuweisung zu Setter zum Problem wird, ist entweder der Setter oder der Code falsch.

Sehe ich auch so.

Problematisch könnte das nur bei APIs sein, die man anderen zur Verfügung stellt... Da lässt sich sowas evt. nicht mal eben ändern, zumindest nicht wenn die API auch tatsächlich viel genutzt wird und hunderte von Projekten ihren Code umschreiben müssen.
Aber ja, wenn so viel davon abhängt stecken die Variablen in den falschen Klassen.

Zitat von »DeKugelschieber«

@Cookiezzz: stimmt hatte ich nicht bedacht
Trotzdem werde ich sie vermeiden, der Nutzer der Schnittstelle sollte die Werte dann prüfen ob sie laut Doku sinn machen.

Stimme da voll mit ein.
Aber gemessen am vorherigen Bsp., war mir das doch ne zu pauschale Antwort

Prinzipiell *resümiere mal*..
Getter & Setter sind wichtige Instrumente der Kapselung.
Damit also OOP bedingt und wichtig, wenn man es denn so halten möchte.

Ich bin mir sicher, dass jeder hier ein UML diagramm zustande bekommt, dass seine Ansicht belegen würde.
Abhängigkeit also durch das Anwendungsgebiet impliziert und -meines Erachtens - primär durch die zu nutzende Sprache.

Also bei uns, würds ohne nicht gehen, 20 Leute - >50 Klassen..
Wenn man Polymorphismus versteht, sollte man schon damit arbeiten

Zitat von »bif_z«

Prinzipiell *resümiere mal*..
Getter & Setter sind wichtige Instrumente der Kapselung.
Damit also OOP bedingt und wichtig, wenn man es denn so halten möchte.

Und die Gegenaussage war, dass Getter und Setter die Datenkapselung aushebeln. Wenn man keinen Zugriff auf bestimmte Werte von außen benötigt, sollte es keine Getter und/oder Setter geben.
Einfaches Beispiel: ein Spieler kennt seinen derzeitigen Score. Ein anderes Spielelement will zu einem bestimmten Zeitpunkt (Kollision, Zerstörung, was auch immer...) Punkte hinzufügen. Ein direkter Zugriff auf die entsprechende Variable steht zweifelsfrei außer Frage, da sonst keine weiteren Prüfungen durchgeführt werden könnten (Wert > 0?). Getter und Setter würden dies ermöglichen (player.setScore(player.getScore() + 5)). Eine Property wäre zwar wie eine Variable aufzurufen, hätte aber die Vorteile von Gettern und Settern (player.score = player.score + 5 bzw. player.score += 5). Eigentlich will man nur den Score des Spielers erhöhen, warum ist man dann dazu gezwungen, den Score des Spielers vorher abzurufen? Besser wäre also eine Methode, die nur genau das übernimmt (player.addScore(5)).

Weil der Score von aussen nicht manipulierbar sein darf also = private sein sollte.
Da Kapselung auch besagt, Zugriffe zu verwalten, wäre das weniger ein Kontra, als ein Pro-Argument in meinen Augen.

Ich sehe genau darin den Sinn solcher Getter- und Settermethoden, schließlich kann man den Mutator auch so anlegen (was ich widerrum für das normalste Arbeiten überhaupt halte), dass man auch ohne Accessor expliziet setzen kann.

Prinzipiell, verstehe ich aber dein Bsp. nicht ganz, das Problem leuchtet mir noch nicht entgegen, verzeihung

Und deine Herangehensweise ist zu pauschalisierend.

Die meisten Benutzer hier werden kein Framework schreiben.
Sollte es für den einen oder anderen Benutzer doch der Fall sein, könnte durchaus zwischen der Flexibilität und sauberem Design abgewogen werden. Flexibilität um jeden Preis (selbst bei einem Framework) würde ich jedoch nicht als erstrebenswert ansehen.
Will man das Observer-Pattern implementieren, wäre es wesentlich flexibler, wenn man alle registrierten Listener anrufen könnte, da man dann jeden Listener einzeln untersuchen und nach belieben ab und wieder anhängen könnte. Gesehen habe ich dennoch bisher lediglich Implementierungen mit Add- und Remove-Methoden. (Und auch mit event lässt sich nur ein Event hinzufügen, entfernen oder alle vorhandenen Listener auf einmal aufrufen.)

Eigentlich beteilige ich mich gerne an Diskussionen über bspw. Software Design, da man dabei grundsätzlich Dinge dazu lernen kann, weil die Beiträge der anderen Seite evtl. Punkte beinhalten, die man noch nicht berücksichtigt hatte.
Bei deinem Beitrag fällt es mir aber schwer. Nicht wegen der Argumente, sondern viel eher wegen der Argumentationsweise. Ich habe zwar den Aufruf einer addScore-Methode aufgeschrieben, ich habe sie aber an keiner Stelle als add(positiven Score) beschrieben. Ich habe auch nicht geschrieben, dass das die einzige notwendige Methode ist und auch nicht, dass diese nur positive Werte annehmen kann. Ich wollte auch nicht schreiben, dass man auf diesem Wege den Getter sparen kann.
Und vor allem habe ich nur eine einzige "pauschalisierte" Aussage getroffen: man sollte nur das verwenden, was auch tatsächlich benötigt wird.

Ich war beim Schreiben des Beitrags am Überlegen, ob ich diesen wirklich verfassen sollte. Ich werde mich zukünftig wahrscheinlich wieder von diesem Thema fern halten.

@bif_z:
Man muss den Score erhöhen, also gibt es eine Methode, mit der man den Score erhöhen kann.

Wenn beide auftauchen, ist es das sehr oft. Ein Getter allein (also ohne Setter) ist wieder eine ganz andere Sache.