Użycie wielu ramek JFr: dobra czy zła praktyka? [Zamknięte]


531

Tworzę aplikację, która wyświetla obrazy i odtwarza dźwięki z bazy danych. Próbuję zdecydować, czy użyć osobnej ramki JFrame, aby dodać obrazy do bazy danych z GUI.

Zastanawiam się tylko, czy dobrą praktyką jest używanie wielu okien JFrame?


11
Tylko jeśli celujesz w konfigurację z wieloma monitorami!
DNA

17
Chciałbym również argumentować, że jest to niezależne od języka i ma związek z interfejsem użytkownika bardziej niż z Javą.
wchargin

6
Zgodziłbym się z tym @WChargin To pytanie stało się bardziej cenne, niż się spodziewałem!
Handlarz

1
Zauważam, że początkujący (jak ja) zwykle korzystają z wielu JFrame. Prawdopodobnie dlatego, że łatwiej jest wywołać go z wnętrza głównego JFrame niż przy użyciu powiedz CardLayout. Chociaż w niektórych przypadkach nie zaleca się korzystania z niego.
Hoodlum,

Debugowanie przypomina jedzenie kaktusa. Nie jest to wskazane.
Taslim Oseni

Odpowiedzi:


447

Zastanawiam się tylko, czy dobrą praktyką jest używanie wielu ramek JFrame?

Zła (zła, zła) praktyka.

  • Nieprzyjazny dla użytkownika: użytkownik widzi wiele ikon na pasku zadań, gdy oczekuje tylko jednej. Plus skutki uboczne problemów z kodowaniem.
  • Koszmar do kodowania i utrzymania:
    • Modalne okno dialogowe oferuje łatwą okazję do skupienia uwagi na treść tego okna - Wybierz / fix / anulować to, następnie kontynuować. Wiele klatek nie.
    • Okno dialogowe (lub ruchomy pasek narzędzi) z rodzicem pojawi się na pierwszym planie po kliknięciu rodzica - musiałbyś zaimplementować to w ramkach, jeśli było to pożądane zachowanie.

Istnieje wiele sposobów wyświetlania wielu elementów w jednym GUI, np .:

  • CardLayout(krótkie demo. ). Dobre dla:
    1. Pokazywanie okien dialogowych podobnych do kreatora.
    2. Wyświetlanie listy, drzewa itp. Dla elementów, które mają powiązany komponent.
    3. Przerzucanie między brakiem komponentu a widocznym komponentem.
  • JInternalFrame/JDesktopPane zwykle używany do MDI .
  • JTabbedPane dla grup komponentów.
  • JSplitPane Sposób wyświetlania dwóch składników, których znaczenie między jednym a drugim (rozmiarem) różni się w zależności od tego, co robi użytkownik.
  • JLayeredPane wiele dobrze dobranych komponentów.
  • JToolBarzazwyczaj zawiera grupy działań lub kontroli. Może być przeciągany wokół GUI lub całkowicie zgodnie z potrzebami użytkownika. Jak wspomniano powyżej, zminimalizuje / przywróci zgodnie z postępowaniem rodzica.
  • Jako elementy w JList(prosty przykład poniżej).
  • Jako węzły w JTree.
  • Układy zagnieżdżone .

Ale jeśli te strategie nie działają dla konkretnego przypadku użycia, spróbuj wykonać następujące czynności. Ustanów pojedynczy element główny JFrame, a następnie wyświetl JDialoglub JOptionPanewystąpień dla pozostałych elementów swobodnych, używając ramki jako elementu nadrzędnego dla okien dialogowych.

Wiele zdjęć

W tym przypadku, gdy wiele elementów jest obrazami, lepiej byłoby użyć jednego z poniższych:

  1. Pojedynczy JLabel(wyśrodkowany w panelu przewijania) do wyświetlenia dowolnego obrazu, który użytkownik jest zainteresowany w danym momencie. Jak widać w ImageViewer.
  2. Jeden rząd JList. Jak widać w tej odpowiedzi . Część „pojedynczego rzędu” działa tylko wtedy, gdy wszystkie mają takie same wymiary. Alternatywnie, jeśli jesteś przygotowany do skalowania obrazów w locie, a wszystkie mają ten sam współczynnik kształtu (np. 4: 3 lub 16: 9).


