In letzter Zeit habe ich den Nutzen von unveränderlichen Objekten erkannt (einige würden überbeanspruchen), um Lese-Schreib-Abhängigkeitsprobleme in meinem Objektmodell und die daraus resultierenden Bedingungen und Nebenwirkungen drastisch zu reduzieren, um den Code letztendlich einfacher zu machen zu verwalten (Art der funktionalen Programmierung-esque).
Diese Vorgehensweise hat mich dazu gebracht, schreibgeschützte Objekte zu erstellen, die bei der Erstellungs- / Erstellungszeit Werte bereitstellen und dann nur öffentliche Getter für externe Anrufer verfügbar machen, auf die ich mit den Eigenschaften zugreifen kann. Geschützte, interne und private Setter ermöglichen das Beibehalten der internen Kontrolle über das Schreiben in das Objektmodell.
Beim Erstellen von Schnittstellen beim Erstellen einer API über mein Objektmodell habe ich begonnen, die gleichen Probleme bezüglich der Unveränderbarkeit zu untersuchen. Zum Beispiel, indem ich nur öffentliche Getter auf meinen Schnittstellen zur Verfügung stelle und es den Implementoren überlasse, über die Setter zu entscheiden und wie man mit diesem Aspekt umgeht.
Ein Beispiel für eine "Nur-Lese" -Schnittstelle für die Implementierung, von der ich spreche, ist dieses Wertobjekt (nur zur Demonstration):
%Vor%Allerdings habe ich mich gefragt, wie ich eine Companion-Schnittstelle bereitstellen sollte, die das Schreiben ermöglicht (und wenn ich sollte) und nicht diese Operationen innerhalb der gleichen Schnittstelle kombinieren, um ihre Unveränderlichkeit nicht zu "beschmutzen" .
Die folgenden Ideen sind mir direkt in den Sinn gekommen. Ohne das zu liefern, was ich für und für sich halte, Was ist Ihrer Meinung nach der beste Ansatz? Gibt es eine branchenübliche Codierungsmethodik für die Verwaltung dieses Konzepts?
%Vor%oder
%Vor%oder
%Vor%oder
%Vor%oder
etc ...
Was kann mir sonst noch helfen, mein ansonsten unveränderliches Programmiermodell zu schreiben und es mäßig flexibel zu halten oder zumindest die Sorgen zu trennen, um es besser kontrollieren zu können?
Ich denke, ich könnte eine Variante Ihrer Ideen verwenden, etwa so:
%Vor%Auf diese Weise hat Ihre veränderbare Schnittstelle vollständige Getter und Setter (ich glaube nicht, dass es sinnvoll ist, eine Schnittstelle zu haben, die Setter hat, aber keine Getter), aber jedes Objekt, das es implementiert, wird auch eine unveränderliche Version der Schnittstelle haben Sie können für jeden reinen Funktionscode verwenden.
Sie sollten separate Schnittstellen für ReadableFoo, ImmutableFoo und MutableFoo haben. Die letzteren beiden sollten von der ersten erben. ReadableFoo sollte eine "AsImmutable" -Methode enthalten, die ein Foo liefert, das garantiert unveränderlich ist (eine unveränderliche Instanz sollte sich selbst zurückgeben; eine veränderbare Instanz sollte eine neue unveränderliche Instanz zurückgeben, die ihre Daten enthält) und wahrscheinlich ein "AsNewMutable" -Mitglied ( Dadurch wird eine neue veränderbare Instanz erstellt, die dieselben Daten enthält, unabhängig davon, ob das Original änderbar war oder nicht.)
Keine Klasse sollte ImmutableFoo und MutableFoo implementieren.
Wenn Ihre Objekte unveränderlich sein sollen (und Sie Ihre Anwendung um das Konzept der unveränderlichen Daten entwerfen), MÜSSEN Objekte wirklich unveränderlich bleiben.
Die kanonische Methode zum Ändern von Daten in unveränderlichen Szenarios besteht darin, neue Objekte zu erstellen. Daher würde ich Folgendes vorschlagen:
%Vor%Sie sollten ein Builder-Muster verwenden: Builder-Objekte erstellen unveränderliche Instanzen des Core-Objekts. .NET-Zeichenfolgen sind wie folgt - das Zeichenfolgenobjekt ist unveränderlich und es gibt eine StringBuilder-Klasse für die effiziente Konstruktion von Zeichenfolgenobjekten. (string + string + string ist viel weniger effizient als mit einem StringBuilder, um dasselbe zu tun)
Beachten Sie außerdem, dass Builder-Objekte ausschließlich zum Erstellen des Zielobjekts vorhanden sind - Builder sind keine Instanzen des Zielobjekts / Implementieren Sie die Zielschnittstelle nicht selbst.
Es lohnt sich, Ihr System auf unveränderlichen Objekten laufen zu lassen, da Unveränderlichkeit viele Probleme in Threading- / Parallelitäts- / parallelen Ausführungsszenarios sowie Daten-Caching- / Datenversionierungsszenarien beseitigt.
Tags und Links .net c# interface immutability