Комментарии 30
Чем отличается ваш самописный паттерн от системного addObserver?
-2
В NotificationCenter, о котором я упоминал в самом начале статьи, такой проблемы не существует. Дело в том, что там передача данных происходит одним-единым параметром-словарем.
Извините, а почему нельзя сделать такой же параметр-словарь вместо нескольких параметров в методе
- (void)updateWithTemperature:(double)temperature
humidity:(double)humidity
andPressure:(double)pressure;
?-1
Можно конечно. Но если внимательно прочитать статью сначала, то выяснится, что это лишь учебный пример, который подан в таком виде лишь для лучшего понимания материала. :)
0
Я прекрасно понимаю, что ваш пример приведен для лучшего разъяснения паттерна и в реальном мире для этих целей есть решение из SDK. Вопрос ведь об этом.
Если внимательно прочитать статью сначала, то выяснится, что от использования одного словаря вместо трех параметров понимание не пострадает, а гибкость решения увеличится. От того и поинтересовался.
Если внимательно прочитать статью сначала, то выяснится, что от использования одного словаря вместо трех параметров понимание не пострадает, а гибкость решения увеличится. От того и поинтересовался.
-1
Использование словаря также не лучшее решение.
В случае с методами вы знаете о типах данных, не нужно бояться, что если вдруг тип одного из передаваемых значений изменится, то вы получите краш или просто некорректный вывод на экране: лучше получить ошибки на этапе компиляции и поправить их в каждом месте, чем править их по мере «натыкания» на краш или, что еще сложнее заметить, на пустой лэйбл, заходя на один из экранов раз в месяц, поскольку его разработкой сейчас не занимаетесь.
Почему бы не создать класс или структуру вроде
А если наблюдатель, простите за тавтологию, наблюдает за значениями/объектами/событиями, не относящимися к одной группе, так вообще лучше объявить несколько методов в протоколе наблюдателя.
В случае с методами вы знаете о типах данных, не нужно бояться, что если вдруг тип одного из передаваемых значений изменится, то вы получите краш или просто некорректный вывод на экране: лучше получить ошибки на этапе компиляции и поправить их в каждом месте, чем править их по мере «натыкания» на краш или, что еще сложнее заметить, на пустой лэйбл, заходя на один из экранов раз в месяц, поскольку его разработкой сейчас не занимаетесь.
Почему бы не создать класс или структуру вроде
WeatherDescription
, объявить в ней нужные вам поля и радоваться жизни. Добавить новое поле в класс, да без проблем, удалить какое-то поле и получить ошибки компиляции в нужных местах, да отлично.А если наблюдатель, простите за тавтологию, наблюдает за значениями/объектами/событиями, не относящимися к одной группе, так вообще лучше объявить несколько методов в протоколе наблюдателя.
+3
Использование словаря — универсальное решение.
Можно ведь создать тот же самый WeatherDescription и написать в нем 2 метода:
И получишь строгую типизацию, при этом оставив саму реализацию Observer универсальной.
Можно ведь создать тот же самый WeatherDescription и написать в нем 2 метода:
toDictionary() -> [String: Any]
и init?(from dictionary: [String: Any])
И получишь строгую типизацию, при этом оставив саму реализацию Observer универсальной.
0
Было бы кстати рассказать перед заключением о плюсах, минусах и ситуациях, когда будет хорошей идеей использовать этот паттерн.
А в общем хорошо написано, продолжай в том же духе.
А в общем хорошо написано, продолжай в том же духе.
+1
спасибо за статью, но владением должен заниматься наблюдатель. Ведь если мы начинаем наблюдать, значит важно что бы наблюдаемый не подох раньше времени.
+1
Хммм. А напишите конкретную реализацию для WeatherStation
плиз.
0
Мудреть лучше, чем молодеть
-1
То же самое, что сказать "лучше быть теплым чем мягким" ;)
Какое, по вашему мнению, отношение имеют друг к другу слова "старый" и "мудрый"? :)
0
а причем тут старый — я про старый не писал
-1
Уточню вопрос, так чтоб он стал более понятен: почему вы считаете, что нельзя мудреть и молодеть одновременно? :)
0
Поясню также для понятности: обучение, как получение знаний, в соединение с практическим опытом должно привести к мудрости (знания без мудрости опасны, не только на мой взгляд).
На это и обращено внимание.
Молодение, старение и прочее возрастное изменение с процессом обучения связано косвенно, опять же на мой взгляд
Для понятности — есть русская пословица. отражающая связь учения с временем — Век живи, век учись — дураком помрешь
На это и обращено внимание.
Молодение, старение и прочее возрастное изменение с процессом обучения связано косвенно, опять же на мой взгляд
Для понятности — есть русская пословица. отражающая связь учения с временем — Век живи, век учись — дураком помрешь
-1
NSMutableArray — это вообще законно? :)
0
Только что понял, что парсер съел угловые скобки.
Имелось ввиду, что
Имелось ввиду, что
NSMutableArray<Observer>
это не то же самое, что NSMutableArray<id<Observer>>
+1
Проясните в чем отличие?
0
В первом случае это будет свойство «NSMutableArray, адоптящий протокол Observer», во втором — «NSMutableArray, элементы которого теоретически адоптят Observer»
+1
Аааа, кажется понял. То есть — в первом случае, это может быть какой-нибудь объект, который мы унаследовали от NSMutableArray и подписали на протокол Observer? Но не обязательно, что его элеметы будут следовать этому протоколу?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Паттерны проектирования, взгляд iOS разработчика. Часть 2. Наблюдатель