?
Entschuldige die späte Antwort.
Dravere schrieb:
@μ,
Da du bereits die ReadOnlyCollection erwähnst, wärst du somit gar nicht dafür zu haben, dass man eine Collection per Setter setzen könnte?
Naja bei Fragen wie den Deinen gibt es keine absoluten Antworten, was Du natürlich weißt. Es kommt auf das Projekt und die Teamgröße an.
Trotzdem tendiere ich dazu, dass man Collections eines Objekts nicht von außen austauschen sollte. Wenn man sich außerhalb eine Referenz auf die Collection speichert ist es einfacher, wenn dieses Objekt niemals ausgetauscht wird.
Dravere schrieb:
Ich finde es wahnsinnig praktisch, dass jeder seine eigene Liste dem RentableObject übergeben kann. Weil grundsätzlich transportiert RentableObject diese Liste nur. Die Klasse fängt damit nichts an. Auf der anderen Seite kann man nicht garantieren, dass es keine Null-Werte darin geben wird, wodurch man überall wieder zusätzliche redundante Prüfungen einführen muss.
Die Liste per Konstruktor übergeben und danach nicht mehr austauschbar machen?
Prüfungen auf Nullwerte auf höheren Schichten der Software sind einfach ein Nogo wie ich finde. Das lässt sich aber nur vermeiden, wenn nicht jeder seinen Müll in die interne Collection eines Objekts einfügen kann. Die Kernfrage ist doch, wie es überhaupt zu Nullreferenzen in einer Collection kommen kann. Ist das nicht ein ganz klarer Bug an anderen Stellen?
Vielleicht geht man während der Entwicklungszeit mit Asserts darauf ein, aber in einem Produkt das ausgeliefert werden kann will ich die Gewissheit, dass keine Nullreferenzen in einer Collection sind, wenn das nicht per Design beabsichtigt wurde. Und das konnten wir bisher gut damit erreichen, indem wir solche Fälle in Exceptions laufen gelassen haben und es immer in Tests festgestellt haben.
Dravere schrieb:
(...) dann müsste ich in diesen Algorithmen ständig prüfen, ob es Null-Werte in der Collection hat:
Eben nicht. Lass die Software abrauchen. Wenn solche Dinge nicht auffallen während der Entwicklung, sollte man imho an der Qualitätsprüfung ansetzen. Es gibt Projekte in denen Unit-Tests nicht so gut funktionieren, dann geht man eben den klassischen weg und kompiliert und startet die Software (oder Teile davon in kleinen Testprojekten) und schaut was passiert.
Also. Bei sowas hier:
foreach(...)
if(payment == null) continue;
würde ich mich direkt auf Fehlersuche begeben und meine Kollegen ansprechen, warum diese Prüfung überhaupt notwendig ist. Auf die Gefahr hin mich zu wiederholen: Eine andere Stelle der Software ist verbugt und das ist reine Symptonbekämpfung.
