Стратегия Java OOP

Question

У меня есть проект под названием Visual Data Structures. У меня такой дизайн ООП.

Class VisualDataStructures extends JFrame 
Class ControlPanel extends JPanel 
Class CodePanel extends JPanel 

Class VisualDataStructures имеет основные. Этот класс имеет экземпляры Class ControlPanel и CodePanel.

Class ControlPanel имеет JMenuItem под названием «Нагрузка» внутри JMenuBar.

Class CodePanel имеет номер JTextArea.

Вопрос:
мне нужно иметь ActionListener для JMenuItem под названием «нагрузка» внутри класса ControlPanel. Когда щелкнет нагрузка, пользователь войдет в каталог файла, затем файл будет загружен и отображен на JTextAreaCodePanel.

Должен ли я передать объект CodePanel, который был создан из VisualDataStructures в ControlPanel, чтобы я мог использовать этот объект, а затем изменить значение JTextArea?

Кто-нибудь знает, что для этого лучше подходит? Благодарю.

Answer 1

Немного сложно ответить на этот вопрос, не видя фактического кода, но я все равно попробую. Может быть, если бы вы могли каким-то образом поделиться своим кодом, через Github, Bitbucket, как Gist или в Pastebin, я мог бы дать лучший ответ. Тогда также лучше сделать это в CodeExchange CodeReview вместо StackOverflow.

В целом, я нахожу подозрительным, что из родительских классов GUI существует так много extends. Использование по расширению может быть немного anti-pattern. В первую очередь это может привести к кажущемуся простому коду в крошечных приложениях, но в конечном итоге он имеет тенденцию к запутыванию исходного кода, поскольку он поощряет сочетание бизнес-логики и пользовательского интерфейса. Это недоразумение, что расширение является ядром ООП. Это не. Полиморфная абстракция для развязки и инверсии ключевых зависимостей, это ядро ​​ООП. Расширение - это просто приятное и удобное дополнение к этому, и это чрезмерно.

Говоря об этом, возможно, вы слышали о MVC - Model View Controller. Это типичный образец для пользовательских интерфейсов, чтобы держать вещи в отдельности.

Вы не хотите, чтобы ActionListener реагировал на действие load, чтобы непосредственно знать CodePanel, поскольку такая зависимость слишком конкретна. Вы хотите иметь абстракцию между ними, как интерфейс, и ссылаться на этот интерфейс вместо CodePanel.

Что касается ActionListener и аналогичных интерфейсов, возможно, вам будет интересно перейти на Java 8, если вы еще не сделали этого. Интерфейсы, такие как ActionListener с помощью всего одного абстрактного метода, являются неявно функциональными интерфейсами, что означает, что вы можете использовать ссылки lambdas или методы.

В целом, я думаю, что это помогает всегда помнить о следующем вопросе: Что делать, если я заменю набор инструментов пользовательского интерфейса другой? Даже если это не прецедент и никогда не произойдет, разделение и разделение опасений, которые вы делаете, чтобы ответить на этот вопрос, приводят к более модульным, лучшим проектам, которые легче понять и поддерживать.В конце концов, вопрос Что делать, если я заменю набор инструментов пользовательского интерфейса другой? приводит к дизайну, который следует за многими принципами SOLID.

Имея дело с ActionListener в Swing, вы можете посмотреть на interface Action и abstract class AbstractAction. Они предлагают очень интересные возможности. Используемые в правильном направлении, они могут упростить код.