Вызов функции вместо самостоятельного обмена сообщениями - когда что использовать? - PullRequest
Новая
       8

Вызов функции вместо самостоятельного обмена сообщениями - когда что использовать?

7 голосов
/ 07 июня 2011

В Objective-C, когда я хочу вызвать подпрограмму, я отправляю сообщение объекту, например:

[self mySubroutine:myParameter];

Существует (незначительное?) Снижение производительности, поэтому я мог бы просто использовать вызов функции в стиле C:

mySubroutine(myParameter);

Реализация последнего будет тогда находиться вне контекста класса @implementation.

Это нет-нет? Это распространено? Есть ли передовая практика по этому вопросу?

Ответы [ 2 ]

7 голосов
/ 07 июня 2011

Обратите внимание, что они не обязательно эквивалентны.Поскольку -mySubroutine является методом экземпляра, ему, вероятно, необходим доступ к данному экземпляру.В этом случае ваша функция mySubroutine() должна иметь и другой параметр для экземпляра.

В общем, используйте метод.Если вас беспокоит производительность, 1 вы всегда можете получить IMP для метода и использовать его как функцию вместо стандартной инфраструктуры диспетчеризации сообщений Objective-C.

Есть некоторые недостатки использования функций:

  • Они не могут быть переопределены подклассами;
  • Нет самоанализа (при использовании среды выполнения для получения списка методов, объявленных Objective-Cкласс, функции не перечисляются);
  • Они не могут использоваться как средства доступа / мутаторы объявленных свойств;
  • Они не видны для Кодировка значения ключа ;
  • Они не могут напрямую использоваться для пересылки сообщений Objective-C;
  • Они не могут напрямую использоваться в различных случаях, когда API-интерфейс Cocoa ожидает селектор (например, при использовании NSTimer).

Некоторые преимущества использования функций:

  • Они не могут быть переопределены подклассами (если вы хотите предотвратить это);
  • Там нет самоанализа (если выхочу для предотвращения этого);
  • Они могут быть встроенными;
  • Они могут иметь область видимости файлов (static), предотвращая доступ к ним кода из других файлов.

1 Когда вы определили, что инфраструктура отправки сообщений является узким местом.Это действительно происходит;например, некоторые аудио-примеры Apple не используют Objective-C для обработки аудио.

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

2 голосов
/ 07 июня 2011

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

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

Вы также можете столкнуться с проблемами пространства имен. С Objective-C разные классы могут совместно использовать имена методов, а с подходом c все ваши функции будут нуждаться в разных сигнатурах.

Лично я всегда использовал бы методы target-c, разница в производительности будет незначительной.

...