ЗВ книге Эриха Гаммы про паттерны описывается
А>паттерн Медиатор, но там же написано что он эффективность его применения быстро уменьшается
А>при увеличении числа зависящих друг от другка элементов. У меня как раз такой случай.
А>Буду признателен за любые идеи.

А чем не подходит Observer?
Делаешь Subject класс, каждый пункт меню регистрируется у него как Observer, и получает callback "stateChanged" на любое изменение состояния. Ну а обработчик stateChanged для каждого Observer уже запрашивает необходимы данные у Subject-а.

class DocumentCloseMenuItem : public Observer
{
void stateChanged(){
setEnabled(Application.getActiveDocument() != 0)
}
};

class DocumentSaveMenuItem : public Observer
{
void stateChanged(){
setEnabled(Application.getActiveDocument() != 0 && Application.getActiveDocument()->isDirty())
}
};

Дальше уже оптимизация. Что бы на каждый чих не дёргать stateChanged у 10000 Observer-ов, можно отложить вызов некоторых Observer::stateChanged на "потом". Например, когда придёт время показать меню пользователю. Возможно, что state приложение сменится 10 раз, а stateChanged вызовется только 1 — перед показом.
Так же можно помечать Observer-ы, у которых ещё не вызывался stateChanged и вызывать по одному в onIdle.
При таких мерах оптимизации можно в любой функции помечать state как изменённый, не задумываясь — а не делает ли то же самое какая-то из тех функций, что ты вызываешь.
Ну и ещё можно сделать несколько Subject-ов. Например, ActiveDocumentSubject (для save/close), ActiveViewSubject (next/prev), ActiveWindow(copy/paste/find) и т.д.
Надеюсь не очень скомканно объяснил?