Korzystanie z wielu ramek JFrames: dobra czy zła praktyka? [zamknięte]

Podejście wielokrotne JFrame było czymś, co zaimplementowałem, odkąd zacząłem programować aplikacje Swing. W większości przypadków zrobiłem to na początku, bo nie wiedziałem nic lepszego. jednak , gdy dojrzałem w swoim doświadczeniu i wiedzy jako programista i zacząłem czytać i przyswajać opinie tak wielu bardziej doświadczonych programistów Java online, podjąłem próbę odejścia od podejścia wielokrotnego JFrame (zarówno w obecnych, jak i przyszłych projektach) tylko po to, aby być spełnionym z... posłuchaj tego... Opór moich klientów! kiedy zacząłem implementować modalne okna dialogowe do kontrolowania "dzieci" okien i JInternalFrame S dla oddzielnych komponentów, moi klienci zaczęli narzekać! byłem dość zaskoczony, ponieważ robiłem to, co uważałem za najlepszą praktykę! Ale, jak mówią, " szczęśliwa żona to szczęśliwe życie."To samo dotyczy twoich klientów. Oczywiście jestem wykonawcą, więc moi użytkownicy końcowi mają bezpośredni dostęp do mnie, dewelopera, co oczywiście nie jest powszechnym scenariuszem.

Więc, Wyjaśnię korzyści płynące z podejścia multiple JFrame, a także obalę niektóre z minusów, które przedstawili inni.

1. najwyższa elastyczność w układzie - pozwalając na oddzielne JFrame s, dajesz użytkownikowi końcowemu możliwość rozłożenia i kontrolowania tego, co znajduje się na jego ekranie. Koncepcja wydaje się "otwarta" i nie krępująca. Tracisz to, gdy idziesz w kierunku jednego dużego JFrame i kilku JInternalFrame s.
2. Działa dobrze dla bardzo modularnych aplikacje - w moim przypadku większość moich aplikacji ma 3-5 dużych "modułów", które naprawdę nie mają ze sobą nic wspólnego. Na przykład jeden moduł może być pulpitem sprzedaży, a jeden może być pulpitem księgowym. Nie rozmawiają ze sobą. Jednak zarząd może chcieć otworzyć oba i są to oddzielne ramki na pasku zadań ułatwia mu życie.
3. ułatwia użytkownikom końcowym odwoływanie się do materiałów zewnętrznych - kiedyś miałem to sytuacja: Moja aplikacja miała "przeglądarkę danych", z której można kliknąć "Dodaj nowy" i otworzy się ekran wprowadzania danych. Początkowo oba były JFrame S. jednak chciałem, aby ekran wprowadzania danych był JDialog, którego rodzicem był przeglądarka danych. Wprowadziłem tę zmianę i natychmiast otrzymałem telefon od użytkownika końcowego, który polegał w dużej mierze na tym, że mógł zminimalizować lub zamknąć przeglądarkę i utrzymać otwarty Edytor , podczas gdy odwoływał się do innej części programu (lub strony internetowej, Nie wiem, czy pamiętaj). On jest Nie na multi-monitorze, więc potrzebował okna dialogowego wejścia, aby było pierwsze, a coś innego, aby było drugie, z przeglądarką danych całkowicie ukrytą. To było niemożliwe z JDialog i na pewno byłoby niemożliwe z JInternalFrame, jak również. Żałośnie zmieniłem go z powrotem na oddzielny JFrames dla jego zdrowia psychicznego, ale to dało mi ważną lekcję.
4. Mit: trudno zakodować - Z mojego doświadczenia wynika, że nie jest to prawdą. Nie rozumiem, dlaczego miałby to być jakikolwiek łatwiej utworzyć JInternalFrame niż JFrame. W rzeczywistości, z mojego doświadczenia, JInternalFrames oferują znacznie mniejszą elastyczność. Opracowałem systematyczny sposób obsługi otwierania i zamykania JFrames W moich aplikacjach, który naprawdę działa dobrze. Kontroluję ramkę prawie całkowicie z samego kodu ramki; tworzenie nowej ramki, SwingWorkerS, które kontrolują pobieranie danych z wątków tła i kodu GUI NA EDT, przywracanie / doprowadzanie do przodu ramki, jeśli użytkownik spróbuje otworzyć ją dwa razy, itp. All you trzeba otworzyć moje JFrame S jest wywołanie publicznej statycznej metody open() i metoda otwarta, w połączeniu ze zdarzeniem windowClosing() obsługuje resztę (czy ramka jest już otwarta? nie jest otwarty, ale ładuje się? itd.) Zrobiłem to podejście szablonem, więc nie jest trudno zaimplementować dla każdej klatki.
5. Myth / Unproven: Resource Heavy - chciałbym zobaczyć kilka faktów stojących za tym spekulacyjnym oświadczeniem. Chociaż, być może, można powiedzieć, że a JFrame potrzebuje więcej miejsca niż a JInternalFrame, nawet jeśli otworzysz 100 JFrame s, ile jeszcze zasobów naprawdę byś zużywał? Jeśli twoim zmartwieniem jest wyciek pamięci z powodu zasobów: wywołanie dispose() uwalnia wszystkie zasoby używane przez ramkę do zbierania śmieci (i powtarzam, JInternalFrame powinno wywoływać dokładnie ten sam problem).