4
@AndrewThompson Nigdy wcześniej nie spotkałem się z sytuacją, w której potrzebowałem wielu JFrames i nigdy nie rozważałem tych problemów, dziękuję za wyjaśnienie!
Jeffrey,

4
@ user417896 „Po prostu zależy”. Nie, nie ma. Użyłem Gimpa. To okropne i powinno być MDI.
Andrew Thompson,

4
@ryvantage „Czy (Excel) powinien być MDI?” Dobre pytanie. Uważam, że powinien być oferowany użytkownikowi na dwa sposoby (z pewnością nie tylko w formie MDI). Na przykład: 1) Obecnie korzystam z TextPada i według konfiguracji do wyboru, otwieram osobne instancje, z których każdy oferuje wiele dokumentów pokazanych na liście. 2) Chociaż zwykle używam FF w trybie z kartami, od czasu do czasu przeciągam kartę do nowego okna. - Wspólnym czynnikiem w przykładach jest wybór użytkownika. Dostarcz aplikację. „jednak użytkownik tego chce”.
Andrew Thompson,

12
@AndrewThompson Właśnie odpowiedziałeś na swój własny argument swoim ostatnim komentarzem. W głównej odpowiedzi mówisz, że jest to zła praktyka i nigdy nie należy tego robić, ale w powyższym komentarzu mówisz, że czasami lubisz SDI i że powinniśmy zaoferować naszym użytkownikom wybór. Z pewnością tak właśnie powiedział użytkownik user417896 powyżej. To zależy. To jedna z moich największych nienawiści do zwierząt domowych wobec moich kolegów programistów. Fakt, że wielu z nich staje się fanatycznie religijnymi w związku z tak zwanymi „najlepszymi praktykami”. Nie mielibyśmy innowacyjnych interfejsów, które mamy dzisiaj, gdybyśmy wszyscy trzymali się „najlepszych praktyk” i nie myśleli poza rynkiem.
DuncanKinnear

4
Ogromne uogólnienie! Nie jest ZAWSZE pozwalanie użytkownikowi kontrolować okna indywidualnie i uzyskiwać do nich dostęp z poziomu paska zadań. Dobrą praktyką jest być świadomym wszystkich opcji i wybierać jedną inteligentnie. Z pewnością istnieją przypadki, w których wiele ramek JFrame ma sens.
Dawood ibn Kareem,

203

Wielokrotne JFramepodejście jest czymś, co wdrożyłem, odkąd zacząłem programować aplikacje Swing. W większości zrobiłem to na początku, ponieważ nie wiedziałem nic lepszego. Jednak w miarę dojrzewania mojego doświadczenia i wiedzy jako programisty oraz gdy zacząłem czytać i wchłaniać opinie tak wielu bardziej doświadczonych programistów Java, podjąłem próbę odejścia od wielorakiego JFramepodejścia (zarówno w bieżących, jak i przyszłych projektach) ) tylko po to, by spotkać się z ... uzyskać ten ... opór od moich klientów! Gdy zacząłem wdrażać modalne okna dialogowe do kontrolowania okien potomnych JInternalFrameoddzielnych 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, programisty, co oczywiście nie jest częstym scenariuszem.

