Как избежать @ property-itis (т. Е. Чрезмерного использования свойств, когда они уместны)? - PullRequest
9 голосов
/ 12 ноября 2008

Objective-C 2.0 дал нам @ свойства.

  • Они допускают самоанализ.
  • Они допускают декларативное программирование.
  • Механизмы @synthesize и @dynamic избавляют пользователя от необходимости писать повторяющиеся стандартные средства доступа.
  • Наконец, есть синтаксис свойства «точка», который некоторые любят, а некоторые ненавидят.

Это не то, что я слышу, чтобы спросить. Как и любая новая функция, изначально существует тенденция к использованию везде @property. Так, где уместно использование собственности?

Очевидно, что в модельных объектах атрибуты и отношения являются хорошим кормом для свойств.

@property(...) NSString *firstName;
@property(...) NSString *lastName;
@property(...) Person *parent;

Даже синтезированные / вычисленные атрибуты кажутся хорошим вариантом использования свойств.

@property(...) NSString *fullName;

Где еще вы использовали свойства? Где вы их использовали, а потом решили, что это неуместное использование этой функции?

Используете ли вы свойства для атрибутов вашего частного объекта?

Можете ли вы вспомнить какие-либо примеры вещей, которые не являются свойствами в Какао, на первый взгляд кажется, что они могут быть свойствами, но после более тщательного изучения являются реальным примером злоупотребления или property-itis? 1025 *

Ответы [ 3 ]

7 голосов
/ 12 ноября 2008

Я рекомендую людям использовать собственность везде, где это возможно. Если вы работаете в платформе, возможность использовать не хрупкие переменные экземпляра в современной среде выполнения является огромным бонусом, а если вы этого не сделаете, свойства дают понять, как следует управлять вашими иварами (назначенные или сохраненные, а не скопированные) , При объявлении свойства нет потери производительности, за исключением времени, которое требуется для написания строки кода (я на самом деле использую фрагмент TextExpander, чтобы сделать это для меня), но потенциал для предотвращения ошибок достаточно велик, чтобы он стал фантастическая лучшая практика Если вы планируете использовать пользовательские свойства для частных иваров, вы можете сделать это внутри своего файла реализации с помощью блока @interface. Например

@interface MyObject()

@property(retain) NSArray *myArray;

@end
5 голосов
/ 12 ноября 2008

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

if (foobar.weight > 100) {
    goober.capacity = foobar.weight;
}

В этом примере foobar.weight вызывается дважды. Если он просто возвращает кэшированное значение, нет проблем. Но если ему нужно заблокировать поток во время развертывания робота, чтобы каждый раз вручную взвешивать панель foo, фрагмент кода, приведенный выше, потратит два развертывания робота, когда потребуется только один.

В таких случаях я бы рекомендовал НЕ использовать свойство, а также называть метод по-другому, чтобы код выглядел больше как:

int w = [foobar computeWeight];
if (w > 100) {
    goober.capacity = w;
}

С таким именем, как computeWeight, легче запомнить, что это длительная операция.

0 голосов
/ 18 ноября 2008

Я бы не использовал свойства, если метод доступа делает что-то неочевидное для объекта, например, устанавливает несвязанную переменную экземпляра. Также, если возвращаемое свойство на самом деле не «принадлежит» объекту. Например, в одном из моих проектов у меня есть метод stringValue, по которому я решил не создавать свойство по этой причине. Это действительно больше вопрос стиля.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...