Опасно ли передавать объект через объект [[NSNotificationCenter defaultCenter] postNotificationName]?

Question

Я пишу SDK и ища лучшую практику для отправки объекта через NSNotification.

Apple, и некоторые темы, в том числе this показывают, что object паров в postNotificationNamer должны быть отправителем уведомления, которое в большинстве случаев, self. И ваш пользовательский объект должен быть передан через userInfo NSDictionary. От Apple doc:

Создает уведомление с заданным именем, отправителем и информацией и отправляет его в ресивер.

Например, неадекватная практика:

[[NSNotificationCenter defaultCenter] postNotificationName:@"myNotification" 
                object:myObject]; 

И рекомендуемый способ:

NSDictionary* userInfo = @{@"myMessage": myObject}; 
[[NSNotificationCenter defaultCenter] postNotificationName:@"myNotification" 
                object:self 
                userInfo:userInfo]; 

Я попробовал оба метода, и все они работают хорошо. Вопрос в том, есть ли риск использовать прежний метод? В моем случае меня не интересует отправитель уведомления, но с использованием последнего метода вводится дополнительная оболочка (NSDicionary) вокруг фактического объекта, который я хочу отправить.

Answer 1

Это не опасно использовать параметр объекта, но иметь в виду, что NSNotificationCenter использует этот параметр внутренне решить некоторые вещи. Поэтому, если ваш код зависит от того, что работает в определенном порядке или в определенных очередях, он может вести себя неожиданно.

Вот соответствующая цитата из NSNotificationCenter Class Reference:

Объект, уведомления вы хотите добавить блок в очереди операций.

Если вы передаете ноль, центр уведомлений не использует отправителя уведомления, чтобы решить, следует ли добавить блок в очередь операций.

Я рекомендую, что вы использовали USERINFO по назначению, но это не опасно.

Answer 2

Последний более гибкий. Хотя теперь вам может не понравиться отправитель, это может измениться. И позже вы можете найти дополнительную информацию.

Лучше сделать это прямо вверх. Для этого не требуется никаких дополнительных усилий, чтобы сделать это правильно в первый раз, и приложить много усилий (и склонны к ошибкам), чтобы вернуться и реорганизовать кучу кода, когда ваши потребности меняются.

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