Одна из проблем здесь заключается в том, что во всех правилах есть некоторая свобода действий, когда вы должны использовать свое собственное суждение.
Например, приложение, которое вы описываете сейчас, кажется мне настолько простым, что я, вероятно, сделаю это в одном классе, возможно с парой вложенных, возможно, анонимных классов. В любом случае, я мог бы найти достойное обоснование для того, чтобы поместить все это в один исходный файл, заявив, что несколько исходных файлов на самом деле увеличат сложность всего этого.
Но если бы в вашем графическом интерфейсе было несколько разных элементов управления, возможно, каждый из которых контролировал свое поведение, пришло время разделить функциональность, чтобы вы не закончили с большой чашей спагетти-кода.
Библиотеки Java GUI пытаются естественным образом отделить (view + controller) от модели. Вам рекомендуется определять и отображать графический интерфейс в одном модуле (= файл), но иметь модель данных и, возможно, функциональность в другом. Для сложных графических интерфейсов может также быть несколько модулей реализации графического интерфейса, удерживаемых вместе кодом.
Один из способов сохранить вещи в чистоте - это работать в «слоях», где каждый слой «знает» только то, что ему нужно знать. Чтобы быть точным, уровень GUI должен знать о существовании его базовых моделей & ndash; таблицы и списки, и тому подобное, должны быть подключены к TableModel s и ListModel s и т. д. Тем не менее, не требуется знать детали этих моделей, поэтому он может просто ссылаться на эти модели по интерфейсу.
Слой модели, с другой стороны, не должен ничего знать о GUI. Чем меньше он знает, тем лучше, и это теоретически позволит вам обмениваться графическими интерфейсами без необходимости прикасаться к моделям.
Моя модель также может содержать ActionListener s для ответа на действия, предпринятые, например, нажатие кнопок в графическом интерфейсе.
Конечно, действия и изменения в модели часто приводят к изменениям в графическом интерфейсе. Как сообщить об этих изменениях в GUI, если уровень модели не знает о GUI? Вы можете использовать связанные свойства bean здесь. Вот краткое руководство: http://www.javalobby.org/java/forums/t19476.html. Таким образом, у вас такая же структура: изменения происходят в вашей модели, они сообщаются бинам с поддержкой изменения свойств в модели, и графический интерфейс может подключать слушателей к этим свойствам, чтобы узнать, что что-то изменилось.
Выполните ли вы фактические, эффективные действия (например, написание файлов, преобразование данных и т. Д.) В коде вашей модели, или же вы разделите код "обработки" на еще один модуль, зависит от вас и будет зависеть от того, насколько загромождена ваша модель уже есть. Если там крошечная горстка полей и методов, чувствующих себя одинокими, вы можете решить объединить все вместе, но в тот момент, когда он начнет выглядеть беспорядочным, вам захочется перестроить код обработки в свой собственный модуль. Обработка звучит как тот модуль, который не хочет знать и о других модулях; в итоге вы можете просто вызывать его методы на уровне модели.
Я описал мой основной стиль для разработки GUI. Конечно, есть и другие рекомендации, и вы, вероятно, разработаете свой собственный стиль на основе своего опыта. Это просто для того, чтобы дать вам идею и возможную отправную точку.