Wyjaśnię więc korzyści płynące z wielorakiego JFramepodejścia, a także obalę niektóre z wad przedstawionych przez innych.

  1. Najwyższa elastyczność w układzie - Pozwalając osobnym JFrames, dajesz użytkownikowi końcowemu możliwość rozłożenia i kontrolowania tego, co jest na jego ekranie. Koncepcja wydaje się „otwarta” i niewiążąca. Tracisz to, gdy zbliżasz się do jednego dużego JFramei kilku JInternalFrames.
  2. Działa dobrze w przypadku bardzo modularnych aplikacji - w moim przypadku większość moich aplikacji ma 3–5 dużych „modułów”, które tak naprawdę nie mają ze sobą nic wspólnego. Na przykład jeden moduł może być pulpitem sprzedaży, a drugi może być pulpitem rachunkowości. Nie rozmawiają ze sobą ani nic. Jednak kierownictwo może chcieć otworzyć oba, a ich oddzielne ramki na pasku zadań ułatwiają mu życie.
  3. Ułatwia użytkownikom końcowym odwoływanie się do materiałów zewnętrznych - Kiedyś miałem taką sytuację: moja aplikacja miała „przeglądarkę danych”, w której można kliknąć „Dodaj nowy” i otworzyć ekran wprowadzania danych. Początkowo oba były JFrames. Chciałem jednak, aby ekran wprowadzania danych JDialogbył tym, którego rodzicem była przeglądarka danych. Dokonałem zmiany i natychmiast otrzymałem telefon od użytkownika końcowego, który w dużej mierze polegał na tym, że mógł zminimalizować lub zamknąć przeglądarkę i pozostawić otwarty edytor, podczas gdy odwoływał się do innej części programu (lub strony internetowej, nie nie pamiętam). Nie ma go na wielu monitorach, więc najpierw potrzebował okna dialogowego wejścia i czegoś innegona drugim miejscu, z całkowicie ukrytą przeglądarką danych. To było niemożliwe z, JDialoga na pewno byłoby niemożliwe z JInternalFramerównież. Niechętnie zmieniłem to z powrotem na oddzielne JFramesdla jego zdrowia psychicznego, ale nauczyło mnie to ważnej lekcji.
  4. Mit: trudny do zakodowania - z mojego doświadczenia nie jest to prawdą. Nie rozumiem, dlaczego łatwiej byłoby stworzyć JInternalFrameniż JFrame. Z mojego doświadczenia wynika, że JInternalFramesoferują 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 poziomu samego kodu ramki; tworzenie nowych ramek, SwingWorkerktóre kontrolują pobieranie danych w wątkach w tle i kod GUI w EDT, przywracanie / przybliżanie ramki, jeśli użytkownik spróbuje otworzyć ją dwukrotnie, itp. Wszystko, co musisz otworzyć, JFrameto wywołać publiczną metodę statyczną open()i metodę otwartą w połączeniu zwindowClosing() wydarzenie obsługuje resztę (czy ramka jest już otwarta? czy nie jest otwarta, ale ładowanie? itd.) Ustawiłem to podejście jako szablon, więc nie jest trudno wdrożyć dla każdej ramki.
  5. Mit / niesprawdzony: ciężkie zasoby - chciałbym zobaczyć kilka faktów za tym spekulacyjnym stwierdzeniem. Chociaż być może możesz powiedzieć, że JFramepotrzebujesz więcej miejsca niż a JInternalFrame, nawet jeśli otworzysz 100 JFrames, o ile więcej zasobów tak naprawdę byś zużył? Jeśli twoim problemem jest wyciek pamięci z powodu zasobów: wywołanie dispose()uwalnia wszystkie zasoby używane przez ramkę do zbierania elementów bezużytecznych (i ponownie mówię, że JInternalFramepowinieneś wywołać dokładnie ten sam problem).

Dużo napisałem i czuję, że mógłbym pisać więcej. W każdym razie mam nadzieję, że nie zostaniesz odrzucony po prostu dlatego, że jest to niepopularna opinia. Pytanie jest oczywiście cenne i mam nadzieję, że udzieliłem cennej odpowiedzi, nawet jeśli nie jest to powszechna opinia.

Doskonałym przykładem wielu ramek / pojedynczego dokumentu na ramkę ( SDI ) vs. pojedynczej ramki / wielu dokumentów na ramkę ( MDI ) jest Microsoft Excel. Niektóre zalety MDI:

  • możliwe jest posiadanie kilku okien w kształcie innym niż prostokątny - aby nie ukrywały pulpitu lub innego okna przed innym procesem (np. przeglądarką internetową)
  • możliwe jest otwarcie okna z innego procesu na jednym oknie programu Excel podczas pisania w drugim oknie programu Excel - przy pomocy MDI próba pisania w jednym z wewnętrznych okien spowoduje skupienie się na całym oknie programu Excel, stąd ukrywanie 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