Napisałem dużo i czuję, że mógłbym napisać więcej. W każdym razie, mam nadzieję, że nie poddam się głosowaniu tylko dlatego, że jest to niepopularna opinia. Pytanie jest oczywiście cenne i mam nadzieję, że udzieliłem cennej odpowiedzi, nawet jeśli to nie jest powszechna opinia.

Świetnym przykładem wielu klatek/pojedynczego dokumentu na klatkę (SDI) vs pojedynczej klatki / wielu dokumentów na klatkę (MDI) jest Microsoft Excel. Niektóre z zalet MDI:

Możliwe jest posiadanie kilku okien w kształcie nie prostokątnym - aby nie ukrywały pulpitu lub innego okna przed innym procesem (np. przeglądarką internetową).]}
• możliwe jest otwarcie okna z innego procesu nad jednym oknem Excela podczas zapisu w w przypadku programu MDI, próba zapisu w jednym z wewnętrznych okien spowoduje skupienie się na całym oknie programu Excel, a tym samym ukrycie okna przed innym procesem.]} Możliwe jest posiadanie różnych dokumentów na różnych ekranach, co jest szczególnie przydatne, gdy ekrany nie mają tej samej rozdzielczości [41]}

MDI (Multiple-Document Interface, czyli każde okno może mieć wiele dokumentów):

Chciałbym przeciwstawić argument "nie Przyjazny dla użytkownika" za pomocą przykładu, z którym właśnie byłem zaangażowany.

W naszej aplikacji mamy główne okno, w którym użytkownicy uruchamiają różne "programy" jako oddzielne zakładki. W miarę możliwości staraliśmy się utrzymać naszą aplikację w tym pojedynczym oknie.

Jeden z "programów", które uruchamiają, prezentuje listę raportów wygenerowanych przez system, a użytkownik może kliknąć ikonę w każdej linii, aby otworzyć okno przeglądarki raportów. Ta przeglądarka pokazuje odpowiednik strony A4 w pionie/poziomie, więc użytkownicy lubią, że to okno jest dość duże, prawie wypełniając swoje ekrany.

Kilka miesięcy temu zaczęliśmy otrzymywać prośby od naszych klientów, aby te okna przeglądarki raportów były modne, aby mogli mieć wiele raportów otwartych w tym samym czasie.

Przez pewien czas opierałem się tej prośbie, ponieważ uważałem, że nie jest to dobre rozwiązanie. Jednak zmieniłem zdanie, gdy dowiedziałem się, jak użytkownicy omijali ten "niedobór" naszego systemu.

Otwierali przeglądarkę, używając funkcji "Zapisz jako", Aby zapisać raport jako plik PDF do określonego katalogu, Używając programu Acrobat Reader, aby otworzyć plik PDF, a następnie zrobili to samo z następnym raportem. Będą mieli wiele czytników Acrobat działających z różnymi wyjściami raportów, na które chcieliby spojrzeć.

Więc ustąpiłem i uczyniłem widza modnym. Oznacza to, że każda przeglądarka ma pasek zadań icon.

