Шаблоны реализации, чтобы избежать бесконечных циклов с событиями

Question

Наивная реализация MVC ведет к бесконечным циклам.

Пример: модель - это рабочая книга с рабочими таблицами, представление - это панель с вкладками

1. Пользователь взаимодействует с панелью вкладок для создания новой вкладки
2. Панель вкладок отправляет событие onTabAdded в Controler
3. Controler вызывает Workbook.addWorksheet ()
4. Рабочая книга отправляет событие onWorksheetAdded на вкладку
5. Tabbar добавляет Tab и отправляет onTabAdded в Controler -> 2) Infinite Loop!

В качестве альтернативы цикл может быть инициирован программным добавлением рабочего листа через макрос.Или же вкладка может быть добавлена ​​программно с помощью автоматического тестирования пользовательского интерфейса.

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

Знаете ли вы о шаблонах реализации, как избежать таких бесконечных циклов?Оценка плюсов / минусов таких шаблонов?

Мой особый интерес - это решение для богатого клиента JavaScript.

Ответы на следующие вопросы не совсем соответствуют уровню реализации:

• должен ли шаблон наблюдателя включать в себя обнаружение бесконечного цикла?
• Архитектура, управляемая событиями ... бесконечный цикл
• как избежать бесконечного цикла в схеме наблюдателя?

Answer 1

Обычно вы кодируете что-то вроде этого (псевдокод):

boolean inEventProcessing = false;

processEvent(event){
    if inEventProcessing return
    inEventProcessing = true
    doProcessEvent(event)
    inEventProcessing = false
}

Альтернатива состоит в том, чтобы убедиться, что по построению петли не случаются. Это концептуально более чистый способ, но его трудно сделать, если вы не придумали его в самом начале. Один из способов состоит в том, чтобы позволить наблюдателям только аргументы конструкторам наблюдаемых. Таким образом, было бы невозможно построить петли. Но это чрезвычайно жесткая структура, которая, вероятно, вызывает различные проблемы.

Я подозреваю, что решение этих проблем приведет к действительно хорошей и чистой архитектуре или к полному и экстремальному беспорядку, в зависимости от команды, работающей с ней.