Каковы преимущества использования средств доступа к экземплярам элементов IB? - PullRequest
1 голос
/ 13 ноября 2009

Обычно, когда нам нужно связать элемент интерфейса с полем класса, мы используем ключевое слово «IBOutlet» для информирования пре-компилятора:

@interface MyController : NSObject {
    IBOutlet NSWindow *theWindow;
}

и в реализации мы напрямую используем указатель theWindow для вызова методов класса NSWindow!

Но каковы преимущества того, что прекомпилятору предписывается создавать некоторые средства доступа к объекту, на который указывает «окно», и управлять объектом через средства доступа?

Пример:

@interface MyController : NSObject {
   NSWindow *theWindow;
}
@property(retain) IBOutlet NSWindow *theWindow;


@implementation MyController

@synthesize theWindow;

@end

Замедляет ли использование второго решения (для всех указателей на элементы интерфейса) производительность приложения?

Когда целесообразно использовать второй способ вместо первого?

Спасибо!

Ответы [ 4 ]

1 голос
/ 13 ноября 2009

Брайан прав в том, что вам нужно раскрывать свойства элемента пользовательского интерфейса, только если доступ к ним необходим из другого экземпляра или другого класса целиком. Это обычно является признаком проблемы архитектурного дизайна, но не всегда.

Чтобы ответить на два последних вопроса:

Замедляет ли использование второго решения (для всех указателей на элементы интерфейса) производительность приложения?

Нет. Не более чем добавление метода с именем -doSomethingReallyComplicated замедляет приложение, если этот метод никогда не вызывается. Он может замедлять запуск, имея кучу неиспользуемого кода (тем самым увеличивая размер двоичного кода без причины), и, безусловно, замедляет время компиляции, но не влияет на производительность приложения во время выполнения.

Когда целесообразно использовать второй способ вместо первого?

Как сказал Брайан, вы открываете элемент пользовательского интерфейса как свойство (через @synthesize или метод с ручным кодированием), когда вам нужно получить к нему доступ снаружи данного экземпляра этого класса. Опять же, необходимость сделать это обычно является признаком проблемы проектирования.

1 голос
/ 13 ноября 2009

Ну, в общем, я не сохраняю свойства, и единственный способ, которым я когда-либо даже выставляю Outlets, - это если кому-то нужен доступ к элементу извне, и это, в общем, плохой знак для вашего дизайна.

Я не пробовал этого, но у меня был бы соблазн синтезировать только часть чтения, и я, вероятно, использовал бы ее только там, где атомный доступ там, где это важно. Некоторые части AppKit не всегда безопасны для потоков.

0 голосов
/ 13 ноября 2009

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

Аксессор будет быстрее, так как вы избежите всех затруднений во время выполнения, чтобы найти нужный ивар. При этом, если вы не собираетесь загружать этот кончик снова и снова, разница будет незначительной.

Основная причина, по которой вы хотели бы получить доступ к розетке, такая же, как и для любого другого ивара или свойства, которое вы хотите опубликовать. Это удобный способ убедиться, что управление памятью покрыто должным образом.

0 голосов
/ 13 ноября 2009

Время, которое занимает аксессор, совершенно незаметно. Даже если бы вы запускали этот код миллионы раз, все механизмы IB положительно затмили бы его.

Если эти переменные установлены только в это время и никогда не доступны вне класса, средства доступа могут быть ненужными.

...