Unveränderliches Objektmuster in C # - was denkst du?

Zur info, der zweite Ansatz wird als "Eis am Stiel Unveränderlichkeit".

Eric Lippert hat eine Reihe von blog-Einträgen auf Unveränderlichkeit ab hier. Ich bin noch immer in den Griff mit der CTP (C# 4.0), aber es sieht interessant aus, was optional /named Parameter (zu den .ctor) hier machst (wenn zugeordnet readonly-Felder)...
[update: ich habe gebloggt auf dieser hier]

Für die info, hätte ich wahrscheinlich nicht machen, diese Methoden in virtual - wir möchten wahrscheinlich nicht, dass Unterklassen zu können, machen Sie es nicht-freezable. Wenn Sie wollen, dass Sie in der Lage sein, um hinzuzufügen extra-code, ich würde etwas vorschlagen wie:

[public|protected] void Freeze()
{
    if(!frozen)
    {
        frozen = true;
        OnFrozen();
    }
}
protected virtual void OnFrozen() {} //subclass can add code here.

Auch - AOP (wie PostSharp) könnte eine praktikable option für das hinzufügen all diese ThrowIfFrozen() überprüft.

(entschuldigt, wenn ich mich geändert habe-Terminologie /Methode Namen nicht ALSO halten Sie die original-post sichtbar, das beim schreiben von Antworten)

InformationsquelleAutor der Antwort Marc Gravell

Nachdem meine anfängliche Unbehagen über die Tatsache, dass ich hatte, um eine neue zu erstellen System.Drawing.Point auf jede änderung, ich habe ganz umarmte das Konzept vor einigen Jahren. In der Tat, mache ich nun jedes Feld als readonly standardmäßig nur ändern, dass es wandelbar ist, wenn es einen zwingenden Grund – die gibt es erstaunlich selten.

Ich nicht viel über cross-threading Probleme, obwohl (ich nur selten verwenden Sie den code, wo dies relevant ist). Ich finde es einfach viel, viel besser, weil der semantische Ausdruckskraft. Unveränderlichkeit ist der Inbegriff einer Schnittstelle, die schwer zu bedienen ist falsch.

InformationsquelleAutor der Antwort Konrad Rudolph

Die (relativ) neue Software-Design-Paradigma genannt, Domain Driven design, macht die Unterscheidung zwischen entity-Objekte und Wert-Objekte.

Entity-Objekte sind definiert als alles, was für die Zuordnung zu einer der Schlüssel-gesteuerten Objekts in einen persistenten datenspeicher, wie ein Mitarbeiter, oder ein client, oder eine Rechnung, etc..., wo das ändern der Eigenschaften des Objekts bedeutet, dass Sie brauchen, um die änderung zu speichern, um eine Daten irgendwo speichern, und die Existenz von mehreren Instanzen einer Klasse mit dem gleichen "key" imnplies müssen, um ihn zu synchronisieren oder koordinieren Ihre Beharrlichkeit, um die Daten zu speichern, so dass eine Instanz die änderungen nicht überschreiben die andere. Ändern der Eigenschaften einer Entität, Objekt bedeutet, Sie ändern etwas über die Objekt - nicht ändern, DAS Objekt, das Sie referenzieren...

Value-Objekte otoh, sind Objekte, die berücksichtigt werden können, unveränderlich sind, deren Dienstprogramm ist genau definiert durch die Eigenschaft-Werte, und für die mehrere Instanzen, müssen nicht koordiniert werden, in irgendeiner Art und Weise... wie Adressen oder Telefonnummern, oder die Räder eines Autos, oder die Briefe in ein Dokument... diese Dinge sind vollständig definiert durch Ihre Eigenschaften... einem Großbuchstaben 'A' - Objekt in einem text-editor ausgetauscht werden können transparent mit anderen Großbuchstaben 'A' - Objekt in dem Dokument, Sie brauchen nicht einen Schlüssel zur Unterscheidung von allen anderen 'A' In diesem Sinne ist es unveränderlich, denn wenn Sie es ändern, um ein " B " (wie das ändern der Telefonnummer string in einen Telefonnummer-Objekt, ändern Sie nicht die Daten, die im Zusammenhang mit einigen veränderliche Entität, Sie wechseln von einem Wert zum anderen... genauso, wenn Sie ändern Sie den Wert eines string -...

InformationsquelleAutor der Antwort Charles Bretana

Aufbauend auf den Punkt von @Cory Foy und @Charles Bretana, wo es einen Unterschied zwischen Entitäten und Werten. In der Erwägung, dass Wert-Objekte müssen immer unveränderlich sind, ich glaube nicht wirklich, dass ein Objekt sollte in der Lage sein, zu frieren, sich selbst, oder lassen sich eingefroren werden willkürlich in der codebase. Es hat einen wirklich schlechten Geruch zu ihm, und ich fürchte, es könnte schwer aufzuspüren, wo genau ein Objekt gefroren war, und warum war es gefroren, und die Tatsache, dass zwischen den anrufen auf ein Objekt, könnte es den Status ändern von aufgetaut, eingefroren.

Das ist nicht zu sagen, dass manchmal Sie wollen eine (veränderliche) Entität zu etwas, und sicherzustellen, dass Sie nicht gehen, um geändert werden.

So, statt einfrieren die Sache selbst, eine andere Möglichkeit ist das kopieren der Semantik von ReadOnlyCollection< T >

List<int> list = new List<int> { 1, 2, 3};
ReadOnlyCollection<int> readOnlyList = list.AsReadOnly();

Ihrem Objekt kann ein Teil als veränderlich, wenn es Sie braucht, und dann unveränderlich, wenn Sie es wünschen zu sein.

Beachten Sie, dass ReadOnlyCollection< T > implementiert auch ICollection< T > was hat ein Add( T item) Methode in der Schnittstelle. Es gibt jedoch auch bool IsReadOnly { get; } in der Schnittstelle definiert, so dass die Verbraucher überprüfen können, bevor Sie eine Methode aufrufen, die eine Ausnahme werfen.

Der Unterschied ist, dass Sie können nicht nur festlegen, IsReadOnly false. Eine Sammlung entweder sein oder nicht, Lesen Sie nur, und das ändert sich nie für die Lebensdauer der Kollektion.

Schön wäre es an Zeit, um die const-correctness, C++ haben Sie zur compile-Zeit, aber das beginnt zu haben eigene Probleme und ich bin froh, dass C# nicht gibt.

ICloneable - ich dachte, ich würde nur zurück zu verweisen, die folgenden:

Nicht ICloneable implementieren

Nicht verwenden, ICloneable in öffentlichen APIs

Brad Abrams - Design-Richtlinien, die Verwalteten code und die .NET Framework

InformationsquelleAutor der Antwort Robert Paulson

Mein problem mit diesem Muster ist, dass Sie nicht die Einführung einer compile-Zeit-Beschränkungen auf Unveränderlichkeit. Der Programmierer ist dafür verantwortlich, dass ein Objekt festgelegt ist, unveränderlich, bevor zum Beispiel hinzufügen, um einen cache oder einen anderen non-thread-safe-Struktur.

Deshalb würde ich verlängern diese Codierung Muster mit einer compile-Zeit Zurückhaltung in der form einer generischen Klasse, wie folgt:

public class Immutable<T> where T : IElement
{
    private T value;

    public Immutable(T mutable) 
    {
        this.value = (T) mutable.Clone();
        this.value.MakeReadOnly();
    }

    public T Value 
    {
        get 
        {
            return this.value;
        }
    }

    public static implicit operator Immutable<T>(T mutable) 
    {
        return new Immutable<T>(mutable);
    }

    public static implicit operator T(Immutable<T> immutable)
    {
        return immutable.value;
    }
}

Hier ist ein Beispiel, wie würden Sie diesen:

//All elements of this list are guaranteed to be immutable
List<Immutable<SampleElement>> elements = 
    new List<Immutable<SampleElement>>();

for (int i = 1; i < 10; i++) 
{
    SampleElement newElement = new SampleElement();
    newElement.Id = Guid.NewGuid();
    newElement.Name = "Sample" + i.ToString();

    //The compiler will automatically convert to Immutable<SampleElement> for you
    //because of the implicit conversion operator
    elements.Add(newElement);
}

foreach (SampleElement element in elements)
    Console.Out.WriteLine(element.Name);

elements[3].Value.Id = Guid.NewGuid();      //This will throw an ImmutableElementException

InformationsquelleAutor der Antwort Jos Bosmans

Hier ist ein neues video auf Channel 9, wo Anders Hejlsberg von 36:30 in dem interview reden beginnt Unveränderlichkeit in C#. Er gibt eine sehr gute Verwendung für Eis am Stiel Unveränderlichkeit und erklärt, wie dies ist etwas, das Sie sind derzeit erforderlich, um selber implementieren. Es war Musik in meinen Ohren hören ihn sagen, es ist Wert, darüber nachzudenken, bessere Unterstützung für die Erstellung von immutable Objekt-Graphen in zukünftige Versionen von C#

Experte zu Experte: Anders Hejlsberg - Die Zukunft von C#

InformationsquelleAutor der Antwort Lars Fastrup

Wie wäre es mit einer abstrakten Klasse ThingBase, mit Unterklassen MutableThing und ImmutableThing? ThingBase enthält alle Daten in einer geschützten Struktur, die Bereitstellung von öffentlichen nur-lese-Eigenschaften für die Felder und geschützten nur-lese-Eigenschaft, die für seine Struktur. Es würde auch eine überschreibbare AsImmutable Methode, die zurückkehren würde, ein ImmutableThing.

MutableThing würden Schatten die Eigenschaften mit lese - /schreib-Eigenschaften, und bieten sowohl einen Standard-Konstruktor und einen Konstruktor akzeptiert eine ThingBase.

Unveränderliche Sache sein würde, eine versiegelte Klasse, überschreibt AsImmutable einfach sich selbst zurückgeben. Es würde auch einen Konstruktor akzeptiert eine ThingBase.

InformationsquelleAutor der Antwort supercat

Können Sie optional verwenden benannte Argumente zusammen mit nullables, um ein unveränderliches Set-mit sehr wenig boilerplate. Wenn Sie wirklich wollen, um eine Immobilie zu null, dann haben Sie möglicherweise einige Probleme.

class Foo{ 
    ...
    public Foo 
        Set
        ( double? majorBar=null
        , double? minorBar=null
        , int?        cats=null
        , double?     dogs=null)
    {
        return new Foo
            ( majorBar ?? MajorBar
            , minorBar ?? MinorBar
            , cats     ?? Cats
            , dogs     ?? Dogs);
    }

    public Foo
        ( double R
        , double r
        , int l
        , double e
        ) 
    {
        ....
    }
}

Verwenden Sie es wie so

var f = new Foo(10,20,30,40);
var g = f.Set(cat:99);

InformationsquelleAutor der Antwort bradgonesurfing