Использование нескольких JFrames: хорошая или плохая практика? [закрытый]

несколько JFrame подход был чем-то, что я реализовал с тех пор, как начал программировать приложения Swing. По большей части, я сделал это в начале, потому что я не знал ничего лучшего. , как я созрел в своем опыте и знаниях в качестве разработчика и как начал читать и впитывать мнения многих более опытных Java-разработчиков в Интернете, я сделал попытку сдвиг с множественными JFrame подход (как в текущих проектах, так и в будущем проекты) только для удовлетворения... получить это... сопротивление от моих клиентов! как я начал реализовывать модальные диалоги для управления "дочерними" окнами и JInternalFrameS для отдельных компонентов, мои клиенты начали жаловаться! я был очень удивлен, так как я делал то, что я думал, было лучшей практикой! Но, как говорится, "счастливая жена-это счастливая жизнь.- То же самое касается и ваших клиентов. Конечно, я подрядчик, поэтому мои конечные пользователи имеют прямой доступ ко мне, разработчику, что очевидно не самый распространенный сценарий.

Итак, я собираюсь объяснить преимущества нескольких JFrame подход, а также миф-бюст некоторые из минусов, которые другие представили.

1. максимальная гибкость в компоновке - позволяя отделить JFrames, вы даете своему конечному пользователю возможность распространять и контролировать то, что находится на его/ее экране. Концепция чувствует себя "открытой" и не сжимающей. Вы теряете это, когда вы идете к одному большому JFrame и куча JInternalFrame s.
2. хорошо работает для очень модульных приложений - в моем случае, большинство моих приложений имеют 3-5 больших "модулей", которые на самом деле не имеют ничего общего друг с другом вообще. Например, один модуль может быть панелью продаж, а другой-панелью учета. Они не разговаривают друг с другом или что-нибудь. Тем не менее, руководитель может захотеть открыть оба, и они являются отдельными кадрами на панели задач, что делает его жизнь облегчающий.
3. делает его легким для пользователей сослаться на внешний материал - однажды у меня была такая ситуация: у моего приложения был "просмотрщик данных", из которого вы могли нажать "Добавить новый", и он откроет экран ввода данных. Первоначально, оба были JFrame s. однако я хотел, чтобы экран ввода данных был JDialog чей родитель был средством просмотра данных. Я внес изменения, и сразу же получил звонок от конечного пользователя, который сильно полагался на то, что он может свести к минимуму или закрыть просмотр и сохранить редактор открыть, пока он ссылается на другую часть программы (или веб-сайт, я не помню). Он не на мульти-мониторе, поэтому ему нужно, чтобы диалог ввода был первым и что-то другое быть во-вторых, с просмотра данных полностью скрыты. Это было невозможно с JDialog и, конечно, было бы невозможно с JInternalFrame Как хорошо. Я неохотно изменил его обратно, чтобы быть отдельным JFrames для его здравомыслие, но оно преподало мне важный урок.
4. миф: трудно код - это не соответствует моему опыту. Я не понимаю, почему было бы легче создать JInternalFrame чем a JFrame. На самом деле, по моему опыту, JInternalFrames предложение гораздо меньше гибкости. Я разработал систематический способ обработки открытия и закрытия JFrames в моих приложениях, которые действительно хорошо работают. Я контролирую кадр почти полностью из самого кода кадра; создание нового кадр,SwingWorkers, которые управляют извлечением данных о фоновых потоках и коде GUI на EDT, восстанавливая/выводя на передний план кадр, если пользователь пытается открыть его дважды и т. д. Все, что вам нужно, чтобы открыть мой JFrame s-это вызов публичного статического метода open() и открытый метод, в сочетании с windowClosing() событие обрабатывает остальные (кадр уже открыт? он не открыт, но загружается? так далее.) Я сделал этот подход шаблоном, поэтому его не сложно реализовать для каждого рамка.
5. Миф / Недоказанный: Ресурс Тяжелый - я хотел бы увидеть некоторые факты за этим спекулятивным заявлением. Хотя, пожалуй, можно было бы сказать и JFrame нужно больше места, чем JInternalFrame, даже если вы откроете 100 JFrames, сколько еще ресурсов вы действительно потребляете? Если вас беспокоит утечка памяти из-за ресурсов: вызов dispose() освобождает все ресурсы, используемые фреймом для сбора мусора (и, опять же, я говорю, a JInternalFrame должен вызывать именно та же забота).

