Objective-c nowoczesne środowisko wykonawcze używające zarówno właściwości i ivars w bloku interfejsu

Question

Widziałem przykłady kodu (z książki Początek rozwoju iPhone 4), w których obie deklarują ivars wewnątrz bloku interfejsu, a następnie deklarują właściwości dla tego samego. W ten sposób:

@interface ViewController : UIViewController { 
    UITableView *table; 
} 

@property (nonatomic, retain) IBOutlet UITableView *table; 

Jaki byłby cel/korzyść z tego? Rozumiem, że przy nowoczesnej wersji środowiska wykonawczego (iPhone i 64-bitowe aplikacje OS X) wystarczy zadeklarować właściwości i można pominąć deklarując ivars wewnątrz bloku interfejsu. Zgodnie z odpowiedzią this w wątku similair będzie to do celów debugowania. Ale czy istnieją jakieś inne zalety oprócz debugowania, które można zastosować to podejście?

Cheers,

Peter

Answer 1

Jawnie deklarujące Ivars daje możliwość wewnętrznie użyć specjalistycznego typu dla ivar.

Typowym przykładem jest wewnętrznie zmienny obiekt, do którego można uzyskać dostęp z zewnątrz w sposób jednokrotny, niezmienny.

Przykład:

@interface Foo : NSObject 
@property (readonly) NSArray *bars; 
@end 

@implementation 
{ 
    NSMutableArray *bars; 
} 

@synthesize bars; 

- (void)addBar:(Bar *)bar 
{ 
    [bars addObject:bar]; 
} 
@end 

Oczywiście obiekt zwrócony z majątku bars naprawdę nie jest niezmienna. Ale chodzi o to, że API nie ujawnia swojej zmienności.

Zwróć uwagę, że użyłem nowego fantazyjnego stylu prywatnego-ivars-in-implementation. Jest to zależne od nowoczesnego środowiska wykonawczego, a także kompilatora clang.

Answer 2

Niektórzy programiści lubią definiować swoje iVary z nieco inną nazwą, aby odróżnić bezpośredni dostęp i dostęp KVC. Na przykład:

w ncurses.h

@interface ViewController : UIViewController { 
    UITableView *_table; 
} 

@property (nonatomic, retain) IBOutlet UITableView *table; 

aw .m

@synthesize table = _table; 

ten sposób bezpośredni dostęp do Ivar użyciu _table ale użyć syntetyzowane ustawiające i pobierające za pomocą [self table]

Answer 3

Ale czy są jakieś inne korzyści z wyjątkiem debugowania, które chcielibyście e takie podejście?

Ogłaszam Ivars wyraźnie do:

• kontroli dostępu (widoczność)
• organizacji
• jednolity napisany styl
• kompatybilność (hej, ten program może obsługiwać 32 bit jeden dzień)
• oraz dlatego, że wiążę właściwości w ramach publicznego interfejsu klasy (chociaż istnieją wyjątki) - nie tylko jako asce ssors do ivars klasy.

"wszystko jako własność odczytu/zapisu" jest zasadniczo wadliwe ood.