Swing (Java)
Swing jest niezależnym od platformy frameworkiem GUI typu „model-widok-kontroler” dla Javy, który podąża za jednowątkowym modelem programowania. Dodatkowo, szkielet ten zapewnia warstwę abstrakcji pomiędzy strukturą kodu a graficzną prezentacją GUI opartego na Swingu.
FoundationsEdit
Swing jest niezależny od platformy, ponieważ jest całkowicie napisany w Javie. Kompletną dokumentację wszystkich klas Swinga można znaleźć w Java API Guide dla wersji 6 lub Java Platform Standard Edition 8 API Specification dla wersji 8.
ExtensibleEdit
Swing jest architekturą opartą w dużym stopniu na modułach, co pozwala na „podłączanie” różnych niestandardowych implementacji określonych interfejsów frameworka: Użytkownicy mogą dostarczać własne implementacje tych komponentów, aby zastąpić domyślne implementacje za pomocą mechanizmu dziedziczenia w Javie poprzez javax.swing.LookAndFeel.
Swing jest frameworkiem opartym na komponentach, którego wszystkie komponenty ostatecznie wywodzą się z klasy javax.swing.JComponent. Obiekty Swing asynchronicznie wywołują zdarzenia, mają związane właściwości i odpowiadają na udokumentowany zestaw metod specyficznych dla danego komponentu. Komponenty Swing są komponentami JavaBeans, zgodnymi ze specyfikacją JavaBeans.
ConfigurableEdit
Silne uzależnienie Swinga od mechanizmów runtime i pośrednich wzorców kompozycji pozwala mu reagować w czasie działania na fundamentalne zmiany w ustawieniach. Na przykład, aplikacja oparta na Swingu jest zdolna do wymiany interfejsu użytkownika w czasie działania. Co więcej, użytkownicy mogą dostarczać własne implementacje wyglądu i odczuć, co pozwala na jednolite zmiany w wyglądzie i odczuciach istniejących aplikacji Swing bez żadnych programowych zmian w kodzie aplikacji.
Lightweight UI
Wysoki poziom elastyczności Swinga jest odzwierciedlony w jego nieodłącznej zdolności do zastępowania natywnego systemu operacyjnego hosta (OS) kontrolkami GUI do wyświetlania siebie. Swing „maluje” swoje kontrolki używając API Java 2D, zamiast wywoływać natywny zestaw narzędzi interfejsu użytkownika. W ten sposób komponent Swing nie posiada odpowiadającego mu natywnego komponentu GUI systemu operacyjnego i może być renderowany w dowolny sposób, który jest możliwy dzięki graficznemu GUI.
Jednakże, w swojej istocie, każdy komponent Swing opiera się na kontenerze AWT, ponieważ (Swing’s) JComponent rozszerza (AWT’s) Container. Pozwala to Swingowi na podłączenie się do ram zarządzania GUI systemu operacyjnego hosta, w tym kluczowych mapowań urządzenia/ekranu i interakcji użytkownika, takich jak naciśnięcia klawiszy lub ruchy myszy. Swing po prostu „transponuje” swoją własną (niezależną od systemu operacyjnego) semantykę na bazowe (specyficzne dla systemu operacyjnego) komponenty. Tak więc, na przykład, każdy komponent Swing maluje swoje renderowanie na urządzeniu graficznym w odpowiedzi na wywołanie component.paint(), które jest zdefiniowane w (AWT) Container. Jednak w przeciwieństwie do komponentów AWT, które delegowały malowanie do swojego natywnego dla systemu operacyjnego widżetu „wagi ciężkiej”, komponenty Swing są odpowiedzialne za własne renderowanie.
Ta transpozycja i rozłączność nie jest tylko wizualna, ale rozciąga się na zarządzanie i stosowanie przez Swing własnej, niezależnej od systemu operacyjnego semantyki dla zdarzeń wystrzeliwanych wewnątrz hierarchii zawierania komponentów. Ogólnie rzecz biorąc, architektura Swing przekazuje zadanie mapowania różnych smaków semantyki OS GUI na prosty, ale uogólniony wzorzec do kontenera AWT. Opierając się na tym uogólnionym wzorcu, tworzy własną, bogatą i złożoną semantykę GUI w postaci modelu JComponent.
Luźno sprzężone i MVCEdit
Biblioteka Swing w dużym stopniu wykorzystuje wzorzec projektowy model-widok-kontroler, który oddziela przeglądane dane od kontrolek interfejsu użytkownika, za pomocą których są one przeglądane. Z tego powodu, większość komponentów Swinga ma powiązane modele (które są określone w kategoriach interfejsów Java), a programiści mogą używać różnych domyślnych implementacji lub dostarczyć własne. Framework zapewnia domyślne implementacje interfejsów modeli dla wszystkich swoich konkretnych komponentów. Typowe użycie frameworka Swing nie wymaga tworzenia własnych modeli, ponieważ framework udostępnia zestaw domyślnych implementacji, które w sposób przezroczysty, domyślnie, są kojarzone z odpowiednią klasą potomną JComponent w bibliotece Swing. Ogólnie rzecz biorąc, tylko złożone komponenty, takie jak tabele, drzewa i czasami listy, mogą wymagać niestandardowych implementacji modeli wokół struktur danych specyficznych dla aplikacji. Aby dobrze zrozumieć potencjał, jaki daje architektura Swing, rozważmy hipotetyczną sytuację, w której niestandardowe modele dla tabel i list są wrapperami nad usługami DAO i/lub EJB.
Typowo, obiekty modelu komponentu Swing są odpowiedzialne za dostarczenie zwięzłego interfejsu definiującego uruchamiane zdarzenia i dostępne właściwości (koncepcyjnego) modelu danych do wykorzystania przez powiązany JComponent. Biorąc pod uwagę, że ogólny wzorzec MVC jest luźno sprzężonym, współpracującym wzorcem relacji między obiektami, model zapewnia programowe środki do dołączania nasłuchiwania zdarzeń do obiektu modelu danych. Zazwyczaj, zdarzenia te są skoncentrowane na modelu (np. zdarzenie „wiersz wstawiony” w modelu tabeli) i są mapowane przez specjalizację JComponent do znaczącego zdarzenia dla komponentu GUI.
Na przykład, JTable ma model o nazwie TableModel, który opisuje interfejs, w jaki sposób tabela uzyskuje dostęp do danych tabelarycznych. Domyślna implementacja tego działa na dwuwymiarowej tablicy.
Komponent widoku Swing JComponent jest obiektem używanym do graficznej reprezentacji konceptualnej kontroli GUI. Wyróżnikiem Swinga, jako frameworka GUI, jest jego zależność od programowo renderowanych kontrolek GUI (w przeciwieństwie do użycia natywnych kontrolek GUI systemu operacyjnego hosta). Przed aktualizacją Javy 6 Update 10, to rozróżnienie było źródłem komplikacji podczas mieszania kontrolek AWT, które używają natywnych kontrolek, z kontrolkami Swing w GUI (zobacz Mieszanie komponentów AWT i Swing).
Wreszcie, jeśli chodzi o kompozycję wizualną i zarządzanie, Swing preferuje układy względne (które określają relacje pozycji między komponentami) w przeciwieństwie do układów bezwzględnych (które określają dokładną lokalizację i rozmiar komponentów). Ta tendencja do „płynnego” porządkowania wizualnego wynika z jej pochodzenia ze środowiska operacyjnego apletów, które stanowiło ramy dla projektowania i rozwoju oryginalnego zestawu narzędzi Java GUI. (Koncepcyjnie, ten pogląd na zarządzanie układem jest dość podobny do tego, który informuje o renderowaniu zawartości HTML w przeglądarkach, i odnosi się do tego samego zestawu obaw, które motywowały ten pierwszy.)
Związek z AWTEdit
Od wczesnych wersji Javy, część Abstract Window Toolkit (AWT) zapewnia niezależne od platformy interfejsy API dla komponentów interfejsu użytkownika. W AWT każdy komponent jest renderowany i kontrolowany przez natywny komponent równorzędny specyficzny dla bazowego systemu okienkowego.
Przez kontrast, komponenty Swing są często opisywane jako lekkie, ponieważ nie wymagają alokacji natywnych zasobów w zestawie narzędzi okienkowych systemu operacyjnego. Komponenty AWT są określane jako komponenty wagi ciężkiej.
Większość API Swinga jest na ogół uzupełniającym rozszerzeniem AWT, a nie bezpośrednim zamiennikiem. W rzeczywistości, każdy lekki interfejs Swing ostatecznie istnieje w komponencie AWT heavyweight, ponieważ wszystkie komponenty najwyższego poziomu w Swing (JAppletJDialogJFrame, i JWindow) rozszerzają kontener najwyższego poziomu AWT. Przed aktualizacją Java 6 Update 10, używanie zarówno lekkich jak i ciężkich komponentów w tym samym oknie było ogólnie odradzane z powodu niezgodności Z-order. Jednak późniejsze wersje Javy naprawiły te problemy i zarówno komponenty Swing, jak i AWT mogą być teraz używane w jednym GUI bez problemów z kolejnością Z.
Główna funkcjonalność renderowania używana przez Swing do rysowania lekkich komponentów jest dostarczana przez Java 2D, inną część JFC.
Związek z SWTEdit
Standard Widget Toolkit (SWT) jest konkurencyjnym zestawem narzędzi, pierwotnie opracowanym przez IBM, a obecnie utrzymywanym przez społeczność Eclipse. Implementacja SWT ma więcej wspólnego z ciężkimi komponentami AWT. Daje to korzyści takie jak dokładniejsza wierność z bazowym natywnym zestawem narzędzi do okienkowania, kosztem zwiększonej ekspozycji na natywną platformę w modelu programowania.
Była znacząca debata i spekulacje na temat wydajności SWT w porównaniu ze Swingiem; niektórzy sugerowali, że silna zależność SWT od JNI uczyni go wolniejszym, gdy komponent GUI i Java muszą komunikować dane, ale szybszym w renderowaniu, gdy model danych został załadowany do GUI, ale nie zostało to potwierdzone w żaden sposób. Dość dokładny zestaw benchmarków z 2005 roku wykazał, że ani Swing, ani SWT nie przewyższają wyraźnie drugiego w ogólnym przypadku.