framework español iphone objective-c cocoa-touch init

iphone - framework - cocoa touch español



La mejor manera de evitar que otros programadores llamen-init (5)

Al diseñar una jerarquía de clases, a veces la subclase ha agregado un nuevo método initWithSomeNewParam , y sería conveniente deshabilitar las llamadas al método init antiguo heredado de la superclase.

En primer lugar, he leído la pregunta here , donde las alternativas propuestas son anular init para lanzar una excepción en tiempo de ejecución, o anular y establecer valores predeterminados para las propiedades. En mi caso, no quiero proporcionar valores predeterminados, y quiero indicar claramente que no se debe llamar al método anterior, y en su lugar se debe usar el método nuevo con parámetros.

Por lo tanto, la excepción de tiempo de ejecución está bien, pero a menos que el código sea depurado, no hay forma de que otros programadores en el equipo se den cuenta de que ya no se pretende utilizar el método anterior.

Si estoy en lo cierto, no hay forma de marcar un método como "privado". Entonces, aparte de agregar comentarios, ¿hay una manera de hacer esto?

Gracias por adelantado.



Para agregar a lo que @DarkDust publicó, también puede usar UNAVAILABLE_ATTRIBUTE

- (id)init UNAVAILABLE_ATTRIBUTE;

Esto generará un error cuando un usuario intente llamar a init en una instancia de esta clase.


Puede clasificar un método como "privado" definiendo una extensión privada para su clase.

En tu .h:

@interface MyClassName - (void)initWithSomeNewParam:(id)param;

En tu .m:

@interface MyClassName () - (void)init; @end

También puede agregar una declaración NSLog para que cuando alguien ejecute el proyecto con una sesión XCode adjunta, verá una salida de consola similar a "No use init , use initWithSomeNewParam: lugar". Tenga en cuenta que este es el enfoque que el propio Apple ha tomado históricamente para las llamadas de API en desuso (así como el marcado en desuso en sus documentos).


Puede marcar explícitamente su init como no disponible en su archivo de encabezado:

- (id) init __unavailable;

o:

- (id) init __attribute__((unavailable));

Con la última sintaxis, incluso puede dar una razón:

- (id) init __attribute__((unavailable("Must use initWithFoo: instead.")));

El compilador luego emite un error (no una advertencia) si alguien intenta llamarlo.


initWith: Stuff y: OtherStuff nunca deben ser más que constructores de conveniencia.

En que efectivamente deben llamar

self = [self init]; if(self) { self.stuff = Stuff; self.other = OtherStuff; }

por lo que [objeto init] siempre devolverá un objeto en un estado predefinido, y [objeto initWithStuff: stuff] devolverá el objeto en el estado predefinido con cosas sobrescritas.

Básicamente, a lo que me refiero es que es una mala práctica desalentar a [object init] especialmente cuando alguien subclasifica tu subclase en el futuro ...