Делают ли накладные расходы метода target-c нецелесообразным подход к проектированию «множества маленьких методов»?

15

Я вообще предпочитаю использовать небольшие методы, как это рекомендовал Боб Мартин из Чистого кода . Я также прочитал достаточно о внутренностях Objective C, чтобы иметь хоть какое-то представление о том, как работает его отправка сообщений ( серия bbums особенно информативна в этом).

Несмотря на преждевременную оптимизацию, я хотел бы знать, является ли вся эта работа, которую Objective-c выполняет с objc_msgSend, с практической точки зрения достаточно значимой, чтобы подход «многих небольших методов» был нецелесообразным для проектов Objective-C.

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

осветление

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

(Для чего это стоит, я сейчас пишу Objective-C и использую небольшие методы)

Дальнейший запрос

Я согласен с обоими ответами, которые были даны. Еще одна вещь, которую я хотел бы, чтобы кто-то указал мне на (надеюсь существенную) открытую (или иным образом видимую) кодовую базу Objective-C, которая использует хорошие короткие методы (и небольшие классы). Я еще не видел ничего в Objective-C, чтобы сравнить его (например) с источником фитнеса .

Cris
источник
1
У Майка Эша есть несколько приятных постов с номерами для Leopard и iOS . Я не полностью переварил их, но может показаться, что для кэшированных IMP накладные расходы незначительны, и даже в отправках, требующих поиска, они довольно малы. Если это быстрое впечатление верное, может показаться, что небольшие методы могут стоять или падать на тех же основаниях проектирования в ObjC, что и на любом другом языке.
Крис
1
Если вы хотите избежать этих издержек, используйте функции C.
правостороннее
Технически возможно, но многое потеряно с функциями. Я бы заменил методы только функциями для целевых, чувствительных к производительности частей кода. Я спрашиваю здесь о том, достаточно ли проблематичны накладные расходы, чтобы пересмотреть предпочтительный стиль кодирования / дизайна.
Крис
См. Стоимость отправки сообщения в Objective-C для SO, чтобы найти хорошие ответы.
Калеб
Почему вы просто не профилируете свой код в Xcode? Я понимаю, что вы спрашиваете абстрактно, а не о конкретном коде, но, поскольку вы, очевидно, получили некоторый код с множеством небольших методов, почему бы не запустить его и убедиться в этом самим?
Калеб

Ответы:

4

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

Но, как обычно, ваш пробег может отличаться ...

Jordão
источник
Конечно, я согласен со всем этим (см. Ссылку «Дядя Боб» в этом вопросе). Но если язык не поддается вообще к определенному лучшем случае подход к дизайну, программисты могли бы сделать другой выбор. Я не видел много кода Objective C, который действительно следует за маленькими методами (и классами, если на то пошло), и мне интересно, почему. Я добавлю примечание к вопросу.
Cris
@Cris: «Я не видел много кода Objective-C, который действительно следует маленьким методам» -> Просто любопытно: из какой части кода вы сделали такой вывод? Я верю в это, но я также считаю, что это не из-за осведомленности о микрооптимизации, а из-за того, что программисты не уделяют внимания принципам хорошего дизайна и удобства обслуживания. Иными словами, их Java, C #, Ruby или любой другой код должны следовать той же практике ...
Иордан
Да, это вполне возможно. Я не имел в виду какую-то конкретную кодовую базу; только то, на что я смотрел за год или около того, я работал с Objective-C. Самым большим набором кода, на который я смотрел, был материал с открытым исходным кодом группы Omni и IIRC, у которого было много больших методов. Пример кода Apple также часто делает. Но, конечно, (а) пример кода является именно этим, и (б) мой образец может быть взвешен по отношению к коду пользовательского интерфейса, в частности, к контроллерам, и они могут быть закодированы иначе, чем на более глубоких уровнях.
Cris
2

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

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

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

Майкл Боргвардт
источник