In einer Diskussion, die ich darüber hatte, ob eine Interface-Methode ein Custom-Objekt gegen einen primitiven Typ zurückgeben soll, wurde eine Frage gestellt.
z.B.
%Vor%vs
%Vor%Wo MyFooObj ist:
%Vor%Das Argument ist, dass Sie dem Objekt in Zukunft problemlos Eigenschaften hinzufügen können, ohne den Schnittstellenvertrag ändern zu müssen.
Ich bin unsicher, was die Standardrichtlinien dazu sind?
Meine Standardantwort ist - YAGNI .
Sie können Dinge immer ändern, wenn es so aussieht, insbesondere, wenn Sie die vollständige Quelle der Anwendung steuern und wie die Schnittstelle verwendet wird.
Um einen Boolean nur für die Vorhersage der Zukunft einzufügen, fügen wir nur Komplikation und zusätzliche Abstraktionsschichten hinzu, wenn sie gerade nicht benötigt werden.
Wenn Sie DDD und spezielle Modellierungstechniken in Ihrer Codebasis verwenden, kann es sinnvoll sein, solche Aliase für boolesche Werte zu verwenden, wenn sie in Ihrer Domäne sinnvoll sind (aber ich sehe nicht, dass dies für einen einzelnen booleschen Wert der Fall ist) ).
Ich sehe den Punkt der Kapselung primitiver Typen in einem benutzerdefinierten Objekt nicht.
Wenn Sie die Definition dieses benutzerdefinierten Objekts ändern, ändern Sie den Vertrag tatsächlich, weil die Funktion nicht dasselbe zurückgibt.
Ich denke, es ist wieder ein überentwickeltes "Muster".
Es gibt keine allgemeinen Richtlinien diesbezüglich.
Wenn Sie eine Semantik um den Rückgabetyp haben, die Sie glauben glauben, könnte sich ändern oder muss möglicherweise in Zukunft aktualisiert werden, könnte es besser sein um den komplexen Typ zurückzugeben.
Aber die Realität ist, dass es in den meisten Fällen besser ist, die Dinge einfach zu halten und den primitiven Typ zurückzugeben.
Das hängt davon ab, was Sie mögen. Meiner Meinung nach würde ich in Ihrem Beispielfall aus folgenden Gründen bei der einfachen Definition bleiben:
IMHO, ein Objekt ist nur dann sinnvoll, wenn eine gewisse Komplexität / Gruppierung erforderlich ist.
Wenn es nicht von vornherein benötigt wird, sollte es nicht umgebrochen werden, wenn man das ändert, was innerhalb des Objekts zurückgegeben wird, ist dasselbe wie das Ändern der Schnittstelle, die Regel Nummer eins der Programmierung mit Schnittstellen verletzt.
Es ist ganz oben mit dem Entwurf für die Erweiterung, YAGNI (du wirst es nicht brauchen).
Als Randnotiz wurde ich schon früh in meiner Karriere davon abgehalten.
Wenn Sie jemals etwas mehr als einen booleschen Wert zurückgeben müssen, ist es sehr wahrscheinlich, dass Sie auch andere Teile der Schnittstelle modifizieren werden. Machen Sie die Dinge nicht komplexer, als sie sein müssen: Einfachheit ist die Voraussetzung für Zuverlässigkeit.
Ich möchte nur erwähnen, dass wenn MyFooObj in einer Assembly mit starkem Namen ist, Sie es aktualisieren, wird seine Version aktualisiert - alte Clients werden sofort brechen (zB InvalidCastException) aufgrund einer Versionskonflikt (es wird nicht versucht eine partielle Bindung aufgrund starker Namensgebung), sofern sie nicht mit der neuen Version neu kompiliert werden. Sie haben den Schnittstellenvertrag noch geändert. Um die Dinge einfach zu halten, geben Sie den primativen Typ zurück und deklarieren Sie Ihre Vertragsänderung genauer.