Ab wann werden unveränderliche Klassen zur Last?

Beim Entwerfen von Klassen, die Ihr Datenmodell enthalten sollen, kann es hilfreich sein, unveränderliche Objekte zu erstellen. Ab wann wird die Belastung durch Konstruktorparameterlisten und tiefe Kopien jedoch zu groß, und Sie müssen die unveränderliche Einschränkung aufgeben?

Zum Beispiel ist hier eine unveränderliche Klasse, um eine benannte Sache darzustellen (ich verwende C # -Syntax, aber das Prinzip gilt für alle OO-Sprachen)

class NamedThing
{
    private string _name;    
    public NamedThing(string name)
    {
        _name = name;
    }    
    public NamedThing(NamedThing other)
    {
         this._name = other._name;
    }
    public string Name
    {
        get { return _name; }
    }
}

Benannte Objekte können erstellt, abgefragt und in neue benannte Objekte kopiert werden, der Name kann jedoch nicht geändert werden.

Das ist alles in Ordnung, aber was passiert, wenn ich ein weiteres Attribut hinzufügen möchte? Ich muss dem Konstruktor einen Parameter hinzufügen und den Kopierkonstruktor aktualisieren. Das ist nicht zu viel Arbeit, aber die Probleme beginnen, soweit ich sehen kann, wenn ich ein komplexes Objekt unveränderlich machen möchte .

Wenn die Klasse möglicherweise Attribute und Sammlungen enthält, die andere komplexe Klassen enthalten, scheint mir die Konstruktorparameterliste ein Albtraum zu werden.

Ab wann wird eine Klasse zu komplex , um unveränderlich zu sein?

Wann werden sie zur Last? Sehr schnell (insbesondere, wenn Ihre Sprache keine ausreichende syntaktische Unterstützung für die Unveränderlichkeit bietet.)

Unveränderlichkeit wird als Königsweg für das Multicore-Dilemma und all das verkauft. Die Unveränderlichkeit in den meisten OO-Sprachen zwingt Sie jedoch dazu, künstliche Artefakte und Methoden in Ihr Modell und Ihren Prozess einzufügen. Für jede komplexe unveränderliche Klasse müssen Sie einen (zumindest intern) gleich komplexen Builder haben. Egal wie Sie es entwerfen, es führt immer noch eine starke Kopplung ein (daher haben wir einen guten Grund, sie einzuführen.)

Es ist nicht unbedingt möglich, alles in kleinen, nicht komplexen Klassen zu modellieren. Also für große Klassen und Strukturen, können wir sie künstlich aufzuteilen - nicht , weil das Gefühl in unserem Domain - Modell macht, sondern weil wir mit ihrer komplexen Instanziierung und Bauherr in Code zu tun haben.

Es ist noch schlimmer, wenn Menschen die Idee der Unveränderlichkeit in einer Allzwecksprache wie Java oder C # zu weit führen und alles unveränderlich machen. Infolgedessen werden Konstrukte mit s-Ausdrücken in Sprachen erzwungen, die solche Dinge nicht mühelos unterstützen.

Engineering ist der Akt der Modellierung durch Kompromisse und Kompromisse. Alles durch Erlass unveränderlich zu machen, weil jemand liest, dass alles in der funktionalen Sprache X oder Y (einem völlig anderen Programmiermodell) unveränderlich ist, ist nicht akzeptabel. Das ist keine gute Technik.

Kleine, möglicherweise einheitliche Dinge können unveränderlich gemacht werden. Komplexere Dinge können unveränderlich gemacht werden, wenn es Sinn macht . Aber Unveränderlichkeit ist keine Wunderwaffe. Die Fähigkeit, Fehler zu reduzieren, die Skalierbarkeit und Leistung zu verbessern, ist nicht die einzige Funktion der Unveränderlichkeit. Es ist eine Funktion der richtigen Ingenieurpraxis . Schließlich haben die Leute gute, skalierbare Software ohne Unveränderlichkeit geschrieben.

Unveränderlichkeit wird sehr schnell zu einer Last (sie erhöht die zufällige Komplexität), wenn sie ohne Grund ausgeführt wird, wenn sie außerhalb dessen erfolgt, was im Kontext eines Domänenmodells sinnvoll ist.

Zum einen versuche ich es zu vermeiden (es sei denn, ich arbeite in einer Programmiersprache mit guter syntaktischer Unterstützung).

Ich habe eine Phase durchlaufen, in der darauf bestanden wurde, dass der Unterricht, wo immer möglich, unveränderlich ist. Hatte Builder für so ziemlich alles, unveränderliche Arrays usw. Ich fand die Antwort auf Ihre Frage einfach: Ab wann werden unveränderliche Klassen zur Last? Sehr schnell. Sobald Sie etwas serialisieren möchten, müssen Sie in der Lage sein, es zu deserialisieren, was bedeutet, dass es veränderlich sein muss. Sobald Sie ein ORM verwenden möchten, bestehen die meisten von ihnen darauf, dass Eigenschaften veränderbar sind. Und so weiter.

Ich habe diese Richtlinie schließlich durch unveränderliche Schnittstellen zu veränderlichen Objekten ersetzt.

class NamedThing : INamedThing
{
    private string _name;    
    public NamedThing(string name)
    {
        _name = name;
    }    

    public NamedThing(NamedThing other)
    {
        this._name = other._name;
    }

    public string Name
    {
        get { return _name; }
        set { _name = value; }
    }
}

interface INamedThing
{
    string Name { get; }
}

Jetzt ist das Objekt flexibel, aber Sie können dem aufrufenden Code immer noch mitteilen, dass diese Eigenschaften nicht bearbeitet werden sollen.

Ich glaube nicht, dass es eine allgemeine Antwort darauf gibt. Je komplexer eine Klasse ist, desto schwieriger ist es, über ihre Statusänderungen nachzudenken, und desto teurer ist es, neue Kopien davon zu erstellen. Ab einer gewissen (persönlichen) Komplexität wird es zu schmerzhaft, eine Klasse unveränderlich zu machen / zu halten.

Beachten Sie, dass eine zu komplexe Klasse oder eine lange Liste von Methodenparametern Designgerüche an sich sind, unabhängig von der Unveränderlichkeit.

Daher besteht die bevorzugte Lösung normalerweise darin, eine solche Klasse in mehrere unterschiedliche Klassen zu unterteilen, von denen jede für sich veränderlich oder unveränderlich gemacht werden kann. Wenn dies nicht möglich ist, kann es wandelbar gemacht werden.

Sie können das Kopierproblem vermeiden, wenn Sie alle Ihre unveränderlichen Felder in einem inneren speichern struct. Dies ist im Grunde eine Variation des Erinnerungsmusters. Wenn Sie dann eine Kopie erstellen möchten, kopieren Sie einfach das Erinnerungsstück:

class MyClass
{
    struct Memento
    {
        public int field1;
        public string field2;
    }

    private readonly Memento memento;

    public MyClass(int field1, string field2)
    {
        this.memento = new Memento()
            {
                field1 = field1,
                field2 = field2
            };
    }

    private MyClass(Memento memento) // for copying
    {
        this.memento = memento;
    }

    public int Field1 { get { return this.memento.field1; } }
    public string Field2 { get { return this.memento.field2; } }

    public MyClass WithNewField1(int newField1)
    {
        Memento newMemento = this.memento;
        newMemento.field1 = newField1;
        return new MyClass(newMemento);
    }
}

Hier arbeiten ein paar Dinge. Unveränderliche Datensätze eignen sich hervorragend für die Multithread-Skalierbarkeit. Grundsätzlich können Sie Ihren Speicher erheblich optimieren, sodass ein Parametersatz eine Instanz der Klasse ist - überall. Da sich die Objekte nie ändern, müssen Sie sich nicht um die Synchronisierung kümmern, wenn Sie auf ihre Mitglieder zugreifen. Das ist gut. Wie Sie jedoch betonen, benötigen Sie eine gewisse Veränderlichkeit, je komplexer das Objekt ist. Ich würde mit folgenden Überlegungen beginnen:

• Gibt es einen geschäftlichen Grund, warum ein Objekt seinen Zustand ändern kann ? Beispielsweise ist ein in einer Datenbank gespeichertes Benutzerobjekt aufgrund seiner ID eindeutig, es muss jedoch in der Lage sein, den Status im Laufe der Zeit zu ändern. Wenn Sie hingegen die Koordinaten in einem Gitter ändern, ist dies nicht mehr die ursprüngliche Koordinate. Daher ist es sinnvoll, die Koordinaten unveränderlich zu machen. Gleiches gilt für Streicher.
• Können einige der Attribute berechnet werden? Kurz gesagt, wenn die anderen Werte in der neuen Kopie eines Objekts eine Funktion eines Kernwerts sind, den Sie übergeben, können Sie sie entweder im Konstruktor oder bei Bedarf berechnen. Dies reduziert den Wartungsaufwand, da Sie diese Werte beim Kopieren oder Erstellen auf dieselbe Weise initialisieren können.
• Wie viele Werte bilden das neue unveränderliche Objekt? Irgendwann wird die Komplexität des Erstellens eines Objekts nicht mehr trivial, und an diesem Punkt können mehrere Instanzen des Objekts zu einem Problem werden. Beispiele hierfür sind unveränderliche Baumstrukturen, Objekte mit mehr als drei übergebenen Parametern usw. Je mehr Parameter vorhanden sind, desto größer ist die Möglichkeit, die Reihenfolge der Parameter zu verfälschen oder die falsche aufzuheben.

In Sprachen, die nur unveränderliche Objekte unterstützen (z. B. Erlang), ist das Endergebnis eine neue Kopie des Objekts mit dem aktualisierten Wert, wenn eine Operation den Status eines unveränderlichen Objekts zu ändern scheint. Wenn Sie beispielsweise einen Artikel zu einem Vektor / einer Liste hinzufügen, gehen Sie wie folgt vor:

myList = lists:append([[1,2,3], [4,5,6]])
% myList is now [1,2,3,4,5,6]

Das kann eine vernünftige Art sein, mit komplizierteren Objekten zu arbeiten. Wenn Sie beispielsweise einen Baumknoten hinzufügen, ist das Ergebnis ein neuer Baum mit dem hinzugefügten Knoten. Die Methode im obigen Beispiel gibt eine neue Liste zurück. In dem Beispiel in diesem Absatz wird tree.add(newNode)ein neuer Baum mit dem hinzugefügten Knoten zurückgegeben. Für die Benutzer wird es einfach, damit zu arbeiten. Für die Bibliotheksschreiber wird es langweilig, wenn die Sprache das implizite Kopieren nicht unterstützt. Diese Schwelle liegt in Ihrer eigenen Geduld. Für die Benutzer Ihrer Bibliothek liegt das vernünftigste Limit, das ich gefunden habe, bei drei bis vier Parameterobergrenzen.

Wenn Sie mehrere Endklassenmitglieder haben und nicht möchten, dass sie allen Objekten ausgesetzt werden, die sie erstellen müssen, können Sie das Builder-Muster verwenden:

class NamedThing
{
    private string _name;    
    private string _value;
    private NamedThing(string name, string value)
    {
        _name = name;
        _value = value;
    }    
    public NamedThing(NamedThing other)
    {
        this._name = other._name;
        this._value = other._value;
    }
    public string Name
    {
        get { return _name; }
    }

    public static class Builder {
        string _name;
        string _value;

        public void setValue(string value) {
            _value = value;
        }
        public void setName(string name) {
            _name = name;
        }
        public NamedThing newObject() {
            return new NamedThing(_name, _value);
        }
    }
}

Der Vorteil ist, dass Sie auf einfache Weise ein neues Objekt mit nur einem anderen Wert eines anderen Namens erstellen können.

Ab wann wird eine Klasse zu komplex, um unveränderlich zu sein?

Meiner Meinung nach lohnt es sich nicht, kleine Klassen in Sprachen wie der von Ihnen gezeigten unveränderlich zu machen . Ich benutze hier kleine und nicht komplexe , denn selbst wenn Sie dieser Klasse zehn Felder hinzufügen und damit wirklich ausgefallene Operationen ausführen, bezweifle ich, dass es Kilobyte oder Megabyte oder Gigabyte dauern wird class kann einfach eine billige Kopie des gesamten Objekts erstellen, um das Original nicht zu verändern, wenn es keine externen Nebenwirkungen verursachen soll.

Persistente Datenstrukturen

Ich persönlich verwende die Unveränderlichkeit für große, zentrale Datenstrukturen, die eine Reihe von wichtigen Daten wie Instanzen der Klasse, die Sie anzeigen, wie eine, die eine Million speichert, zusammenfassen NamedThings. Durch die Zugehörigkeit zu einer persistenten Datenstruktur, die unveränderlich ist und sich hinter einer Schnittstelle befindet, die nur Lesezugriff erlaubt, werden die zum Container gehörenden Elemente unveränderlich, ohne dass die Elementklasse ( NamedThing) damit umgehen muss.

Günstige Kopien

Die persistente Datenstruktur ermöglicht es, Bereiche davon zu transformieren und eindeutig zu machen, wodurch Änderungen am Original vermieden werden, ohne dass die Datenstruktur in ihrer Gesamtheit kopiert werden muss. Das ist das Schöne daran. Wenn Sie naiv Funktionen schreiben möchten, die Nebenwirkungen vermeiden, die eine Datenstruktur eingeben, die Gigabyte Speicherplatz beansprucht und nur einen Megabyte-Speicherplatz verändert, müssen Sie das ganze Freaking-Ding kopieren, um zu vermeiden, die Eingabe zu berühren und ein neues zurückzugeben Ausgabe. Entweder kopieren Sie Gigabyte, um Nebenwirkungen zu vermeiden, oder verursachen Nebenwirkungen in diesem Szenario, sodass Sie zwischen zwei unangenehmen Optionen wählen müssen.

Mit einer dauerhaften Datenstruktur können Sie eine solche Funktion schreiben und vermeiden, dass eine Kopie der gesamten Datenstruktur erstellt wird. Die Ausgabe erfordert nur etwa ein Megabyte zusätzlichen Speicher, wenn Ihre Funktion nur den Speicher eines Megabytes transformiert.

Belastung

Was die Bürde angeht, so gibt es zumindest in meinem Fall eine unmittelbare. Ich brauche diese Builder, von denen die Leute sprechen oder "Transienten", wie ich sie nenne, um Transformationen in diese massive Datenstruktur effektiv ausdrücken zu können, ohne sie zu berühren. Code wie folgt:

void transform_stuff(MutList<Stuff>& stuff, int first, int last)
{
     // Transform stuff in the range, [first, last).
     for (; first != last; ++first)
          transform(stuff[first]);
}

... muss dann so geschrieben werden:

ImmList<Stuff> transform_stuff(ImmList<Stuff> stuff, int first, int last)
{
     // Grab a "transient" (builder) list we can modify:
     TransientList<Stuff> transient(stuff);

     // Transform stuff in the range, [first, last)
     // for the transient list.
     for (; first != last; ++first)
          transform(transient[first]);

     // Commit the modifications to get and return a new
     // immutable list.
     return stuff.commit(transient);
}

Im Gegenzug zu diesen beiden zusätzlichen Codezeilen kann die Funktion jetzt sicher über Threads mit derselben ursprünglichen Liste aufgerufen werden, verursacht keine Nebenwirkungen usw. Außerdem ist es sehr einfach, diesen Vorgang zu einer nicht rückgängig zu machenden Benutzeraktion zu machen, da die Undo kann nur eine billige, flache Kopie der alten Liste speichern.

Ausnahmesicherheit oder Fehlerbehebung

Nicht jeder profitiert in solchen Kontexten so sehr von persistenten Datenstrukturen wie ich (ich habe sie in Undo-Systemen und bei der zerstörungsfreien Bearbeitung, die zentrale Begriffe in meiner VFX-Domäne sind, so häufig verwendet), aber eine Sache, die für ungefähr gilt Jeder, der berücksichtigt werden muss, ist Ausnahmesicherheit oder Fehlerbehebung .

Wenn Sie die ursprüngliche Mutationsfunktion ausnahmesicher machen möchten, ist eine Rollback-Logik erforderlich, für die die einfachste Implementierung das Kopieren der gesamten Liste erfordert :

void transform_stuff(MutList<Stuff>& stuff, int first, int last)
{
    // Make a copy of the whole massive gigabyte-sized list 
    // in case we encounter an exception and need to rollback
    // changes.
    MutList<Stuff> old_stuff = stuff;

    try
    {
         // Transform stuff in the range, [first, last).
         for (; first != last; ++first)
             transform(stuff[first]);
    }
    catch (...)
    {
         // If the operation failed and ran into an exception,
         // swap the original list with the one we modified
         // to "undo" our changes.
         stuff.swap(old_stuff);
         throw;
    }
}

Zu diesem Zeitpunkt ist die ausnahmesichere veränderbare Version noch rechenintensiver und wahrscheinlich noch schwieriger zu schreiben als die unveränderliche Version, die einen "Builder" verwendet. Und viele C ++ - Entwickler vernachlässigen die Ausnahmesicherheit einfach und das ist vielleicht in Ordnung für ihre Domain, aber in meinem Fall möchte ich sicherstellen, dass mein Code auch im Falle einer Ausnahme korrekt funktioniert (selbst wenn ich Tests schreibe, die absichtlich Ausnahmen auslösen, um Ausnahmen zu testen Sicherheit), und das macht es so, dass ich in der Lage sein muss, alle Nebenwirkungen, die eine Funktion hervorruft, rückgängig zu machen, wenn etwas auslöst.

Wenn Sie ausnahmesicher sein und Fehler ordnungsgemäß beheben möchten, ohne dass Ihre Anwendung abstürzt und brennt, müssen Sie alle Nebenwirkungen, die eine Funktion im Falle eines Fehlers / einer Ausnahme verursachen kann, rückgängig machen. Und da kann der Builder tatsächlich mehr Programmiererzeit sparen, als es kostet, zusammen mit Rechenzeit, weil:

In einer Funktion, die keine Nebenwirkungen verursacht, müssen Sie sich keine Gedanken mehr über das Zurücksetzen von Nebenwirkungen machen!

Also zurück zur Grundfrage:

Ab wann werden unveränderliche Klassen zur Last?

Sie sind immer eine Belastung für Sprachen, bei denen es mehr um Veränderbarkeit als um Unveränderlichkeit geht. Deshalb sollten Sie sie meiner Meinung nach dort einsetzen, wo der Nutzen die Kosten deutlich überwiegt. Aber auf einer Ebene, die breit genug für ausreichend große Datenstrukturen ist, gibt es meines Erachtens viele Fälle, in denen dies einen angemessenen Kompromiss darstellt.

Auch in meinem Fall habe ich nur wenige unveränderliche Datentypen und alle sind riesige Datenstrukturen, die eine große Anzahl von Elementen speichern sollen (Pixel eines Bildes / einer Textur, Entitäten und Komponenten eines ECS und Eckpunkte / Kanten / Polygone von ein Netz).