2013-03-04 13 views
5

Co to jest konwencja/reguła/preferencja/dyktat o tym, gdzie należy zadeklarować zmienne prywatnych instancji i dlaczego?Gdzie ukryć swoich współlokatorów w celu C

// someClass.h 

@interface someClass : NSObject { 
@private 
// Here in the class declaration? 
} 
// ... 
@end 

// someClass.m 

@interface someClass() { 
// Here in the class extension? This seems to be obj-c's version 
// of the C++ Pimpl idiom. 
} 
@end 

@implementation someClass { 
// Here in the class definition? BTW, what's the default scope here? 
// Seems like it should be @private. I haven't been able to find much 
// documentation about this declaration block. 
} 
// ... 
@end 

ktoś może wypowiedzieć się na temat właściwego stosowania tych trzech sekcji lub punktu do dobrej zasobu sieciowego na ten temat? Dzięki!

+6

+1 za tytuł. – IronMan84

+0

Tytuł jest nieco bezczelny, ale poważnie podchodzę do tego pytania. Nie byłem w stanie znaleźć dokładnej dokumentacji na ten temat. Nic, co widziałem z książek (Kochan, Sadun, Ali) i doc do Apple'a, nie prowadzi do gruntownej dyskusji na ten temat. – Phil

+2

Domyślny zakres znaków iv w bloku '@ implementation' to' @ private'. Jednak prawie na pewno nie ma to znaczenia, ponieważ jeśli nie umieszczasz wielu klas w tym samym pliku '.m', żadne inne klasy nie mogą nawet * zobaczyć * ivars, co jest warunkiem koniecznym do uzyskania dostępu do nich. –

Odpowiedz

4

Dziś najlepiej jest umieścić je w klasie @implementation lub (niepublicznej).

Ivars nigdy nie są interesujące dla klientów klasy, więc nie powinny być widoczne w publicznym interfejsie API (nagłówek).

Nie ma dużej różnicy w umieszczaniu ich w @implementacji lub w rozszerzeniu klasy. Dla spójności zawsze umieszczam je w @implementacji.

+0

dla spójności zawsze umieszczam je w rozszerzeniu klasy. – vikingosegundo

+0

Kolejne pytanie, czy mogę: co byś poparł dla klas, które chcą eksponować zmienne instancji do podklas? Osobiście preferuję kategorię z odpowiednimi getterami i być może zadeklarowaną gdzie indziej niż w głównym nagłówku "public". – Tommy

+0

@Tommy Uważam to za przełamanie enkapsulacji. Inne klasy (podklasy lub nie) nigdy nie powinny uzyskiwać dostępu do plików ivars. –