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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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