Помещение всех уведомлений в один объект разрушает инкапсуляцию, и это плохо. Вы делаете операции уведомления одного объекта зависимыми от работы другого объекта должным образом. Это будет кошмар, отслеживающий все это. Это также связано со всей целью уведомлений, которая заключается в создании децентрализованной и модульной системы обмена сообщениями.
Уведомления не должны быть «разбросаны по всему коду», а должны управляться исключительно объектами, которые их получают. Если вы используете большое количество уведомлений, вам может потребоваться создать класс с выделенными методами для обработки нескольких уведомлений, а затем сделать так, чтобы другие ваши классы наследовали от этого класса. Таким образом, вы получаете автоматическое управление.
Одна из самых больших ошибок, которые люди делают с уведомлениями, заключается в том, что они регистрируют контроллеры, когда им действительно необходимо зарегистрировать свою модель данных. Например, предположим, что вы загружаете некоторые данные с URL-адреса и хотите обновить интерфейс по мере его развития и / или когда он заканчивается. Если в вашем пользовательском интерфейсе несколько представлений и вы регистрируете контроллеры, то каждое представление должно управлять уведомлением (которых может быть несколько). Однако, если вы настроили общую модель данных для получения уведомления, вам нужно иметь только максимум два уведомления. Один из них пойдет в модель данных, чтобы модель данных могла обновляться самостоятельно, а затем вы можете попросить модель данных генерировать общее уведомление для любых прослушивающих представлений об обновлении себя из модели данных.
Зависимость контроллера представления от модели данных во всех случаях значительно упрощает проектирование.