я написал много, и я чувствую, что мог бы написать больше. В любом случае, я надеюсь, что я не буду голосовать просто потому, что это непопулярное мнение. Вопрос явно ценный, и я надеюсь, что дал ценный ответ, даже если это не общее мнение.

отличный пример нескольких кадров / одного документа на кадр ( SDI) против одного кадра / нескольких документов на кадр (MDI) - это Microsoft Excel. Некоторые преимущества MDI:

• можно иметь несколько окон в не прямоугольной форме-поэтому они не скрывают рабочий стол или другое окно от другого процесса (например, веб-браузер)
• можно открыть окно из другого процесса над одним окном Excel во время записи во втором окне Excel - с MDI, пытаясь написать в одном из внутренних окон даст фокус на все окно Excel, следовательно, скрывая окно от другого процесса
• можно разные документы на разных экранах, что особенно полезно, когда экраны не имеют одинаковое разрешение

SDI (интерфейс с одним документом, т. е. каждое окно может иметь только один документ):

MDI (интерфейс с несколькими документами, т. е. каждое окно может иметь несколько документов):

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

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

одна из "программ", которые они запускают, представляет собой список отчетов, которые были сгенерированы системой, и пользователь может нажать на значок в каждой строке, чтобы открыть отчет диалог просмотра. Этот просмотрщик показывает эквивалент портретной / альбомной страницы A4 отчета, поэтому пользователям нравится, чтобы это окно было довольно большим, почти заполняя их экраны.

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

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

они открывали средство просмотра, используя функцию "Сохранить как", чтобы сохранить отчет в формате PDF в определенный каталог, используя Acrobat Reader, чтобы открыть файл PDF, а затем они сделают то же самое со следующим отчетом. У них будет несколько читателей Acrobat, работающих с различными выходными данными отчета, которые они хотели бы посмотреть.

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

Итак, вы идете вперед и говорите своим пользователям, что то, что они хотят, плохо, но в конечном итоге это не принесет вам никакой пользы.

НЕКОТОРЫЕ ПРИМЕЧАНИЯ:

• кажется, лучше всего использовать JDialog для этих немодальных windows
• используйте конструкторы, которые используют новый ModalityType а не булево

сделать jInternalFrame в основной кадр и сделать его невидимым. Затем вы можете использовать его для дальнейших событий.

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);

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

• Это дороже: вам придется выделить больше ресурсов, чтобы нарисовать JFrame, что другой вид контейнера окна, такие как Dialog или JInternalFrame.

• не работает: нелегко перемещаться в кучу JFrame, склеенных вместе, это будет выглядеть ваше приложение как набор непоследовательных приложений и плохо спроектированных.

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

плохая практика наверняка. Одна из причин заключается в том, что это не очень "удобный" для того, что каждый JFrame показывает новый значок на панели задач. Управление несколькими JFrames заставит вас рвать волосы.

лично я бы использовал один JFrame для вашего типа приложения. Методы отображения нескольких вещей зависит от вас, есть много. CanvasЭс JInternalFrame,CardLayout, даже JPanelС, возможно.

несколько объектов JFrame = боль, проблемы и проблемы.

я думаю, что через несколько Jframes не очень хорошая идея.

вместо этого мы можем использовать JPanels более одного или более JPanel в том же JFrame.

также мы можем переключаться между этим JPanel s. таким образом, это дает нам свободу отображать больше, чем на вещи в JFrame.

для каждого JPanel мы можем проектировать разные вещи, и все это JPanel может отображаться на одном JFrameодному за раз.

для переключения между этим JPanel использование s JMenuBar С JMenuItems для каждого JPanelили ' JButtonfor eachJPanel'.

более одного JFrame - это не очень хорошая практика, но нет ничего плохого, если мы хотим больше, чем один JFrame.

но его лучше менять один JFrame для наших различных потребностей, а не несколько JFrame s.

Если кадры будут иметь одинаковый размер, почему бы не создать кадр и передать кадр тогда как ссылку на него вместо этого.

когда вы прошли кадр, вы можете решить, как его заполнить. Это было бы похоже на метод расчета среднего значения набора цифр. Вы бы создали метод снова и снова?

Это не очень хорошая практика, но даже если вы хотите использовать его вы можете использовать шаблон синглтона как его хорошо. Я использовал одноэлементные шаблоны в большинстве своих проектов его хорошо.