Variables de instancia de IBOutlet en archivos de implementación (.m)

Question

Digamos que tengo un controlador de vista, o un controlador de ventana, que es (como es habitual) el "Propietario del archivo" en un archivo XIB correspondiente.

Es (como todos saben) muy común tener IBOutlet s en la clase de controlador que luego puede conectar en el XIB utilizando el Interface Builder.

Hasta ahora, he estado creando variables de instancia IBOutlet en mis archivos de interfaz (.h). Pero (como todos saben) IBOutlet s son muy a menudo un mecanismo privado de la clase de controlador; los extraños ni siquiera deberían saber sobre ellos.

Es por esto que ahora, desde que Objective-C recientemente comencé a ofrecer la capacidad para hacerlo, quiero poner todos mis IBOutlet en mis archivos de implementación (.m).

Intenté hacer esto, y esto parece funcionar bien. Mis preguntas son estas: ¿Por qué funciona esto? Tenía la impresión de que Interface Builder solo podía ver los archivos de cabecera de la clase, no echar un vistazo a sus archivos de implementación. ¿Me equivoco? ¿Cómo es que Interface Builder puede "ver" en los archivos de implementación? ¿Podría ser potencialmente peligroso poner IBOutlet variables de instancia en los archivos de implementación?

Answer 1

De Xcode 4 User Guide

Nota: Debido a Xcode 4 analiza tanto sus archivos de cabecera y aplicación archivos de indexación, se pueden definir acciones y puntos de venta en aplicación (.m) archivos sin necesidad de colocarlos en el archivo de encabezado y puede hacer las conexiones directamente desde el archivo de punta en el archivo de implementación . Por lo tanto, no necesita exponer partes de su interfaz o acciones a clientes que puedan estar utilizando sus clases.

Y para ¿Podría ser potencialmente peligroso poner variables de instancia de IBOutlet en los archivos de implementación?

Sí, pero no tanto como se puede acceder a cualquier método declarado debido a la falta de acceso-ámbito en el tiempo de ejecución. Incluso si el método no es accesible, la resolución se realiza en tiempo de ejecución y no se adjunta información de alcance de acceso al método. Eso podría haber sido implementado, pero Objective-C carece de private, protected y así sucesivamente como en C++ o Java. Tenga en cuenta que la implementación de dicho comportamiento sería mucho más lenta en el tiempo de ejecución.