Veränderlichkeit in Objective-C und C ++ Muster entwerfen

Question

ein gewisse Entwicklung für das iPhone vor kurzem getan hat, ich bin gekommen, ein interessantes Design-Muster zu bemerken, viel im iPhone SDK verwendet wird, in Bezug auf Objekt Veränderlichkeit.

Es scheint, die typische Vorgehensweise gibt es eine unveränderliche Klasse NSFoo zu definieren, und dann leitet daraus eine veränderbare Nachkomme NSMutableFoo. Im Allgemeinen Mitglieder die NSFoo Klasse definiert Daten, Getter und Nur-Lese-Operationen, und die abgeleitete NSMutableFoo fügt auf Setter und mutiert Operationen.

Als vertraut mit C ++, ich konnte nicht umhin zu bemerken, dass dies eine komplette Gegenteil zu sein scheint, was ich tun würde, wenn Sie den gleichen Code in C ++ zu schreiben. Obwohl Sie sicherlich könnte , diesen Ansatz nehmen, wie es mir scheint, dass ein prägnanter Ansatz ist eine einzige Foo Klasse, Marke Getter und Nur-Lese-Operationen als const Funktionen zu erstellen, und auch die wandelbar Operationen implementieren und Setter in der gleichen Klasse. Sie würden dann mit einer wandelbaren Klasse am Ende, aber die Typen Foo const*, Foo const& etc alle effektiv die unveränderliche äquivalent sind.

Ich denke, meine Frage ist, tut mein nehmen auf die Situation sinnvoll? Ich verstehe, warum Objective-C macht die Dinge anders, aber gibt es Vorteile für die Zwei-Klassen-Ansatz in C ++, die ich verpasst habe? Oder bin ich dabei den Punkt ganz?

Nicht eine zu ernste Frage -. Mehr für meine eigene Neugier als alles andere

Answer 1

Objective-C ist zu dynamisch. In C ++ const-Qualifikation zur Übersetzungszeit durchgesetzt und jegliche Verletzungen der const-Qualifikation zur Laufzeit (wie beispielsweise ein const qualifizierten Objekt durch einen nicht const qualifizierten pointer modifizierenden) sind ein undefiniertes Verhalten.

Es ist teilweise der gleiche wie der Grund, warum gibt es keine privaten Methoden in Objective-C. Sie sind frei, was Mitteilung Sie auf ein beliebiges Objekt senden möchten. Die Laufzeit-Dispatch nimmt ein Objekt und eine Nachricht und löst einen Methodenimplementierung aufzurufen.

Wenn const qualifizierte Objekte const qualifizierte Methoden nur invoke könnte, wäre es völlig die dynamische Natur der Objective-C und Stiftung ruinieren, weil eine solche Überprüfung zur Laufzeit (erste Überprüfung durchgeführt werden müssten, würde bestimmen, ob die Nachricht an Entschlüssen gesendet werden eine konst qualifizierte Implementierung für diese bestimmte Instanz, und eine weitere Überprüfung, um zu bestimmen, ob die Instanz selbst war const qualifiziert). Betrachten Sie dieses theoretische Beispiel:

NSArray *mutableArray = [[NSArray alloc] init];

NSString *mutableString = @"I am a mutable string";
const NSString *immutableString = @"I am immutable because I am const-qual'd";

[mutableArray addObject:mutableString];
[mutableArray addObject:immutableString]; // what happens?!

// and what happens here (both immutable and mutable strings would respond
// to the same selectors because they are the same class):
[mutableArray makeObjectsPerformSelector:@selector(aMutableOperation)];

Plötzlich verliert man Dynamik. Wie es jetzt, wandelbar und unveränderliche Objekte ist, können in einer unveränderlichen oder veränderlichen Sammlung zusammen sitzen.

eine veränderbare Unterklasse Nachdem hält die dynamische Natur des Objective-C und hält die Laufzeit einfach. Es war ein ähnliches Thema vor einer Weile über private Methoden.

Answer 2

Die Gedanken ...

Mac, wie Sie wissen, in C ++, können Sie denken, von "A" und "const A", wie zwei verschiedenen Arten, mit ihren nur die Beziehungen zu sein

1. "A" und "A &" kann implizit auf "const A" gegossen werden und "const A &", etc ...
2. "const A &" kann auf "A &" const_cast werden, etc ...

Der Compiler übernimmt die Vererbung und die Ausbreitung des Typ Modifikator durch Ausdrücke, etc.

Ich würde vermuten, dass die NS-Leute die ..Mutable .. Konvention für ein paar Gründe gewählt haben. Meine erste Vermutung ist, dass ich glaube, dass, wenn Nextstep ursprünglich Pionierarbeit geleistet wurde, C keine Unterstützung für „const“ hatte und es immer noch nicht Objekt-Orientierung hat. Und was noch wichtiger ist, sie wollten bestimmte Optimierungen in ihren wandelbaren vs. unveränderlichen Objekt-Implementierungen. Zum Beispiel in einer unveränderlichen String-Klasse wie NSString, kann es zu „Pool“ Strings nützlich sein. Dies ermöglicht eine doppelte Strings zerstäubt und für den Prozess werden möglicherweise weniger Speicher zu verwenden. (Es hat gewisse Nachteile, aber es gibt immer Vor- und Nachteile.)

In C ++ Sie in der gleichen Richtung, indem zunächst Verständnis Kopf könnten copy-on-write . std :: string gesagt wird, dies zu tun.

Interessantes Thema,
Will Bradley