Was ist der effizienteste Weg, um unveränderliche und veränderbare Versionen einer objective-c-Klasse zu machen?

Question

Angenommen, ich mache eine Objective-C-Klasse, die einen Bruch darstellt, und möchte unveränderliche und veränderbare Versionen erstellen.

Nach den Mustern im Foundation-Framework können Sie erwarten, dass die Methode fractionByAddingFraction: in der unveränderlichen Version und addFraction: in der änderbaren Version angezeigt wird.

Das Paradoxon, auf das ich stoße, ist, wie man nur die Bruchteil-addierende Logik einmal zwischen den zwei Klassen einschließt. Es scheint, dass die unveränderliche fractionByAddingFraction: Methode über die veränderbare addFraction: Methode wissen muss (und diese nutzen muss), um Code Duplikation zu vermeiden, und dennoch die veränderbaren Methoden in die Implementierung der unveränderlichen Klasse einbeziehend bedeutet, dass sie möglicherweise auf dem unveränderlichen aufgerufen werden könnten Objekt, das den Punkt besiegt.

Eine kurze Erklärung (oder noch besser, eine Fortsetzung dieses vereinfachten Beispiels) wäre sehr zu begrüßen!

Answer 1

Ihr Ansatz ist korrekt (wenn Sie wirklich eine veränderbare Unterklasse benötigen, die Sie vermeiden sollten, wenn Sie sie nicht wirklich brauchen). Ich bin nicht ganz klar, wo die Verwirrung hereinkommt. Sie würden am einfachsten implementieren addFraction: mit fractionByAddingFraction:. Es wäre ein wenig ineffizient, aber das ist die Richtung, die am sinnvollsten wäre. Etwas wie:

- (void)addFraction:(Fraction *)anotherFraction { 
    Fraction *newFraction = [self fractionByAddingFraction:anotherFraction]; 
    self.internalStuff = newFraction.internalStuff; 
} 

Aber in der Regel würden Sie wahrscheinlich dieses effiziente mit einiger privaten _GetInternalStuffByAddingInternalStuffs() Funktion behandeln, die beiden Klassen verwenden würden.

Answer 2

Die primären Implementierungen von Foundation-Sammlungen betrügen: Es gibt nur eine Implementierung, die eine Unterklasse von NSMutableFoo ist, und sie hat ein privates Veränderbarkeits-Flag. Dies bedeutet, Client-Code kann nicht testen, ob ein bestimmtes Objekt veränderbar ist oder nicht, aber das wäre sowieso nie eine gute Idee außer vielleicht für Debugging und Assertions.