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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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