Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 3
Весьма любопытно, спасибо. У самого опыт работы с фреймворком не слишком большой, заметил несколько моментов для обсуждения, и буду рад комментариям.
На сколько я помню, при выбранном подходе NSNotification было бы использовать удобнее в случае нескольких получателей уведомления об изменении состояния модели.
Общеприянтой практикой, как я понял, является объявление подобных Model сущностей в Application Delegate, с дальнейшим осуществлением доступа через sharedApplication. Т.е. одного синглтона (предоставляемого приложением) казалось бы достаточно, и вводить новые — избыточно.
Такое ощущение, что доставка подобного рода уведомлений обычно осуществляется несколько по-другому: к сеттеру совйства прикручивается вызов метода, описываемого в протоколе соответствующего делегата. Все заинтересованные в уведомлениях сущности (обычно контроллеры) после получения доступа к разделяемой сущности (свойства sharedApplication) добавляют себя в список делегатов (тоже ничего писать не нужно, какой-то стандартный метод типа addDelegate есть). Реализуя необходимое подмножество протокольных методов получаем необходимые нотификации. В качестве бонуса: общая логика связанная с уведомлениями может быть релизована на стороне источника, а в методы делегата передается уже результат. Такой механизм представляется более очевидным, чем KVO или использование NSNotification.
На сколько я помню, при выбранном подходе NSNotification было бы использовать удобнее в случае нескольких получателей уведомления об изменении состояния модели.
Общеприянтой практикой, как я понял, является объявление подобных Model сущностей в Application Delegate, с дальнейшим осуществлением доступа через sharedApplication. Т.е. одного синглтона (предоставляемого приложением) казалось бы достаточно, и вводить новые — избыточно.
Такое ощущение, что доставка подобного рода уведомлений обычно осуществляется несколько по-другому: к сеттеру совйства прикручивается вызов метода, описываемого в протоколе соответствующего делегата. Все заинтересованные в уведомлениях сущности (обычно контроллеры) после получения доступа к разделяемой сущности (свойства sharedApplication) добавляют себя в список делегатов (тоже ничего писать не нужно, какой-то стандартный метод типа addDelegate есть). Реализуя необходимое подмножество протокольных методов получаем необходимые нотификации. В качестве бонуса: общая логика связанная с уведомлениями может быть релизована на стороне источника, а в методы делегата передается уже результат. Такой механизм представляется более очевидным, чем KVO или использование NSNotification.
Есть несколько замечаний:
1. В Вашем случае
2.
3.Инициализация переменных в init не самый лучший способ, лучше использовать lazy способ инициализации, он поможет экономно использовать ресурсы устройства. Плюс в примере инициализация переменной text бессмысленна.
4. Не вижу никакой выгоды от Вашей реализации MVC. MVC подразумевает не только наличие Модели, Контролера и Отображения но и связь между ними, которая позволила бы повторно использовать уже имеющийся код. В примере MainViewController всего лишь показывает строку и позволяет ее изменить и даже это мелочное поведение не можно использовать повторно так как он намертво привязан к синглтону модели. То есть если у Вас завтра в модели добавится еще одно строковое поле то Вы будете для него делать отдельный контроллер для показа второй строки по такому принципу? По моему мнению MVC ни на каплю не раскрыт.
1. В Вашем случае
@property (nonatomic, retain) NSString *text; не подходит. Обязательно надо использовать (nonatomic, copy). Если этого не сделать, то с легкостью можно случайно установить в модель NSMutableString и изменять ее. Ни модель ни кто-либо другой не смогут отследить такие изменения.2.
SYNTHESIZE_SINGLETON_FOR_CLASS(Model); — пердложил бы заменить на код синглтона предложенный в документации от Apple.3.Инициализация переменных в init не самый лучший способ, лучше использовать lazy способ инициализации, он поможет экономно использовать ресурсы устройства. Плюс в примере инициализация переменной text бессмысленна.
4. Не вижу никакой выгоды от Вашей реализации MVC. MVC подразумевает не только наличие Модели, Контролера и Отображения но и связь между ними, которая позволила бы повторно использовать уже имеющийся код. В примере MainViewController всего лишь показывает строку и позволяет ее изменить и даже это мелочное поведение не можно использовать повторно так как он намертво привязан к синглтону модели. То есть если у Вас завтра в модели добавится еще одно строковое поле то Вы будете для него делать отдельный контроллер для показа второй строки по такому принципу? По моему мнению MVC ни на каплю не раскрыт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MVC на iPhone: «The Model» (Часть 1)