SDI (interfejs jednego dokumentu, tzn. Każde okno może mieć tylko jeden dokument):

wprowadź opis zdjęcia tutaj

MDI (interfejs wielu dokumentów, tzn. Każde okno może zawierać wiele dokumentów):

wprowadź opis zdjęcia tutaj


16
Dobrze przemyślane. Jeśli masz wiele modułów, które nie mają ze sobą nic wspólnego, dlaczego nie utworzyć osobnych aplikacji? Ponadto, nie ma ograniczeń mówiących, że musisz używać modalnych okien dialogowych, możesz użyć niemodalnych okien dialogowych, aby służyć jako druga „ramka”.
Jeffrey

Bardzo dobra odpowiedź i szczegółowa odpowiedź, choć muszę się z tym zgodzić z @kleopatra .. Miałem kiedyś aplikację z ponad setką ekranów, w której użytkownicy chcieli porównywać dane wyjściowe z wielu ekranów / tego samego ekranu z różnymi danymi wejściowymi. Zbudowaliśmy niestandardowy system okienkowy, aby nam to umożliwić. Użytkownicy czuli się bardziej komfortowo, mając 2 JFrame do trzymania obok siebie;)
javatarz

Chociaż rozumiem twój argument, nadal wolałbym mieć wszystko w jednym JFramei dużym rodzicu JTabbedPane; ale z możliwością otwarcia drugiego okna (lub nawet więcej), w którym układ może być inny, oferując zatem zachowanie hybrydowe, w którym miłośnicy SDI są zadowoleni, a także MDI. We wszystkich przypadkach zawsze uważałem za JInternalFrameokropny wzór, który daje ci wszystkie niedogodności obu światów. Oferowana przez nich elastyczność jest do bani i pochłaniają dużo cennego miejsca na ekranie bez rzeczywistych celów.
Guillaume Polet

Zgadzam się, że SDI jest czasem odpowiednie (a użytkownicy często wolą). Jest jeszcze jedna wada i nie znalazłem do tej pory żadnego obejścia tego problemu, niestety: każda z nich JFramema własną ikonę paska zadań. Czasami jest to dokładnie to, czego chcesz, ale czasem nie jest. W WinAPI jest to łatwe do skonfigurowania, ale w Swing wydaje się, że nie da się tego zrobić.
Suma

@suma w tym przypadku myślę, że wybrałbym JDialogponad JFrame.
ryvantage

51

Chciałbym odeprzeć argument „nieprzyjazny dla użytkownika” przykładem, w który właśnie byłem zaangażowany.

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

Jeden z uruchamianych przez nich programów przedstawia listę raportów wygenerowanych przez system, a użytkownik może kliknąć ikonę w każdym wierszu, aby otworzyć okno dialogowe podglądu raportów. Ta przeglądarka pokazuje ekwiwalent pionowej / poziomej strony A4 w raporcie, więc użytkownicy lubią to okno, które jest dość duże, prawie wypełniając ekrany.

Kilka miesięcy temu zaczęliśmy otrzymywać żądania od naszych klientów, aby te okna przeglądarki raportów były modelowe, aby mogły mieć jednocześnie otwartych wiele raportów.

Przez pewien czas opierałem się tej prośbie, ponieważ nie sądziłem, że to dobre rozwiązanie. Jednak zmieniłem zdanie, gdy dowiedziałem się, jak użytkownicy radzą sobie z tym „brakiem” naszego systemu.

Otwierali przeglądarkę, używając funkcji „Zapisz jako”, aby zapisać raport jako plik PDF w określonym katalogu, używając Acrobat Reader do otwarcia pliku PDF, a następnie zrobiliby to samo z następnym raportem. Mają wiele czytników Acrobat działających z różnymi danymi wyjściowymi raportów, które chcieli przejrzeć.

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

Kiedy najnowsza wersja została im wydana w zeszłym tygodniu, przytłaczającą odpowiedzią jest to, że UWIELBIAJĄ to. To jedno z naszych najpopularniejszych najnowszych ulepszeń systemu.

