Programmier"stil" C#

[KitKat::new()]

Code direkt in die Getter und Setter zu packen, das sollte man nur sehr sparsam einsetzen.

Echt? Komm ich jetzt nicht ganz mit - erklär mal 🙂

 

[Jesterfox]

Anstatt in der Klasse Spiel die Koordinaten des Spielers und die Größe des Spielfeldes abzufragen und dann zu berechnen, wie sich der Spieler bewegen darf, warum fragst du nicht einfach das Spielfeld, ob ein Spieler einen Schritt nach rechts gehen darf? Dann müsste zwar immer noch das Spielfeld die Koordinaten des Spielers kennen, aber die Abhängigkeit zum Spiel hin ist gelockert. Dann könnte man vielleicht später sogar einmal ein Spielfeld verwenden, das nicht rechteckig ist …

Ja, die Frage wohin die Logik gehört ist nicht immer ganz einfach. ich hab dazu mal ne (imho) gute Regel gelesen. Wenn man sich unsicher ist weil es sowohl in die eine als auch in die andere Klasse passen könnte dann gehört es vermutlich in eine dritte eigene Klasse. Als Beispiel kamen dann die Klassen Kuh und Milch und die Frage wohin die Methode Melken() gehört... das the cow milk herself or does the milk uncow itself? ;-)

Im Falle des Spielfeldes und der Bewegung würde ich wohl dem Spielfeld eine Methode geben die einen Zug von A->B überprüfen kann und die Verwaltung von Spieler (bei dem vermerkt ist auf welchem Feld er steht) und Spielfeld (das sein Layout kennt) in eine Game-Logic Klasse packen.

Ergänzung (11. August 2021)

Komm ich jetzt nicht ganz mit - erklär mal 🙂

Ma sollte es sparsam einsetzen heißt erst mal nicht das man es gar nicht machen sollte. Man sollte sich aber gut überlegen was man da reinpackt. Ein Getter sollte wirklich nur lesen und ein Setter nur den Wert übernehmen. Wenn dazu zusätzlicher Code notwendig ist, dann ist das so. Aber mehr sollte da drin nicht passieren. Entspricht übrigens auch Clean Code, dass eben Code nur eine Aufgabe erledigen soll und die ist bei Gettern und Settern schon sehr spezifisch vorgegeben.

 

[Raijin]

In der Regel findet man in settern nur sowas wie eine Plausibilitätsprüfung - zB Wertebereich - oder den Aufruf für PropertyChanged o.ä.
Mehr sollte da nur in Ausnahmefällen rein und im Zweifelsfall könnte man den zusätzlichen Code gegebenenfalls im besagten PropertyChanged Event ausführen lassen, nachdem der Setter seine Arbeit längst abgeschlossen hat.

 

[steppi]

Danke nochmal für den vielen Input, ich habe gestern fast 4 Std. nochmal den Code "Reviewed" und komplett umgebaut. Dabei habe ich erstmal festgestellt, wieviel redundanten Code ich verwendetet hatte oder dass ich "Logik" im Bereich der "View" hatte. (also beim Zeichnen nochmal eben eine Position neugesetzt)

Was mir der Compiler jetzt noch in den Mitteilungen nennt ist "IDE1006 Verstoß gegen die Bennungsregeln: Diese Wörter müssen mit Großbuchstaben beginnen: ..."

Es handelt sich dabei um Attribute die ich in meinen Klassen verwende, also z.B. das hier:
public int columns { get; }

Ich hatte das jetzt aber eher so aufgeschnappt, dass Attribute und Variablen bei C# klein gehalten werden sollen und Klassen und Methoden groß sind?

 

[efcoyote]

Mit Getter/Setter ist es ein Property und die verlinkten Coding Conventions sagen zu Members mit public:

When naming public members of types, such as fields, properties, events, methods, and local functions, use pascal casing.

 

[steppi]

Perfekt danke.
Ich hatte vorhin mal durch die beiden Links geschaut und auch gesehen, dass da Beispiele in diese Richtung waren, aber den zitierten Satz hatte ich nicht gefunden bzw. hätte ich es glaub nicht als Propertie identifiziert.
Ich hatte aber genauso Artikel gefunden, die die Meldung der IDE "ignorieren (wollen)" und hatte mich dadurch verunsichern lassen, was nun richtig ist.

 

[BeBur]

Die Idee hinter Klassen besteht darin, Zustand (Daten/Variablen) und Verhalten (Funktionen) zu bündeln und über eine Schnittstelle (public Funktionen) zur Verfügung zu stellen. Das haben andere hier schon geschrieben, aber noch nicht zusammengefasst in einem einzelnen Satz .

Das hier ist in dem Kontext sicherlich eine gute Lektüre: Tell-Don't-Ask
ImHo ist es guter Lernstil, allgemeinere Paradigmen eher dogmatischer als lockerer umzusetzeren, Ausnahmen und Alternativen lernt man mit der Zeit. Also im Zweifelsfall lieber ein GetterEradicator sein , d.h. keine Getter/Setter Methoden verwenden.