Comments
Имхо, Pure MVC под ObjC надо обходить за версту. У меня складывается впечатление, что его разработчики увидели впервые Objective-C и iOS/OsX именно при портировании.
PureMVC ломает типичный подход UIKit, когда UIViewController является контроллером, а UIView, соответственно, вью. В терминах PureMVC UIViewController это View, а UIVIew существует вообще где-то сбоку.

В копилку плохого кода, который порождает PureMVC в кривых неопытных руках: govnokod.ru/9614
При этом всём версия под Java для постороннего взгляда кажется значительно вменямее.

В целом я с вами согласен, PureMVC — неслабое такое испытание для неокрепшей психики.
Однако
1. На околоигровые проекты, ориентированные не на UIKit, а, например на Cocos 2D он ложится чуточку лучше.
2. Пожалуй это одно из основных достоинств ПурМВЦ — что он позволяет говнокодить ГОДАМИ и при этом иметь приемлемое время на внесение изменений.

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

P.S. ваш пример говнокода не очень-то Pure-MVC специфичен) обычный антипаттерн God-Class — класс со слишком большим количеством ответственности)
В любом случае, в чём
somethingManager = (TCSomethingManager*) [[ECApplicationFacade getInstance] retrieveProxy:[TCSomethingManager NAME]];
лучше, чем
somethingManager = [TCSomethingManager sharedManager];
я не понимаю.
На мой взгляд практический любой велосипед, реализующий MVC-паттерн будет лучше, чем PureMVC. Ну или возможен вариант, что в том проекте, откуда я беру примеры, его просто «неправильно приготовили».
Ничем не лучше — синглтон — он и есть синглтон — и это громадный недостаток PureMVC, однако несмотря на обилие способов приготовить его неправильно — приготовить правильно его возможно. И вызов этих самых «синглтонов» при правильном приготовлении увеличивает связность не более чем обычный Объектно-ориентированный код
На мой взгляд, проблема реализации PureMVC именно в плохих архитектурных решениях и незнаниях возможностей фреймворка.
PureMVC заставляет писать тонны бойлерплейта, которые, вообще говоря, не нужны.
Так же в нём есть куча велосипедов: там написали свой NSNotification и свой NSNotificationCenter.
А уж выуживание объектов по строковому ключу — вообще за гранью добра и зла.
Спасибо за статью! Подчерпнул для себя много интересных фич :)
На самом деле, в самом начале статьи, я подумал, что Вы будете рассматривать каждый фреймворк или фичу подробнее и с примерами. Но было очень круто и так, как есть на самом деле.
К сожалению, я лентяй :-(
И с одной стороны, вроде, набрался приличный набор знаний, которые можно шарить с разработчиками, а с другой стороны недостаточно мотивации для того, чтобы разобрать их все в максимально подробной форме. Поэтому, по итогам этой статьи я бы хотел еще и определить для себя — на чем сфокусироваться в будущих статьях.
Спасибо за отзыв :-)
Ну и да, еще раз, во всех разобранных проектах есть просто изумительная документация с множеством примеров использования. Моей задачей было среди огромного множества наработок в этой сфере — указать на те, которые по моему мнению заслуживают подробного изучения.
Ну и да, еще раз, во всех разобранных проектах есть просто изумительная документация с множеством примеров использования
Кроме, как минимум, BloodMagic, потому что я тоже
К сожалению, я лентяй :-(
:)
Собственно, вместо фьючурсов вполне можно использовать github.com/ReactiveCocoa/ReactiveCocoa, правда там уровень вхождения немалый
Согласен, о чем и написал в статье — промисы — это более узкий пример реактивного программирования и работы с потоками данных. Этот фреймворк полезен тем, что позволяет сконцентрироваться на более узкой области прежде, чем переходить к более фундаментальной ReactiveCocoa.
В первой и второй главе перечислены прекрасные инструменты, позволяющие превратить простой и читабельный код в говно.
Only those users with full accounts are able to leave comments. Log in, please.