How to become an author
Search
Profile
Pull to refresh

Comments 30

Чем отличается ваш самописный паттерн от системного addObserver?
Total votes 2: ↑0 and ↓2 -2

Так какбэ ничем. Я ж для этого и использовал в статье такие ключевые слова как "не будет острой необходимости", "NotificationCenter" и "в образовательных целях". Причем в первом же абзаце. )))

Total votes 2: ↑1 and ↓1 0
В NotificationCenter, о котором я упоминал в самом начале статьи, такой проблемы не существует. Дело в том, что там передача данных происходит одним-единым параметром-словарем.


Извините, а почему нельзя сделать такой же параметр-словарь вместо нескольких параметров в методе 
- (void)updateWithTemperature:(double)temperature
                     humidity:(double)humidity
                  andPressure:(double)pressure;
?
Total votes 1: ↑0 and ↓1 -1

Можно конечно. Но если внимательно прочитать статью сначала, то выяснится, что это лишь учебный пример, который подан в таком виде лишь для лучшего понимания материала. :)

This comment wasn’t rated yet 0
Я прекрасно понимаю, что ваш пример приведен для лучшего разъяснения паттерна и в реальном мире для этих целей есть решение из SDK. Вопрос ведь об этом.

Если внимательно прочитать статью сначала, то выяснится, что от использования одного словаря вместо трех параметров понимание не пострадает, а гибкость решения увеличится. От того и поинтересовался.
Total votes 1: ↑0 and ↓1 -1
Использование словаря также не лучшее решение.

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

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

А если наблюдатель, простите за тавтологию, наблюдает за значениями/объектами/событиями, не относящимися к одной группе, так вообще лучше объявить несколько методов в протоколе наблюдателя.
Total votes 3: ↑3 and ↓0 +3
Использование словаря — универсальное решение.
Можно ведь создать тот же самый WeatherDescription и написать в нем 2 метода: 
toDictionary() -> [String: Any]
и 
init?(from dictionary: [String: Any])

И получишь строгую типизацию, при этом оставив саму реализацию Observer универсальной.
Total votes 2: ↑1 and ↓1 0
Насколько я понимаю, это не поможет с ловлей ошибок на этапе компиляции.
Total votes 2: ↑2 and ↓0 +2
Было бы кстати рассказать перед заключением о плюсах, минусах и ситуациях, когда будет хорошей идеей использовать этот паттерн.
А в общем хорошо написано, продолжай в том же духе.
Total votes 1: ↑1 and ↓0 +1
спасибо за статью, но владением должен заниматься наблюдатель. Ведь если мы начинаем наблюдать, значит важно что бы наблюдаемый не подох раньше времени.
Total votes 1: ↑1 and ↓0 +1

Хммм. А напишите конкретную реализацию для WeatherStation плиз.

This comment wasn’t rated yet 0
вы можете в наблюдаемом объекте вместо массива с наблюдателями использовать NSHashTable, у нее есть метод +weakObjectsHashTable.
This comment wasn’t rated yet 0

Так в наблюдаемом объекте нет массива с наблюдателями, как можно что-то использовать "вместо" него? :)

This comment wasn’t rated yet 0
как же нет?
@property (strong, nonatomic) NSMutableArray *observers;
Total votes 1: ↑1 and ↓0 +1

То же самое, что сказать "лучше быть теплым чем мягким" ;)


Какое, по вашему мнению, отношение имеют друг к другу слова "старый" и "мудрый"? :)

This comment wasn’t rated yet 0
а причем тут старый — я про старый не писал
Total votes 1: ↑0 and ↓1 -1

Уточню вопрос, так чтоб он стал более понятен: почему вы считаете, что нельзя мудреть и молодеть одновременно? :)

This comment wasn’t rated yet 0
Поясню также для понятности: обучение, как получение знаний, в соединение с практическим опытом должно привести к мудрости (знания без мудрости опасны, не только на мой взгляд).
На это и обращено внимание.
Молодение, старение и прочее возрастное изменение с процессом обучения связано косвенно, опять же на мой взгляд
Для понятности — есть русская пословица. отражающая связь учения с временем — Век живи, век учись — дураком помрешь
Total votes 1: ↑0 and ↓1 -1
Только что понял, что парсер съел угловые скобки.
Имелось ввиду, что 
NSMutableArray<Observer>
это не то же самое, что 
NSMutableArray<id<Observer>>
Total votes 1: ↑1 and ↓0 +1
В первом случае это будет свойство «NSMutableArray, адоптящий протокол Observer», во втором — «NSMutableArray, элементы которого теоретически адоптят Observer»
Total votes 1: ↑1 and ↓0 +1

Аааа, кажется понял. То есть — в первом случае, это может быть какой-нибудь объект, который мы унаследовали от NSMutableArray и подписали на протокол Observer? Но не обязательно, что его элеметы будут следовать этому протоколу?

This comment wasn’t rated yet 0
Да, все верно. Ну и за компанию: в данном случае торчать мутабельностью вредно. Торчать не ридонли мутабельностью вредно вдвойне. Обязательно найдется кто-то, кто «пофиксит» баг обнулением/перезаписью свойства, либо вызовом removeAllObjects.
Total votes 1: ↑1 and ↓0 +1

В общем: и первый комент тоже имеет смысл:


NSMutableArray — это вообще законно? :)

Спасибо, люблю каменты по делу. Теперь буду это знать, благодаря вам. :)

Total votes 1: ↑1 and ↓0 +1
так мутабельное свойство в приватном екстеншене, или пофиксили уже?
This comment wasn’t rated yet 0
Only those users with full accounts are able to leave comments. Log in, please.

Articles

Your account

Sections

Information

Services

Support
© 2006–2023, Habr