spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »DeKugelschieber«

Mir ist gerade beim lesen von Toas Post noch mal aufgefallen: in unserem Projekt wird sehr viel "weggemocket". Das führt dann zu einem dichten Gestrüpp aus XYBuildern, bei denen es länger dauert herauszufinden wie sie funktionieren, als den eigentlichen Test zu schreiben. Die Builder erzeugen ohne entsprechende Methodenaufrufe Objekte im ungültigem Zustand (was sich beim testen dann als Exception äußert, Top Kandidat ist da die NullPointerException).

Es kann sein das euer Mock Framework (falls ihr eins habt, die builder klingen nicht so) einfach zu unintuitiv ist. Die Vorgehensweise das man einen leeren Dummy erzeugt und dann Stubs für die benötigten Funktionen anhängt ist aber üblich. Es soll sogar eine Exception geworfen werden wenn Funktionen aufgerufen werden, die gar nicht aufgerufen werden sollten und entsprechend nicht hinzugefügt wurden.

Bei uns ist es mit den ungültigen Zuständen zum Glück nicht so schlimm. Dennoch ist die Art, wie das erreicht wird, meiner Meinung nach nicht so sinnvoll.
Beispielsweise gibt es bei uns im Model, also in den Datenklassen, für alles Getter und Setter. Die Setter (vor allem bei Strings) sind so implementiert, dass sie nichts prüfen (kein null-check, obwohl es kaum Member gibt, bei denen ein null Sinn machen könnte), in den Gettern wird dann aber der null-check durchgeführt und notfalls ein Leerstring zurückgegeben.
Alle Arten von Listen (meist ArrayList<T>) sind dabei eine Ausnahme, damit nicht einfach ein null zugewiesen kann, gibt es keinen Setter, sondern nur einen Getter. Den Listen können dann Werte zugewiesen werden, indem die Liste per Getter abgerufen und deren Methoden (add, remove[ic], [ic]clear, ...) aufgerufen werden (statt Methoden, wie "addComment" zu verwenden).
Mit "Datenklassen" meine ich natürlich auch Klassen, die ausschließlich Daten und entsprechende Getter und Setter beinhalten. Da "Im Model keine Logik" sein darf, befinden sich alle möglichen Methoden, die auf irgendeine Weise die Model-Objekte anpassen, in den Managern (früher mal Singletons, jetzt über ServiceLocator abgerufen). Dass nicht ausnahmslos alles in die Model-Klassen geschaufelt werden sollte, ist verständlich und richtig, aber ein Großteil der Dinge, die in den Methoden gemacht wird, gehört eher an andere Stellen.

Und man kann sich doch durchaus für DeKugelschieber freuen, dass in seinem Team automatisierte Tests geschrieben werden. Das ist leider nicht überall der Fall...

Zitat von »DeKugelschieber«

Zitat von »Sacaldur«

Alle Arten von Listen (meist ArrayList<T>) sind dabei eine Ausnahme, damit nicht einfach ein null zugewiesen kann, gibt es keinen Setter, sondern nur einen Getter. Den Listen können dann Werte zugewiesen werden, indem die Liste per Getter abgerufen und deren Methoden (add, remove[ic], [ic]clear, ...) aufgerufen werden (statt Methoden, wie "addComment" zu verwenden).

Das z.B. finde ich gelungenes Design. Ständig wird um Container herumprogrammiert. Aber genau diese Dinge, die ich in meinen privaten Projekten für selbstverständlich erklärt habe, werden hier noch gewrapped, durch ServiceLocater und eine Abstrakte Basisklasse + mehrere Interfaces versteckt/abstrahiert bis zum geht nicht mehr.

Auf diese Weise ist es aber nicht möglich, die Werte, die der Liste hinzugefügt werden, zu prüfen. Man kann durchaus darüber streiten, welche Prüfungen (maximale Länge bei Strings, kein null) und Einschränkungen (bspw. kein Entfernen von Kommentaren) wohin gehören, meiner Meinung nach sollte aber im Großteil der Fälle nicht einfach eine intern verwendet Liste nach außen weitergereicht werden.

Das geht technisch, ist praktisch aber Mist, weil man eine Komposition nicht durch eine Vererbung ausdrücken sollte. Und nur für Konsistenzprüfung ständig eine Unterklasse einzuführen ist auch sehr unschön.

Man kann Objekte falsch verwenden, aber sie sollten so aufgebaut sein, dass das so schwer wie möglich ist.
Abgesehen davon kann es für Außenstehende auch, abhängig vom Anwendungsfall, eventuell einfach egal sein, wie die interne Repräsentation aussieht, ob also ein Array oder eine Liste verwendet wird, ob Kommentar-, UserContent- oder String-Objekte verwendet werden.

Und BlueCobold hat ja schon geschrieben, dass diese Erweiterung des Arrays nicht gerade gut ist. Spätestens, wenn eine Prüfung durchgeführt werden muss, die auf dem Wert eines anderen Members (nicht der Liste) beruht, wird wieder eine Referenz auf das Objekt benötigt, das diese Liste beinhaltet. Auch wenn man das mit inneren Klassen machen kann, zeigt das, dass das absolut nichts mit Wiederverwendbarkeit zu tun hat. Entsprechend wäre es sinnvoller, nach außen hin nur die Operationen anzubieten, die zugelassen sind.