Comments 13
> Потому-что множество хранит сильные ссылки.
Если очень хочется использовать NSSet/NSDictionary/NSArray — можно обернуть объект в NSValue:
[NSValue valueWithNonretainedObject:]
Если очень хочется использовать NSSet/NSDictionary/NSArray — можно обернуть объект в NSValue:
[NSValue valueWithNonretainedObject:]
Что-то я не совсем уловил суть. KVO — это и есть уже готовая реализация паттерна Observer. Зачем писать реализацию над реализацией? Чтобы вы могли реализация пока реализация реализация?
это комментарий немного в стиле «зачем писать на высокоуровневых языках, если можно писать на асме». А если больше по теме — то мы должны стараться использовать более точные абстракции, соответствующие задаче. Вот например, мы же вместо NSURLConnection — стремимся использовать именно AFNetworking (потому-что он более удобен), или например, RestKit для работы с RESTful сервисами, потому-что эти библиотеки представляют нам более удобные интерфейсы для нашей задачи. В некоторых случаях, мы конечно, теряем управляемость, и тратим лишнее время (если реализуем собственные решения), но в дальнейшем мы можем иметь выигрыш (особенно в крупных проектах). Потому-что в дальнейшем низкоуровневый код будет сложно модифицировать и понимать.
С одной стороны, вроде бы мотивация ясна. С другой стороны, для меня это всё равно выглядит, как бесполезное усложнение. Абстракция ради абстракции. Штатное kvo, к примеру, легко использовать для биндингов к UI. И не только (пользуюсь им постоянно, для различных целей, нареканий никаких нет). Ваше решение, видимо, только Вам одному понятно, для чего можно использовать. Хотя, главное, конечно, чтобы Вы сами ощущали полезность Вашей абстракции и прирост продуктивности от ее использования в Вашем проекте.
Программист на фортранеджаве на любом языке может писать на фортране?
А если по теме — то если у нас сущность подписывается на изменение одного поля в модели — то зачем тянуть наблюдение за остальными? (пусть даже на уровне протокола)
А если на изменение нескольких — то не проще ли (и не чище ли) подписываться на изменение объекта модели в целом?
А если по теме — то если у нас сущность подписывается на изменение одного поля в модели — то зачем тянуть наблюдение за остальными? (пусть даже на уровне протокола)
А если на изменение нескольких — то не проще ли (и не чище ли) подписываться на изменение объекта модели в целом?
все это не совсем так — я за всеми этими свойствами веду наблюдение (и имею не одного подписчика), да и в дальнейшем, если мне где-то нужно будет еще следить за чем-то — я получаю большой выигрыш, потому-что смогу очень быстро реализовать новый функционал.
Если подписываться на изменение модели — это требует написания лишних строчек willChangeValueForKey/didChangeValueForKey в местах, где происходят изменения объектов. Хотя, кажется, там был какой-то автоматический механизм. В любом случае это тоже неплохая идея, но сделал уже именно так, и оно неплохо сразу заработало
Если подписываться на изменение модели — это требует написания лишних строчек willChangeValueForKey/didChangeValueForKey в местах, где происходят изменения объектов. Хотя, кажется, там был какой-то автоматический механизм. В любом случае это тоже неплохая идея, но сделал уже именно так, и оно неплохо сразу заработало
Вообще, стоит архитектурно очень качественно подумать — а правильно ли организованы потоки данных в приложении, если есть изменяемая модель с несколькими слушателями. Необходимость такого — это, скорее, исключение, чем правило.
Могу порекомендовать подробно поизучать ReactiveCocoa и прочие порты Rx — оно, конечно, оверкилл с точки зрения производительности — но при осознанном использовнии невероятно упрощает поддержку кода бизнес-слоя.
Могу порекомендовать подробно поизучать ReactiveCocoa и прочие порты Rx — оно, конечно, оверкилл с точки зрения производительности — но при осознанном использовнии невероятно упрощает поддержку кода бизнес-слоя.
Например модель, отвечающая за авторизацию:
Её могут слушать как и контроллер чего-нибудь интерфейсного, так и другая модель.
Или же состояние сети. Аналогично, его могут слушать как и модели, чтобы сделать запрос к сети, когда появится доступ, так и контроллер, чтобы показать пользователю надпись, «извините, нет соединения с интернет»
Правда, я реализую это вещи по другому, но как пример — сгодятся.
Интернет — это чаще всего Reachibility, использующий NSNotificationCenter, а авторизация (как и прочие модели) — «множественные» делегаты.
Её могут слушать как и контроллер чего-нибудь интерфейсного, так и другая модель.
Или же состояние сети. Аналогично, его могут слушать как и модели, чтобы сделать запрос к сети, когда появится доступ, так и контроллер, чтобы показать пользователю надпись, «извините, нет соединения с интернет»
Правда, я реализую это вещи по другому, но как пример — сгодятся.
Интернет — это чаще всего Reachibility, использующий NSNotificationCenter, а авторизация (как и прочие модели) — «множественные» делегаты.
Вот, вы приводите как раз превосходные примеры атомарных моделей. В которых нам интересно изменение всего состояния авторизации, либо же сети, а не одного из 5 полей, что значительно упрощает работу по организации подписки — как через Notification Center, так и через KVO или же множественное делегирование, реализованное, как-нибудь иначе.
У меня вызывает вопросы как раз необходимость дробления модели до ее полей.
У меня вызывает вопросы как раз необходимость дробления модели до ее полей.
Честно говоря, в код особо не вникал, возможно потому вас неверно понял. Теперь, кажется, понял :)
В принципе, основная проблема изкоробочного KVO в obj-c, на мой взгляд, — это «божественный метод», который уведомляется о всех изменениях в слушателей: observeValueForKeyPath. Эта проблема — причина которой я и не использую KVO.
Насколько я понял автора — это попытка решать эту проблему. Объект, который перенаправляет уведомления KVO в соответствующие им селекторы. В принципе, хуже не стало. На счёт лучше… Тоже не уверен. Вообще, можно реализовать это гораздо прозрачнее.
В принципе, основная проблема изкоробочного KVO в obj-c, на мой взгляд, — это «божественный метод», который уведомляется о всех изменениях в слушателей: observeValueForKeyPath. Эта проблема — причина которой я и не использую KVO.
Насколько я понял автора — это попытка решать эту проблему. Объект, который перенаправляет уведомления KVO в соответствующие им селекторы. В принципе, хуже не стало. На счёт лучше… Тоже не уверен. Вообще, можно реализовать это гораздо прозрачнее.
Насколько я помню, NSObjectController как-то связан за слежением за объектом в целом. Хотя, могу и ошибаться.
Чем меньше в системе изменяемых моделей, тем спокойнее работать
Sign up to leave a comment.
Пишем реализацию Observer-а над KVO на objective-c