Xcode ora genera una categoria vuota. Perché?

Question

ho notato questo durante l'utilizzo di iOS6 beta 3

Quando creo una nuova sottoclasse di un UIViewContoller (senza altre classi genitore generano questo comportamento che ho notato), il file .m ora ha una categoria vuota in alto del file. In passato, quando ho imparato a conoscere le categorie, ho notato che alcune persone usavano questa stessa tecnica per indicare metodi privati ​​(anche se non veramente privati).

E 'questo l'intento? C'è stato qualche cambiamento nel rendere le cose effettivamente private adesso? Ho notato anche la direttiva @private.

Qual è lo stile di codifica personale per quanto riguarda i metodi e le private var?

AGGIORNAMENTO: Poiché XCode ci sta spingendo a utilizzare le estensioni di classe, sono andato avanti e li ho usati per metodi privati ​​/ ivar per questo progetto. Ho trovato un inconveniente però. Ho visto che potevo riutilizzare uno dei miei UIViewControllers sottoclassi insieme a tutti i suoi UIButtons, UILabels, ecc .... Avevo questa ereditarietà: UIViewController < - FirstViewController < - SecondViewController.

Beh, tutti i metodi privati ​​che ho messo nel prolungamento classe di FirstViewController non pop up nel completamento automatico quando ho codice in SecondViewController. Un leggero fastidio ....

Answer 1

ti riferisci a questa definizione di interfaccia:

@interface MYViewController() 
@end 

Questo è tecnicamente un'estensione di classe piuttosto che una categoria. Le categorie hanno una stringa all'interno delle parentesi. Le estensioni di classe vengono aggiunte alla classe in fase di compilazione, e quindi possono aggiungere ivars (di solito sotto forma di proprietà). Le categorie vengono aggiunte in fase di runtime e non è possibile aggiungere ivars.

Detto questo, il punto è corretto. Questo è usato per definire metodi e proprietà private.

Nel mondo ObjC, "privato" è un cartello "no trespassing", non un muro di filo spinato. Mentre c'è una parola chiave @private (che aggiunge l'applicazione del compilatore), si applica solo a ivars e generalmente non è necessaria. Questo tipo di privacy basata su avvisi funziona molto bene in ObjC ed è abbastanza sufficiente.

Inserisci le tue proprietà private in questa estensione di classe, e i chiamanti esterni riceveranno gli avvertimenti "potrebbe non rispondere al selettore" se tentano di accedervi (proprio come si farebbero per chiamare qualsiasi metodo non definito). Non dovresti mai permettere che gli avvertimenti esistano in un progetto ObjC, quindi questo impone l'incapsulamento dei dati.

---

EDIT

Se sono privati, allora non dovrebbero comparire nella sottoclasse. Quello che vuoi è protetto. Non esiste un grande schema per i metodi protetti in ObjC, ma una tecnica comune è metterli in una categoria in un file .h come MYViewController + Protected.h. Trovo che ciò avvenga molto raramente nella pratica, dal momento che gran parte del design di ObjC non è sottoclasse. Usa invece composizione e delega.

In merito a "Perché è sufficiente visualizzare i controller". Innanzitutto, non sono solo i controller di visualizzazione. Sono solo i controller di visualizzazione su iOS (beh, VC, TableViewController e GLKViewController). Su Mac, sono anche controllori di finestre e importatori di riflettori.Cerca in:

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

Ma perché quelli? Bene, quelli sono tutti controller, ed è insanamente comune che i controllori abbiano bisogno di proprietà private. In effetti, se non hai proprietà private in un controller, probabilmente stai facendo troppa pubblicità. Non è così universale per le classi di modelli e visualizzazioni. Sospetto che abbia giocato nella loro decisione. Potrebbero anche esserci persone diverse che hanno posseduto i modelli o che sono stati aggiornati in momenti diversi. A volte vedi piccole incongruenze che si attenuano nel tempo.

È possibile creare anche i propri modelli. Vedi Creating Custom Xcode 4 File Templates.