Więc mów dalej i powiedz użytkownikom, że to, czego chcą, jest złe, ale ostatecznie nie zrobi ci żadnych przysług.

NIEKTÓRE UWAGI:

  • Wydaje się, że najlepszą praktyką jest używanie JDialog w tych modelowych oknach
  • Użyj konstruktorów, które używają argumentu nowego ModalityTypezamiast logicznego modal. Dzięki temu w tych oknach dialogowych pojawia się ikona paska zadań.
  • W przypadku dialogów niemodalnych przekaż konstruktorowi zerowy element nadrzędny, ale zlokalizuj je względem okna „nadrzędnego”.
  • Wersja 6 Java na Windows ma błąd, który oznacza, że ​​twoje główne okno może stać się „zawsze na wierzchu” bez twojej wiedzy. Zaktualizuj do wersji 7, aby to naprawić

6
To jest dokładnie moje doświadczenie. Jeśli jestem pewien, że robisz coś złego, gdy ludzie próbują obejść twoją łatwość obsługi, aby robić to, co naprawdę chcą. Funkcjonalność jest królem.
ryvantage

Jednym ze sposobów obejścia tego jest zezwolenie na otwarcie wielu JFrame, z których wszystkie oferują tę samą funkcjonalność, ale domyślnie wszystko odbywa się w jednym oknie. To pozwala użytkownikowi wybrać pomiędzy SDI lub MDI.
Guillaume Polet

Przepraszam? Czy możesz wyjaśnić swoje rozwiązanie nieco lepiej? Jak może to być jedno okno ORAZ wiele okien? Mamy jedno główne okno, w którym działa główna aplikacja, ale czasami musimy otwierać okna dialogowe, a czasami te okna dialogowe (w zależności od wymagań użytkownika) muszą być niemodalne. Ustalanie zasad, że interfejs powinien być w ten sposób lub że po prostu wykopie dla ciebie wielką dziurę.
DuncanKinnear

1
@GuillaumePolet Zgadzam się z Duncanem, czy możesz wyjaśnić, co masz na myśli? Podzielam jego zamieszanie
Ungeheuer,

Myślę, że chodzi mu o to, że użytkownik może uruchomić wiele kopii aplikacji („JFrame”), ale wewnątrz każdej z nich jest SDI. Jednak nasza aplikacja kliencka jest bardzo grubym klientem, więc byłoby to podejście wymagające dużych zasobów.
DuncanKinnear,

20

Zrób jInternalFrame w ramce głównej i uczyń ją niewidoczną. Następnie możesz użyć go do dalszych wydarzeń.

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

19

Minęło trochę czasu od ostatniego dotknięcia huśtawki, ale generalnie 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ł przydzielić znacznie więcej zasobów, aby narysować JFrame niż inny rodzaj kontenera okien, taki jak Dialog lub JInternalFrame.

  • Nie jest przyjazny dla użytkownika: Nie jest łatwo nawigować w grupie JFrame sklejonych razem, będzie wyglądać, jakby twoja aplikacja była zbiorem niespójnych i źle zaprojektowanych aplikacji.

  • Jest łatwy w użyciu JInternalFrame Jest to rodzaj retoryczny, teraz jest o wiele łatwiejszy i inni ludzie mądrzejsi (lub z więcej wolnego czasu) niż my już przemyśleli wzorzec Desktop i JInternalFrame, więc polecam go użyć.


7
Czy nie masz tego samego efektu dla użytkownika, gdy używasz wielu JInternalFrame? Osobiście nie zgadzam się na użycie JInternalFrame! CardLayoutjest prawdziwym błogosławieństwem!
Branislav Lazic

