Confusione di definizione della classe C oggettiva

Question

Sto imparando Objective-C attraverso Cocoa (E amandolo). Sto seguendo un tutorial. C'è una classe chiamata Menu e l'interfaccia ha un aspetto simile a questo.

@interface Menu: MenuObject {} 
@end 

@interface MenuLayer : LayerObject {} 
-(void) someMethod:(id)sender 
-(void) someOtherMethod:(id)sender 
@end 

e le implementazioni seguono la stessa convenzione

@implementation Menu 
    -(id)init{ 
     // blah blah blah 
    } 
@end 

@implementation MenuLayer 
    // init, someMethod and someOtherMethod stuff here 
@end 

Il che mi si presenta come due oggetto separato/classi di essere definite e attuate negli stessi file. C'è una ragione per farlo? Il risultato sarebbe lo stesso se divido i file .h e .m su Menu.h/.m e MenuLayer.h/.m? O sto fraintendendo qualcosa di fondamentale?

Answer 1

Va bene se li dividi in file separati. La maggior parte delle volte in cui vedi le cose implementate in questo modo è solo perché le 2 classi sono così strettamente accoppiate che non si userebbe mai l'una senza l'altra.

Quindi, è davvero solo una cosa di stile. Non c'è "magia" nel fatto che siano entrambi definiti e implementati nello stesso file.

Answer 2

Questa è solo una questione di preferenze personali. Dovresti essere in grado di dividerli, purché tu abbia #import una delle intestazioni dall'altra se necessario. Objective-C ti dà semplicemente la possibilità di raggruppare le classi insieme in file, piuttosto che in Java, il che ti costringe a dividerli. Se le classi sono strettamente correlate, può essere più facile vedere come tutto funziona in un unico file, invece di dover passare da un gruppo all'altro.

Answer 3

La tua valutazione è corretta. Due classi separate vengono dichiarate e definite.

La ragione probabile per fare ciò è che entrambe le classi sono necessarie per fare tutto ciò che fa Menu. Avere entrambe le classi nella stessa intestazione e origine rende l'interfaccia più compatta.

La suddivisione in due file continuerà a funzionare.