и ей я пользуюсь и return вместо break я пользуюсь, что в этом плохого? Если оно есть, значит гдето его можно использовать. Вы писали когда нибудь на ассамблере?
2. Хорошее предложение, на самом деле в Картотеке использовались паттерны и очень активно, но в разделении кода почти не было необходимости, то есть там где код отличался координально было удобнее разделить на подклассы, а если разница всего в две строки неохото было наследовать, и фабричными методами переопределять поведение, согласитесь?
3. я бы сказал парадигма одна, контролы и суп из них отличаются. Суть в том что кода надо будет настолько больше переписывать, что я лично не вижу делать его единым. Но не об этом статья, и не будет под Mac Картотеки, уверяю вас. Статья про iOS.
4. Вы уверены что UISplitViewController можно для этого расширить? Дело в том что ограничения стоят на уровне архитектуры. Я читал много статей о нем и все писали свои варианты, ни видел я даже попыток его расширить. Многие компоненты Apple не поддаются дресировки, именно потому что написаны на месадж-ореентированном языке, как это не звучит странно
еще раз повторюсь — это неизбежно, и актуально для продуктов с требованиями к ресурсам. Радуйтесь что вам не предлагают на асемблере писать как альтернативу
я хочу сказать что там где платформы почти идентичны, код почти один, писать кучу классов для того чтобы блюсти все почести ООП не разумно, нужно пользоваться уметь не только ООП, но и макросами. goto кстати еще жив в objective-c :-)
По соотношениям Количество кода/Ошибки, Время разработки/читаемость кода, Масштабиремость / Быстрота исполнения в конкретном продукте я посчитал макросы идеальным решением
Был спор по GOTO, зло ли это? Нужно ли его использовать? Кароче спор никто не выйграл, но языки программирования начали от него избавлятся. Типо чтобы народ не шубуршил и фигней не страдал с обсуждениями. :-)
контент с Web-сервиса приходит на русском, соответственно приложение не может быть никаким кроме русского. Кстати интересно, что xCode 4 насильно заставляет использовать механизм интернационализации, генеря подпапку en по умолчанию
практика поиска ошибок с макрасами элементарная — во первых умные IDE затеняют ветви препроцесоров, которые не будут исполнятся, во вторых есть дебагер, который пошагово проходит нужные строки.
Я просто сталкивался с С/С++ многоплатформенными библиотеками такими как OpenCV, BOOST и не боюсь макросов, и вам рекомендую не переживать, они бывают неизбежны и очень полезны.
Web-сервис выплевывает json громадный, его разумеется вместо того чтобы держать в памяти парсят в sqlLite и потом как вы пишете — все верно, но этож както черезчур много делать. Много операций.
> Это в теории. На практике, у всех девайсов на iOS достаточно много памяти, чтобы плевать на это.
в сравнении с Android да, но я на практике встречал задачи для iOS, в которых памяти нехватает и постоянно происходят Memory Warnings, соответственно виджеты перезагружаются и это сказывается на быстродействии
согласен, в MVP по сути предлагается контроллер как то так упрознить, чтобы его функцию связывания урезать, чтобы этот код связывания уменьшить и чтобы его не нужно было поддерживать-тестировать каждый раз
ну что вам так не нравятся ifdef, сравните количество символов ifdef и количество строк новых классов, мне кажется числа будут сопостовимы, это вам не JAVA а Objective-C. Язык на котором писалась NEXT Step, помните в 80-х как там все в 3D крутилось? Технологиие обогнавшие десятилетия. Думаете не было тогда макросов? Кстати сейчас картотеку портируют под Android и есть проблемы с памятью… нет, это конечно же не из-за того что там нет макросов
мне кажется четких граний нет, эти границы начинаешь ощущать когда у тебя неожиданно вырастает код UIViewController и сыпятся warnings со словами типо вы забыли объявленные классы связать с визуальным представлением в контроллере, при добавлении новых компонентов. А впринципе как не назови все одно — меньше связанностей — больше свободы :-)
разницы в написании кода практически нет, но вот в продукте конечном…
макросы позволяют на этапе копиляции убрать ненужный код в конечном приложении, ну например объявили вы массив в iPad для класса и где небудь держите миллион экземпляров этого класса, оно надо iPhone?, память нужно экономить у мобилок
Или метод вызывается в цикле миллион итераций, а в методе надо делать проверку? Насколько все замедлится?
1. Вы все таки не согласны что макросы это правилно в данном контексте, когда критична память и процессор?
2. Паттерны в статье предлагается открыть для себя самостоятельно, это значит что в данном контексте они не используются, у вас не возникает вопроса почему?
3. «А если Вы захотите еще настольную MAC версию сделать ??? еще одна ветка ??? или заново все писать ???» Вот тут вы себе противоречите, как раз будет куча веток классов наследования, каждый композитор будет перенаследован, кроме того будет написано куча обслуживающего кода: адапторы, фабрики. Кроме того поедит производительность. Кроме того стоит учитывать тот факт что iPhone/iPad — почти идентичные платформы, следовательно код у них почти одинаков, меняется представление и чаще всего оно всего лишь расширяется для iPad. А под Mac используются совершенно другие компоненты и поведение, для него можно портировать только МОДЕЛЬ. Впринципе модель можно портировать под любую платформу.
4. Свои компоненты чаще всего неизбежны за счет ограничений стандартных. Чего тут спорить? Ну никак нельзя UISplitViewController посадить на навигатор, что вы предложите в замен?
хорошее предложение, поскольку Proxy не сильно утежелит MPMusicPlayerController, я думаю. Но в местах, где быстродействие критично — определите свой макрос в проекте и пользуйтесь им. Кстати метод Krypt рекомендован Apple
Вы предлагаете использовать паттерн Adapter, есть еще куча паттернов, которые помогают объектную модель сделать проще и отказавшись от линейной модели программирования сделать код более понятной. В статье кстати написано, кстати, что вы их сами изучите, и соответственно сами будете их использовать. Здесь уклон в другую сторону: в сторону быстродействия (НУ ОЧЕНЬ КРИТИЧНО) и минимизации кода. Представте что вы своим насследованием потяните кучу изменений классов. В Картотеке например присутствует 6-уровневое наследование виджетов, что каждую ветвь перенаследовать? Кстати паттерны учат нас избегать наследования в пользу композиции, это так — к слову.
3. я бы сказал парадигма одна, контролы и суп из них отличаются. Суть в том что кода надо будет настолько больше переписывать, что я лично не вижу делать его единым. Но не об этом статья, и не будет под Mac Картотеки, уверяю вас. Статья про iOS.
4. Вы уверены что UISplitViewController можно для этого расширить? Дело в том что ограничения стоят на уровне архитектуры. Я читал много статей о нем и все писали свои варианты, ни видел я даже попыток его расширить. Многие компоненты Apple не поддаются дресировки, именно потому что написаны на месадж-ореентированном языке, как это не звучит странно
4.
По соотношениям Количество кода/Ошибки, Время разработки/читаемость кода, Масштабиремость / Быстрота исполнения в конкретном продукте я посчитал макросы идеальным решением
Был спор по GOTO, зло ли это? Нужно ли его использовать? Кароче спор никто не выйграл, но языки программирования начали от него избавлятся. Типо чтобы народ не шубуршил и фигней не страдал с обсуждениями. :-)
Как вы думаете насчет перспектив макросов?
Я просто сталкивался с С/С++ многоплатформенными библиотеками такими как OpenCV, BOOST и не боюсь макросов, и вам рекомендую не переживать, они бывают неизбежны и очень полезны.
в сравнении с Android да, но я на практике встречал задачи для iOS, в которых памяти нехватает и постоянно происходят Memory Warnings, соответственно виджеты перезагружаются и это сказывается на быстродействии
макросы позволяют на этапе копиляции убрать ненужный код в конечном приложении, ну например объявили вы массив в iPad для класса и где небудь держите миллион экземпляров этого класса, оно надо iPhone?, память нужно экономить у мобилок
Или метод вызывается в цикле миллион итераций, а в методе надо делать проверку? Насколько все замедлится?
А где был замечен впервые MVP?
2. Паттерны в статье предлагается открыть для себя самостоятельно, это значит что в данном контексте они не используются, у вас не возникает вопроса почему?
3. «А если Вы захотите еще настольную MAC версию сделать ??? еще одна ветка ??? или заново все писать ???» Вот тут вы себе противоречите, как раз будет куча веток классов наследования, каждый композитор будет перенаследован, кроме того будет написано куча обслуживающего кода: адапторы, фабрики. Кроме того поедит производительность. Кроме того стоит учитывать тот факт что iPhone/iPad — почти идентичные платформы, следовательно код у них почти одинаков, меняется представление и чаще всего оно всего лишь расширяется для iPad. А под Mac используются совершенно другие компоненты и поведение, для него можно портировать только МОДЕЛЬ. Впринципе модель можно портировать под любую платформу.
4. Свои компоненты чаще всего неизбежны за счет ограничений стандартных. Чего тут спорить? Ну никак нельзя UISplitViewController посадить на навигатор, что вы предложите в замен?