4
Zgadzam się z @ brano88. JInternalFramenie oferuje żadnych korzyści w żadnym z trzech wspomnianych przypadków (1. gdzie dowody JInternalFramesą lżejsze niż JFrame? 2. Twoje JInternalFramemogą być tak samo zagracone / niechlujne / utknąć razem jak kilka JFrames. 3. Jak to jest JInternalFramełatwiejsze? ten sam dokładny kod, z wyjątkiem tego, że jeden jest zawarty w a, JDesktopPanea drugi w naturalnym obszarze ekranu.
Brzmi to

1
1. JFrame jest składnikiem ciężkim w porównaniu do JInternalFrame, który jest lekki. 2. Czy kiedykolwiek widziałeś aplikację, która zawiera mnóstwo okien jednocześnie, aby była funkcjonalna? IDE, przeglądarki, nawet w aplikacjach finansowych celem jest utrzymanie go w tym samym zakresie. 3. W przeszłości stwierdziłem, że JIF jest bardzo łatwy w użyciu i nie mam żadnych skarg, oczywiście, że wybieram komponent, który najlepiej pasuje do scenariusza
Necronet

4
1. Chciałbym zobaczyć na to dowód. Oba są obiektami, oba są JComponents, oba mają prawie identyczne struktury, z wyjątkiem tego, że jeden jest renderowany na JDesktopa drugi nie. Znowu przepraszam, ale wierzę, że spekulujesz na temat „wagi” JFrame. 2. Moje aplikacje używają SDI, a moi klienci są bardzo zadowoleni. Powiedziałeś jednak „masę okien”, co oczywiście byłoby do bani. Ale chodzi mi o to, że „tona” JInternalFramessałaby równie źle! Jeśli mówisz, że JIF pozwalają ci być niechlujnym projektantem interfejsu użytkownika, to okropne. Zaśmiecony bałagan to zagracony bałagan, zarówno JF, jak i JIF.
ryvantage

2
„oczywiście wybierz komponent, który najlepiej pasuje do scenariusza”
Necronet

10

Zdecydowanie zła praktyka. Jednym z powodów jest to, że nie jest zbyt „przyjazny dla użytkownika”, ponieważ każdy JFramepokazuje nową ikonę paska zadań. Kontrolowanie wielu JFrames sprawi, że wyrwiesz włosy.

Osobiście użyłbym JEDNEJ JFramedla twojego rodzaju aplikacji. Metody wyświetlania wielu rzeczy zależą od Ciebie, jest ich wiele. CanvasES JInternalFrame, CardLayoutnawet JPanels ewentualnie.

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


9
hmm ... nic nowego w porównaniu do przyjętej odpowiedzi, afaics?
kleopatra,

5
„Każda JFrame pokazuje nową ikonę paska zadań” - dotyczy to tylko systemu Windows! W systemie Mac OS X każda aplikacja ma tylko jedną ikonę stacji dokującej, niezależnie od liczby otwartych okien, i często aplikacje mają wiele okien najwyższego poziomu.
Rolf

8

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

Zamiast tego możemy użyć JPanelwięcej niż jednego lub więcej JPanelw tym samym JFrame.

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

Dla każdego z nich JPanelmożemy zaprojektować różne rzeczy, a wszystko to JPanelmoże być wyświetlane pojedynczo JFrame.

Aby przełączać się między tym JPanel, a korzystanie JMenuBarz JMenuItemsdla każdego JPanellub „JButton for eachJPanel`.

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

Ale lepiej jest zmienić jeden JFramedla naszych różnych potrzeb niż mieć wiele JFrames.


5

Jeśli ramki będą 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 tak, jakby mieć metodę obliczania średniej z zestawu liczb. Czy tworzysz tę metodę w kółko?


1
To w zasadzie robienie tego, co potrafią Cardlayout i JTabbedPane, ale robienie tego w odwrotnej kolejności i nadmierne komplikowanie kodu, podczas gdy masz czyste i łatwe rozwiązanie, aby osiągnąć to samo.
Guillaume Polet

4

Nie jest to dobra praktyka, ale nawet jeśli chcesz jej użyć, możesz użyć wzorca singletonu jako dobrego. Używałem wzorców singletonów w większości moich projektów, które są dobre.


3
Wzór Singleton to koszmar. Każdy projekt, który chce skalować, powinien za wszelką cenę unikać wzorca singletonu.
Guillaume Polet
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.