Приватный ivar в @interface или @implementation

Question

Есть ли причина объявить личный ивар в @interface вместо @implementation?

Я вижу такой код по всему Интернету (включая документацию, предоставленную Apple ):

foo.h

@interface Foo : NSObject {
@private
    id _foo;
}
@end

Foo.m

@implementation Foo
// do something with _foo
@end

Заголовочный файл определяет открытый интерфейс класса, тогда как приватный ivar ... ну ... приватный. Так почему бы не объявить это так?

foo.h

@interface Foo : NSObject
@end

Foo.m

@implementation Foo {
@private
    id _foo;
}

// do something with _foo
@end

Answer 1

Объявление переменных экземпляра в @implementation является недавней функцией Obj-C, поэтому вы видите много кода с ними в @interface - другого выбора не было.

Если вы используете компилятор, который поддерживает объявление переменных экземпляра в реализации, объявляющей их, вероятно, лучший вариант по умолчанию - помещайте их в интерфейс, только если они должны быть доступны для других.

Редактировать: Дополнительная информация

Переменные экземпляра, объявленные в реализации, являются неявно скрытыми (фактически частными), и видимость нельзя изменить; ошибки (по крайней мере, с текущим Clang), но игнорируются.

Answer 2

Вы бы предпочли @interface, если вам нужна поддержка компилятора для более старых систем или выпусков Xcode.

Если вы уверены, что вам не понадобится эта обратная совместимость, я бы сказал, что лучше поместить ее в @implementation.

• Я думаю, @private - это хороший вариант по умолчанию.
• Он минимизирует время компиляции и уменьшает зависимости, если вы правильно его используете.
• Вы можете уменьшить большую часть этого шума в верхней части заголовка. Многие люди ставят #imports для своих ivars, но они должны использовать предварительное объявление по умолчанию. Таким образом, вы можете удалить из заголовка много #imports и много предварительных объявлений.

Answer 3

Директивы @public, @protected и @private не являются обязательными в target-C, они являются подсказками компилятора о доступности переменных. НЕ ОГРАНИЧИВАЕТ ВАМ доступ к ним.

пример:

@interface Example : Object
{
@public
int x;
@private
int y;
}
...


...
id ex = [[Example alloc ] init];
ex->x = 10;
ex->y = -10;
printf(" x = %d , y = %d \n", ex->x , ex->y );
...

Компилятор gcc выдает:

Main.m: 56: 1: предупреждение: переменная экземпляра 'y' равна @private;в будущем это будет серьезной ошибкой

Main.m: 57: 1: предупреждение: переменная экземпляра 'y' равна @private;в будущем это будет серьезной ошибкой

один раз для каждого "несоответствующего" доступа к "частному" члену y, но все равно компилируется.

Когдазапустите, вы получите

x = 10 , y = -10

Так что на самом деле вы НЕ должны писать код доступа таким образом, но поскольку objc является надмножеством C, синтаксис C работает просто отлично, и всеклассы прозрачны.

Вы можете настроить компилятор так, чтобы эти предупреждения воспринимались как ошибки и залог, но цель C не установлена ​​внутри для такой строгости.Диспетчеризация динамического метода должна была бы проверять область действия и разрешение для каждого вызова (slooooowwwww ...), поэтому помимо предупреждения во время компиляции система ожидает, что программист соблюдает область видимости элемента данных.

Существует несколькоТрюки, чтобы получить конфиденциальность членов в цель-C.Один из них - убедиться, что вы поместили интерфейс и реализации вашего класса в отдельные файлы .h и .m, соответственно, и поместили элементы данных в файл реализации (файл .m).Тогда файлы, импортирующие заголовки, не имеют доступа к элементам данных, а только к самому классу.Затем укажите методы доступа ( или не ) в заголовке.Вы можете реализовать функции установки / получения в файле реализации для диагностических целей, если хотите, и они будут вызываться, но прямого доступа к членам данных не будет.

пример:

@implementation Example2 :Object
{ 
 //nothing here
}
double hidden_d; // hey now this isn't seen by other files.
id classdata;    // neither is this.

-(id) classdata { return [classdata data]; } // public accessor
-(void) method2 { ... }
@end

// this is an "informal category" with no @interface section
// these methods are not "published" in the header but are valid for the class

@implementation Example2 (private)
-(void)set_hidden_d:(double)d { hidden_d = d; }

// You can only return by reference, not value, and the runtime sees (id) outside this file.
// You must cast to (double*) and de-reference it to use it outside of this file. 
-(id) hidden_d_ptr { return &hidden_d;}
@end

...
[Main.m]
...
ex2 = [[Example2 alloc] init];

double d = ex2->hidden_d; // error: 'struct Example2’ has no member named ‘hidden_d’
id data = ex2->classdata; // error: 'struct Example2’ has no member named ‘classdata’
id data = [ex2 classdata] // OK

[ex2 set_hidden_d : 6.28318 ]; // warning:'Example2' may not respond to '-set_hidden_d:'

double* dp = [ex2 hidden_d_ptr]; // (SO UGLY)  warning: initialization from incompatible pointer type
                                 // use (double*)cast -- <pointer-to-pointer conversion>  
double d = (*dp); // dereference pointer (also UGLY). 

...

Компилятор выдаст предупреждения для таких вопиющих махинаций, но продолжит и будет верить, что вы знаете, что делаете (на самом деле?), И что у вас естьпричины (ты?).Кажется, много работы?Ошибка склонна?Yay Детка!Попробуйте сначала выполнить рефакторинг своего кода, прежде чем прибегать к волшебным трюкам C и операции с фрикадельками, как это.

Но это так.Удачи.