Xcode ahora genera una categoría vacía. ¿Por qué?

Question

Me di cuenta de esto durante el uso de iOS 6 beta 3

Cuando creo una nueva subclase de un UIViewContoller (no hay otras clases de padres generan este comportamiento que he notado), el archivo .m ahora tiene una categoría vacía en la parte superior del archivo. En el pasado, al aprender sobre categorías, noté que algunas personas usarían esta misma técnica para indicar métodos privados (aunque no verdaderamente privados).

¿Esa es la intención aquí? Ha habido algún cambio para hacer las cosas realmente privadas ahora? También veo la directiva @private.

¿Cuál es su estilo de codificación personal con respecto a los métodos y vars privados?

ACTUALIZACIÓN: Dado que XCode nos está presionando para usar las extensiones de clase, procedí y las usé para métodos privados/ivar para este proyecto. Encontré un inconveniente sin embargo. Vi que podía reutilizar uno de mis UIViewControllers subclase junto con todos sus UIButtons, UILabels, etc. Tenía esta herencia: UIViewController < - FirstViewController < - SecondViewController.

Bueno, todos los métodos privados que puse en la extensión de clase de FirstViewController no aparecen en la autocompletar cuando codigo en SecondViewController. Una pequeña molestia ....

Answer 1

te refieres a esta definición de interfaz:

@interface MYViewController() 
@end 

Esto es técnicamente una extensión de clase en lugar de una categoría. Las categorías tienen una cadena dentro de los paréntesis. Las extensiones de clase se agregan a la clase en el momento de la compilación y, por lo tanto, pueden agregar ivars (generalmente en forma de propiedades). Las categorías se agregan en tiempo de ejecución y no pueden agregar ivars.

Dicho todo esto, su punto es correcto. Esto se usa para definir métodos y propiedades privados.

En el mundo de ObjC, "privado" es un letrero de "no invasión", no una pared de alambre de púas. Si bien existe una palabra clave @private (que agrega la aplicación del compilador), solo se aplica a ivars y, en general, no es necesaria. Este tipo de privacidad basada en la advertencia funciona muy bien en ObjC y es bastante suficiente.

Coloque sus propiedades privadas en esta extensión de clase, y las personas que llamen recibirán advertencias de "no pueden responder al selector" si intentan acceder a ellas (como lo harían al llamar a cualquier método no definido). Nunca debe permitir que las advertencias existan en un proyecto ObjC, por lo que esto impone la encapsulación de datos.

---

EDITAR

Si son privados, entonces no deberían aparecer en la subclase. Lo que quieres está protegido. No hay un gran esquema para los métodos protegidos en ObjC, pero una técnica común es ponerlos en una categoría en un archivo .h como MYViewController + Protected.h. Encuentro que esto sale muy raramente en la práctica, ya que gran parte del buen diseño de ObjC no se subclasifica. Utiliza composición y delegación en su lugar.

En relación con "Por qué solo ver los controladores". Primero, no son solo los controladores de vista. Es solo ver los controladores en iOS (bueno, VC, TableViewController y GLKViewController). En Mac, también son controladores de ventanas e importadores de Spotlight.Mire en:

.../Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Templates 
.../Library/Xcode/Templates 

¿Pero por qué esos? Bueno, esos son todos los controladores, y es increíblemente común que los controladores necesiten propiedades privadas. De hecho, si no tiene propiedades privadas en un controlador, probablemente esté haciendo demasiado público. Eso no es tan universal de las clases de modelo y vista. Sospecho que jugó su decisión. También podría haber sido personas diferentes que poseían las plantillas, o que se actualizaron en diferentes momentos. A veces, ves pequeñas inconsistencias que se suavizan con el tiempo.

Puede hacer sus propias plantillas también. Ver Creating Custom Xcode 4 File Templates.