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

Question

Noté esto mientras usaba IOS6 BETA 3

Cuando creo una nueva subclase de un UIViewContoller (ninguna otra clase de los 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 las categorías, noté que algunas personas usarían esta misma técnica para indicar métodos privados (aunque no son verdaderamente privados).

¿Es eso lo que la intención está aquí? ¿Ha habido algún cambio para hacer que las cosas realmente sean privadas ahora? Noto la directiva @Private por ahí también.

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

Actualización: Dado que Xcode nos está empujando para usar las extensiones de clase, seguí adelante y los usé para métodos privados / IVAR para este proyecto. Sin embargo, encontré un inconveniente. Vi que podía reutilizar uno de mis Controladores UIVIEW subclasificados junto con todos sus udectons, UILABELLEL, etc. ... Tuve esta herencia: UIViewController <- FirstViewController <- SecondViewController.

Bueno, todos los métodos privados que pongo en la extensión de clase de FirstViewController no aparecen en el código automático cuando codifiquen en SecondViewController. Una ligera molestia ...

Answer 1

Te estás referil a esta definición de interfaz:

@interface MYViewController ()
@end

Esta 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 a tiempo de compilación, por lo que pueden agregar IVARS (generalmente en forma de propiedades). Las categorías se agregan en tiempo de ejecución y no pueden agregar IVARS.

Todo lo que decía, su punto es correcto. Esto se utiliza para definir métodos y propiedades privadas.

En el mundo del OBJC, "Privado" es un signo de "sin interrupción", no una pared de afeitar. Si bien hay una palabra clave @private (que agrega el cumplimiento del compilador), solo se aplica a los IVARS, y generalmente no es necesario. Este tipo de privacidad basada en advertencias funciona muy bien en el objc y es bastante suficiente.

Ponga sus propiedades privadas en esta extensión de clase, y las personas que llaman externas obtendrán "pueden no responder a las advertencias de selección" si intentan acceder a ellos (al igual que ellos obtendrían por llamar a cualquier método indefinido). Nunca debe permitir que existan advertencias en un proyecto OBJC, por lo que esto implica la encapsulación de datos.

---

editar

Si son privados, entonces no deben aparecer en su subclase. Lo que quieres está protegido. No hay un gran esquema para los métodos protegidos en el objc, pero una técnica común es ponerlos en una categoría en un archivo .h como MyViewController + Protected.h. Me parece que esto surge muy rara vez en la práctica, ya que gran parte del buen diseño de OBJC no subclase. Utiliza composición y delegación en su lugar.

con respecto a "Por qué simplemente ver controladores". Primero, no son solo los controladores. Es solo ver los controladores en iOS (Bueno, VC, TableviewController, y GlkViewController). En Mac, también son controladores de ventanas y importadores de proyectos. Mirar 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 ver. Sospecho que jugó en su decisión. También podría haber sido diferentes personas que poseían las plantillas, o que se actualizaron en diferentes momentos. A veces ves pequeñas inconsistencias que se alisan con el tiempo.

También puedes hacer tus propias plantillas. Consulte Creación de plantillas de archivos Xcode 4 personalizadas .