objective c - protocol - ¿Cuál es el daño de la anulación de la propiedad en Objective-C?

swift extension property

Question

Hay varias situaciones en las que puede anular la propiedad de una súper clase.

1. Declara una propiedad con el mismo nombre y el mismo atributo de su superclase ''(ya que si cambia el atributo, puede obtener una advertencia del compilador). Y puede sintetizar con un ivar que cree. ¿Para qué sirve esto? ¿O qué daño puede hacer?

2. Si una superclase declara una propiedad en una extensión de clase (una categoría sin nombre), es posible que no esté en el archivo de encabezado. Si no conoce esa propiedad del archivo de encabezado, puede declarar la misma propiedad de nombre con el atributo o la clase que desee. Pero el método setter / getter anulará los de esa "propiedad secreta". Creo que esto solo puede hacer daño. Pero como no sabe por el archivo de encabezado, ¿cómo puede evitar esto?

3. Puede declarar una propiedad en el archivo de encabezado como "readonly" y en la extensión de clase volver a declararla como "readwrite". Creo que esta es la situación que puede hacer el bien.

¿Mi entendimiento acerca de estas situaciones es correcto? Y no sé qué bien pueden hacer la primera y la segunda situaciones. Pero si quiero evitar la primera situación, puedo verificar si la subclase ya tiene la propiedad antes de declararla. Pero si la propiedad no está en el archivo de encabezado público, como en la segunda situación, simplemente no sé qué hacer.

Answer 1

Buena pregunta

1. El uso de esto es que usted como desarrollador debe saber lo que está haciendo en este momento y debe agregar personalizaciones a la propiedad de clase base. Y como sabe lo que está haciendo, llamará a la implementación del super s, a menos que tenga una buena razón para no hacerlo. La decisión de no llamar a super podría ser perjudicial, especialmente en situaciones en las que no sabe cómo se implementa la clase base.

2. Sí, esto es dañino, pero se puede evitar al no usar categorías y elegir cuidadosamente un nombre de propiedades o métodos y considerar prefijarlos.

3. Sí, tiene razón, eso es bueno para limitar el acceso a su propiedad.

Ejemplo para # 2

@interface UIView(PFXextended)
-(NSArray*)PFXGetSubviewsOfType:(Class)class;
@end

Answer 2

Hay un lugar adecuado para cada una de las situaciones que ha mencionado, con una frecuencia variable de uso en la naturaleza. Solo debes tener cuidado de no pisarte a ti mismo. Voy a ilustrar con ejemplos que personalmente he encontrado.

Subclase para anular intencionalmente una propiedad
En esta situación, como mencionó Joe, es mejor que sepa exactamente lo que está haciendo y no tiene otras opciones antes de anular una propiedad. Personalmente, he encontrado que generalmente es suficiente anular un solo setter o getter para que una propiedad ya existente logre la personalización, en lugar de volver a declarar y sintetizar la propiedad. Por ejemplo, considere una subclase UIView especializada que solo tiene sentido tener un fondo UIClearColor. Para hacer cumplir esto, puede anular -setBackgroundColor: solo para imprimir un mensaje de advertencia y luego no llamar a la implementación de super. Diré que nunca tuve una razón para anular completamente una propiedad, pero no diré que no podría ser una herramienta útil en algunos casos en los que necesite secuestrar una propiedad existente por completo.

Propiedad privada
Esto es más útil de lo que le das crédito. La alternativa a una propiedad privada es un simple ol ''ivar, con el que todos estamos familiarizados. Si este es un ivar que está cambiando con cierta frecuencia, terminarás con trozos de código que se ven así:

[_myIvar release], _myIvar = nil;

o:

[_myIvar release];
_myIvar = [someValue retain];

Si bien no se ve tan mal, el código de repetición de la gestión de la memoria como este se vuelve muy antiguo, muy rápido. Alternativamente, podríamos implementar el ejemplo anterior como una propiedad privada, con retención semántica. Esto significa que, sin importar qué, solo tenemos que:

self.myIvar = someValue;

Que es mucho más fácil en los ojos y los dedos después de un tiempo. Tiene razón al señalar que, dado que esta propiedad es invisible para el resto del universo, puede ser anulada accidentalmente por una subclase. Este es un riesgo inherente cuando se desarrolla en Objective-C, pero puede tomar medidas para hacer que el riesgo sea muy pequeño. Estas medidas son variaciones en la modificación del nombre de sus propiedades privadas de una manera predecible. Hay una infinidad de caminos que podría tomar aquí: digamos, por ejemplo, que es una política personal anteponer sus nombres de propiedad privada con sus iniciales y un guión bajo. Para mí, obtendría algo como mw_ivar y los correspondientes -setMW_ivar: y -mw_ivar . Sí, es estadísticamente posible que alguien pueda venir y anular accidentalmente ese nombre, pero en realidad no lo hará. Especialmente si tiene una forma de publicar sus prácticas para aquellos que pueden usar su código. Y, puedo decir con seguridad que Apple no ha ido y hecho propiedades privadas que fueron destrozadas de tal manera, por lo que estará seguro en ese frente también.

Publicamente Readonly, Private Readwrite
Esto es sólo una práctica estándar. Tienes razón en que es útil, y también que no es peligroso ya que la propiedad está en el encabezado. Cualquier persona que lo anule accidentalmente solo tiene la culpa de ellos mismos.