Kiedy najnowsza wersja została im wydana w zeszłym tygodniu, przytłaczająca odpowiedź od nich jest taka, że ją kochają. To jedno z naszych najpopularniejszych ostatnich ulepszeń systemu.

Więc śmiało powiedz swoim użytkownikom, że to, czego chcą, jest złe, ale ostatecznie nie przyniesie Ci to żadnych korzyści.

NIEKTÓRE UWAGI:

Wydaje się, że najlepszą praktyką jest używanie JDialog dla tych bezmodelowych okien.]}
• użyj konstruktorów, które używają nowego ModalityType raczej niż argument boolean modal. To właśnie daje tym oknom ikonę paska zadań.
• W przypadku bezmodalnych okien dialogowych przekaż konstruktorowi rodzica null, ale zlokalizuj go względem okna 'rodzica'.
• Wersja 6 Javy w systemie Windows ma błąd , co oznacza, że główne okno może stać się "zawsze na szczycie" bez mówienia o tym. Aktualizacja do wersji 7, aby to naprawić

Stwórz jInternalFrame w ramce głównej i uczyń go niewidzialnym. Następnie możesz go użyć do dalszych wydarzeń.

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

Minęło trochę czasu od ostatniego dotknięcia swingu, ale ogólnie jest to zła praktyka, aby to zrobić. Niektóre z głównych wad, które przychodzą na myśl:

• Jest to droższe: będziesz musiał przeznaczyć o wiele więcej zasobów, aby narysować JFrame, inny rodzaj kontenera okien, taki jak Dialog lub Jinternalframe.

• Nie jest łatwy w obsłudze: nie jest łatwo nawigować do kilku połączonych ze sobą JFrame, będzie to wyglądało tak, jakby twoja aplikacja była zestaw aplikacji niespójnych i źle zaprojektowanych.

• Jest łatwy w użyciu JInternalFrame jest to rodzaj retoryczny, teraz jest o wiele łatwiejszy i inni ludzie mądrzejsi (lub z większą ilością wolnego czasu) niż my już przemyśleli schemat pulpitu i jinternalframe, więc polecam go używać.

Zdecydowanie zła praktyka. Jednym z powodów jest to, że nie jest zbyt "przyjazny dla użytkownika", ponieważ każda JFrame pokazuje nową ikonę paska zadań. Kontrolowanie wielu JFrame s sprawi, że będziesz wyrywał włosy.

Osobiście użyłbym jednego JFrame do twojego rodzaju aplikacji. Metody wyświetlania wielu rzeczy zależy od ciebie, jest ich wiele. Canvases, JInternalFrame, CardLayout, nawet JPanel jest możliwe.

Wiele obiektów JFrame = ból, kłopoty i problemy.

Myślę, że używanie wielu Jframes nie jest dobrym pomysłem.

Zamiast tego możemy użyć JPanel s więcej niż jeden lub więcej JPanel w tym samym JFrame.

Możemy również przełączać się między tymi JPanel s. daje nam to swobodę wyświetlania więcej niż na rzeczy w JFrame.

Dla każdego JPanel Możemy zaprojektować różne rzeczy i wszystko to JPanel może być wyświetlane na pojedynczym JFrame pojedynczo.

Aby przełączyć się pomiędzy tą JPanel Użyj JMenuBar z JMenuItems dla każdego JPanel lub "JButton for each JPanel"`

Więcej niż jeden JFrame nie jest dobrą praktyką, ale nie ma nic złego, jeśli chcemy więcej niż jeden JFrame.

Ale lepiej zmienić jeden JFrame dla naszych różnych potrzeb, niż mieć wiele JFrames.

Jeśli ramki mają być tego samego rozmiaru, dlaczego nie utworzyć ramki i przekazać ją jako odniesienie do niej.

Po przejściu ramki możesz zdecydować, jak ją wypełnić. To byłoby jak posiadanie metody obliczania średniej z zestawu liczb. Czy stworzyłbyś metodę w kółko?

Nie jest to dobra praktyka, ale nawet jeśli chcesz jej użyć, możesz użyć wzoru Singletona jako jego dobrego. Użyłem wzorów Singletona w większości mojego projektu jest dobry.