Objetivo-C Método privado Dilema

Soy consciente de que Objective-C no admite methods privados reales. Lo que estoy haciendo actualmente para declarar methods "privados" es agregar lo siguiente a los files .m de class:

@interface MyClass() - (void) privateMethodName; @end 

El problema:

Si ahora agrego una subclass y quiero usar este método 'privado', ¡no puedo! Me sale el error:

El tipo de receptor 'SubClassName', por ejemplo, el post no declara un método con el selector 'privateMethodName'

Entonces, si no quiero que las subclasss no puedan acceder a este método, pero quiero que las subclasss puedan hacerlo, ¿qué puedo hacer? ¿Cuál es la forma mejor / adecuada de lograr mi meta?

Podría separar la interfaz "protegida" de la pública. En el encabezado principal, solo declare los methods públicos:

MyMagicThingy.h :

 @interface MyMagicThingy: NSObject - (void) publicMethod; @end 

Luego, tenga un encabezado adicional con methods protegidos:

MyMagicThingy+Protected.h :

 #import "MyMagicThingy.h" @interface MyMagicThingy (Protected) - (void) protectedMethods; @end 

No puede tener methods privados / protegidos / públicos "reales" en el Objetivo C (como en: el comstackdor aplicará las reglas de acceso. Todos los methods son públicos). Tienes que ir con una convención.

Lo que describes es realmente un método protegido . Un enfoque para superar esto: Ivars puede ser declarado @public , @protected o @private . Puede declarar una instancia de ayudante protegida para restringir el acceso a las instancias derivadas, que luego invoca a través del object que lo contiene.

Otra alternativa en algunos casos sería hacer que las subclasss escriban en una interfaz, luego mantenga su implementación privada.

A veces, solo tiene que documentar "no hagas esto, a less que no seas una subclass" porque no forma parte del idioma. En esta mentalidad, uno de mis favoritos es un encabezado separado que declara una categoría de methods protegidos. Está bastante oculto de los clientes, pero puede ser visible para las subclasss mediante inclusión explícita: Dirk proporcionó un ejemplo de esto al mismo time, échale un vistazo.

Por último, si te sientes cómodo con ObjC ++, C ++ ofrece este control, por lo que puedes mezclar modos y visibilidad con bastante libertad.

Primero y ante todo

No se puede lograr que nadie pueda llamar a ningún método implementado en un object en Objective-C (al less no sin quemar a través de varias docenas de razors haciendo que Yaks sea less resistente a la intemperie).

Simplemente no llame a los methods que no están declarados en los files de encabezado públicos, como una convención (esto es, lo que ya está haciendo).

Segundo

La palabra pública en el párrafo anterior hace el truco:

En Objective-C (al less en su encarnación actual), la interfaz de una class se puede definir sobre cualquier cantidad de files de encabezado utilizando la técnica que acabas de describir en tu publicación: continuación de classs.

Un ejemplo de una class de marco de trabajo de Apple que lo haría sería UIGestureRecognizer con su encabezado de subclass separado UIGestureRecognizerSubclass.h .


PD:
El error que está viendo apesta a usar ARC, por lo que su time de ejecución es lo suficientemente reciente como para incluso usar múltiples files de implementación para eso.