Написание чистого, совершенного кода для iPhone

Question

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

Я был вполне доволен результатами. Однако некоторые разработчики iPhone независимо друг от друга посоветовали мне отказаться от этого, так как говорят, что я пишу слишком много классов и слишком много методов. В разное время меня предупреждали:

• Стек взорвется
• Слишком большое количество классов будет замедлять работу iPhone (т.е. воспринимается пользователем)
• Вложенные вызовы методов снижают производительность (то есть воспринимаются пользователем)

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

Я хотел бы продолжить изучение и усовершенствование методов независимого программирования в области, которые хорошо мне помогали в прошлом, но при разработке на iPhone я не хочу идти по пути, который закончится с болью!

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

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

Answer 1

Вся проблема с замедлением работы OO-приложений заключается в том, что объект может выйти из-под контроля легче, чем стили структурированного программирования. Когда-то, прежде чем оптимизация вызова метода была улучшена, это могло иметь значение, особенно когда были сделаны косвенные (то есть виртуальные) вызовы.

Если ваши объекты часто используются, и у вас есть некоторые объекты более низкого уровня, которые вы часто вызываете, то, возможно, вы получите снижение производительности от их использования - но я говорю о миллионах вызовов (я видел некоторые ужасный код в моё время, неструктурированный, структурированный и ОО!). Вы также получите большее снижение производительности, если будете постоянно выделять и удалять партии (LOTS) объектов.

Единственный ответ, правда, это посмотреть. Если у вас есть объект, который выделен, удален в быстрой последовательности, затем оптимизируйте его (даже если он выглядит менее элегантно), если у вас есть объект, который вы вызываете его методы тысячи раз, то оптимизируйте и его тоже. (но после того, как вы выполните это измерение, вы измерите его производительность и улучшите медленные биты!)

Существует компромисс между «элегантным» кодом и кодом, который работает просто и быстро, не переходите ни в крайности, и с вами все будет в порядке.

Answer 2

У меня был похожий опыт при разработке довольно сложного приложения Blackberry. Мне тоже сказали избегать частого выделения объектов, внутренних классов и т. Д. Исходное приложение, которое мы имели, представляло собой неразрешимый беспорядок. Недавно я переписал приложение с акцентом на хороший дизайн ОО (шаблоны, где это необходимо, множество одноцелевых и часто неизменяемых объектов и т. Д.). Во многих местах я нарушал совет избегать определенных «дорогостоящих» конструкций и распределения объектов. Полученное приложение было не только проще в обслуживании, но и было меньше. Если дополнительные выделения объектов создают какие-либо издержки, я, конечно, не заметил. Я думаю, что урок здесь именно то, что сказал Кнут. Сосредоточьтесь сначала на хорошем дизайне, а затем оптимизируйте при необходимости. Кроме того, эти мобильные устройства в настоящее время имеют достаточно памяти, чтобы этот совет, как мы надеемся, потерял популярность ...

Answer 3

Для меня это действительно сводится к ремонтопригодности. с помощью кода хорошего качества вы сможете намного легче поддерживать систему.

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

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

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

Answer 4

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

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