MVC много видов и один controller

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

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

++++++++++++++++++++++++

Более детально. Игра, которую я пишу, – это шашки (шашки). В одном сценарии, когда компьютер играет против себя, пользователь должен выбрать некоторые параметры перед началом игры. Одним из таких вариантов является выбор страtagsи игры для определенных периодов во время игры. Например, когда на доске будет от 12 до 8 штук, он атакует больше, 8 до 4 штук на доске будет более защитным.

Способ отображения графического интерфейса пользователя в настоящий момент состоит в том, что существует один общий JPanel (RightContainerFrame), который содержит другие JPanels; то есть один JPanel (StartGamePanel), в котором пользователь может настроить игру. Также есть JTabbedPane (jTabbedPane1), который содержит вкладки. В настоящее время в StartGamePanel, когда пользователь выбирает определенный параметр в JComboBox, вкладки нужно добавлять или удалять из jTabbedPane1.

То, как я достигаю этого в настоящее время, находится в StartGamePanel

RightContainerFrame.getInstance().generateAndDisplayPlayerTwoRangeTabs(numberOfRangeTabsNeeded);

Теперь я знаю, что все это неправильно, поскольку у меня есть один вид, StartGamePanel напрямую меняет другой вид JTabbedPane, вызывая метод в другом контейнере в виде RightContainerFrame.

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

Сначала я мог перенести метод jComboBox1ActionPerformed на controller. Это может либо обновить модель для jTabbedPane1. Или он может вызвать метод непосредственно в jTabbedPane1, чтобы отобразить количество необходимых вкладок.

    Swing – это не настоящая MVC-архитектура: это модель / (просмотр + controller). Каждый JComponent является одновременно и представлением, и controllerом.

    Вам необходимо определить методы обратного вызова (например, прослушиватели событий), которые вы связываете с каким-либо событием на компонентах. Существуют разные типы прослушивателей событий для разных типов событий на разных JComponents.

    Вот пример, когда прослушиватель событий зарегистрирован на кнопке, так что при щелчке он меняет текст в другом компоненте (myJLabel):

     jButton1.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent event) { myJLabel1.setText("You just clicked a button."); } } // you can add other ActionListeners to the same jButton1 

    У вас может быть глобальный controller, который обрабатывает все события, но вам нужно будет зарегистрировать его как слушателя для каждого компонента. Когда глобальный controller получил event , он может запросить его, чтобы узнать, с какой кнопкой он пришел, и соответствующим образом изменить другие JComponent (s). Итак, да, ваш глобальный controller будет нуждаться в ссылках на все JComponents, помимо того, что их регистрируют как слушателя. Глобальному controllerу необходимо будет реализовать не только ActionListener, как указано выше, чтобы получить щелчки мыши, но также и все другие типы EventListeners, необходимые для обработки всех других типов событий из других компонентов.

    Возможно, неплохо иметь глобальный controller, потому что он может стать очень большим classом. Просто позволить каждому JComponent, регистрирующему один (или много) прослушиватель событий, которые непосредственно меняют какой-либо другой компонент (ы), должно быть достаточно.

    EDIT :
    Я не уверен, что это плохая идея иметь глобальный controller: вы получаете огромный class, но, по крайней мере, вся логика обратного вызова находится в одном месте.

    Я еще не знаю, как представления обновляют другие представления.

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

    Я честно не понимаю вашего дизайна, но дизайн, который я бы принял в этом случае (предполагая, что мы говорим о богатых компонентах на основе пользовательских интерфейсов), заключается в том, чтобы Views прослушивал автобус событий и адаптировал свой собственный макет на основании события, проходящие в автобусе. В этом контексте обработчики действий пользовательского интерфейса могут публиковать события в шине. Эффективно развязывать взгляды друг от друга и с controllerа.

    Обновление: посмотрите здесь – материал Google, как правило, немного застенчив и переопределен для большинства потребностей с низкой средней сложностью, но вы можете обрезать его в соответствии с вашими потребностями.