iphone - español - ¿Cuál es la lógica detrás de tener versiones mutables e inmutables de clases como NSArray, NSDictionary, etc. en Objective C?
cocoa touch español (5)
¿Por qué las clases de recopilación comunes en Objective C como NSString, NSArray, NSDictionary, etc. tienen una versión mutable y otra inmutable?
El concepto se utiliza en idiomas relacionados. La distinción notable es que los tipos objc se denominan variantes mutables. lenguajes similares suelen lograr esto a través de la aplicación de una palabra clave, como const . Por supuesto, otros lenguajes relacionados también usan tipos que son explícitamente mutables o inmutables.
¿Cuál es la lógica detrás de definirlos por separado?
los mensajes de objc no distinguen entre const y non-const, y el lenguaje no proporciona soporte integrado para garantizar que el estado de un objeto no cambie (aunque realmente no sería una adición difícil si uno estuviera realmente inclinado a extender un compilador). así que hay un poco de historia involucrada aquí también.
por lo tanto, es una convención para la clase definir la inmutabilidad frente a la mutabilidad y proporcionar variantes que distinguen la mutabilidad.
Las abstracciones múltiples también introducen la seguridad y la intención del tipo.
Actuación
sí. hay múltiples optimizaciones que un objeto invariante puede hacer.
algunos casos incluyen:
- Podría almacenar los valores en caché, nunca computándolos más de una vez.
- Podría usar asignaciones exactas, no actualizables para sus datos.
- a menudo no necesita ningún código especial para el uso de subprocesos múltiples: muchos tipos inmutables solo mutarán durante la construcción / destrucción.
- estos tipos a menudo utilizan grupos de clase. si se implementa un clúster de clase, las implementaciones especializadas pueden proporcionar diferencias significativas en la memoria, la implementación, etc. Considere cómo una cadena inmutable con exactamente un carácter podría diferir de una variante mutable.
gestión de la memoria
algunos casos incluyen:
- Los tipos inmutables podrían compartir sus contenidos inmutables.
- también pueden reducir las asignaciones. por ejemplo, una implementación de
copyWithZone:oinitWithType:podría devolver la fuente retenida, en lugar de una copia física superficial o superficial.
¿O algo más?
Facilita la escritura de interfaces claras. Usted puede garantizar y (intentar) restringir algunas cosas. Si todo fuera mutable, habría muchos más errores que cometer y casos especiales. de hecho, la distinción podría cambiar por completo la forma en que abordamos la escritura de bibliotecas de objc:
[[textField stringValue] appendString:@" Hz"];
[textField stateDidChange];
por lo que es bueno poder pasar objetos sin preocuparse de que el cliente cambie detrás de su espalda, mientras evita copiar todo el lugar.
¿Por qué las clases de recopilación comunes en Objective C como NSString, NSArray, NSDictionary, etc. tienen una versión mutable y otra inmutable? ¿Cuál es la lógica detrás de definirlos por separado? ¿Rendimiento, gestión de memoria o cualquier otra cosa?
Aparte de las respuestas mencionadas anteriormente, una diferencia es: los objetos inmutables generalmente son seguros para subprocesos. Mientras que, los objetos mutables no son seguros para hilos.
Gracias
Básicamente, cuando sabes que una estructura de datos es inmutable, puedes hacer muchas optimizaciones alrededor de eso. Por ejemplo, si una matriz es inmutable, puede omitir todo el código que "haga crecer" la matriz cada vez que intente agregar un objeto, y simplemente puede hacer que su matriz inmutable sea una envoltura alrededor de una id[] .
En general, para una API, una clase inmutable será segura para subprocesos, por lo que puede leerla directamente en un subproceso en segundo plano sin preocuparse de que el contenido cambie ...
Eso importa más para cosas como una colección donde los contenidos pueden cambiar y es posible que estés en medio de enumerarlos.
Las versiones inmutables de las clases existen porque un objeto inmutable es, en sí mismo, un identificador único para un estado particular . Es decir, si tiene una NSArray de 100 instancias de NSString , esa instancia de NSArray se puede tratar como idempotente para cualquiera de esas cadenas.
Además, la inmutabilidad significa que un cambio no puede ocurrir después de que el estado haya sido vendido. Por ejemplo, el método de subviews devuelve una matriz inmutable, asegurando así que la persona que llama no va a jugar juegos con el contenido (ni tampoco espera poder hacerlo). Internamente, NSView podría optar por devolver la NSMutableArray [probable] que contiene las subvistas (ya que es internamente mutable) y la conversión a NSArray significa que la persona que llama no puede manipular el contenido sin una advertencia de reparto mal o mal. (Esto puede o no ser realmente la implementación real, por cierto, pero este patrón se usa en otros lugares).
La inmutabilidad también significa que la enumeración y / o recorrido se puede hacer sin riesgo de un cambio de estado en el medio. Del mismo modo, muchas clases inmutables también son explícitamente seguras para subprocesos; cualquier número de hilos puede leer simultáneamente el estado inmutable, a menudo sin necesidad de un bloqueo.