Как я могу избежать передачи одного экземпляра компонента верхнего уровня всем моим подклассам - PullRequest
2 голосов
/ 17 марта 2012

Итак, я пытался понять, как лучше всего структурировать свой код, потому что у меня есть интуитивное чувство, что должен быть лучший способ достичь того, чего я хочу, без передачи одного объекта почти каждому классу пользовательского интерфейса вproject.

Проект, над которым я работаю, имеет класс RhythmWheel, расширяющий JRootPane.Затем конструктор создает все компоненты, которые образуют RhythmWheel.Например, он создает экземпляр ControlPanel (который расширяет JPanel) и добавляет его к себе.

Однако ControlsPanel необходимо иметь много знаний о вещах, определенных в RhythmWheels, таких как количество колескоторые в настоящее время выбраны.В настоящее время конструктор для ControlsPanel принимает RhythmWheel в качестве аргумента, а затем сохраняет ссылку на него.Он использует это для всего, что связано с компонентом, к которому следует добавить JFileChooser, и в качестве аргумента функции, которая записывает основное состояние приложения в файл XML.

Мне кажется, что это неправильноЯ передаю основной компонент по многим классам.Я подумал о шаблонах проектирования и подумал, что решение этой проблемы может быть синглтоном.Тем не менее, я много раз читал, что синглтоны - это зло и это анти-паттерн.Я думаю, что шаблон MVC мог бы помочь, но я не уверен, как я реализовал бы это в Swing.И совсем недавно я наткнулся на Dependency Injection как возможное решение.

Я немного растерялся относительно того, что мне следует делать, или мне вообще следует что-то делать.Если вы хотите взглянуть на код, над которым я работаю, вы можете увидеть его по адресу https://github.com/vamega/RhythmWheels, поэтому любые советы о том, как поступить, были бы полезны.

Ответы [ 2 ]

1 голос
/ 17 марта 2012

если все требует ссылки на RhythmWheel, значит, RhythmWheel ужасно сложно.может быть, вы можете разбить RhythmWheel на набор компонентов, которые (надеюсь и вероятно, поскольку GUI должен отражать логическую структуру) соответствуют определенным частям GUI?

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

и да, это mvc.компоненты колеса образуют вашу модель;Gui это ваш взгляд.что менее понятно, так это то, что контроллер.я подозреваю, что это колесо высокого уровня.

Итак, в итоге:

  • колесо состоит из подкомпонентов
  • колесо имеет высокуюметоды уровня, отражающие то, что вы можете «сделать» с ним
  • методы высокого уровня колеса - это то, что вызывается действиями в представлении
  • методы высокого уровня колеса вносят изменения в колесоподкомпоненты
  • подкомпоненты колеса, когда они изменяются, сообщают модели, которая обновляет

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

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

0 голосов
/ 17 марта 2012

Я не вижу, что не так с использованием синглетонов. Панель управления звучит как основной кандидат на синглтон. Зачем тебе больше одного? То же самое касается других. Все, к чему у вас есть доступ в ControlPanel из RhythmWheel, может быть открыто через геттеры и сеттеры.

Если нет разделения модели / вида, которое вы хотели бы отделить, или вида, который должен наблюдать за обновлениями модели, я бы не использовал MVC.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...