Ogólnie rzecz biorąc, w Javie istnieją detektory i programy obsługi zdarzeń.
Mam na myśli to, że używam ich nieświadomie, po prostu cokolwiek jest dostępne w API.
Moje pytanie brzmi: w jakim przypadku używamy detektorów, a w jakim przypadku używamy handlerów dla zdarzeń?
Jaka jest między nimi różnica? Charakterystyka ??
Szukałem powodów i nie mogłem znaleźć właściwego wyjaśnienia dla języka Java.
Odpowiedzi:
Nie ma formalnie zdefiniowanej różnicy między słuchaczami a obsługą. Niektórzy ludzie prawdopodobnie argumentowaliby, że są wymienne. Dla mnie mają jednak nieco inne znaczenie.
Detektor to obiekt, który subskrybuje zdarzenia ze źródła. Por. wzór obserwator . Zwykle możesz mieć wielu detektorów subskrybujących każdy typ zdarzenia i są one dodawane za pomocą addXyzListenermetod.
Przykład:MouseListener w API Java.
Procedura obsługi to obiekt odpowiedzialny za obsługę określonych zdarzeń. Typowym scenariuszem byłoby dostarczenie procedury obsługi dla określonego zdarzenia / zadania jako argumentu dla konstruktora lub ustawienie procedury obsługi za pomocą setXyzHandlermetody. Innymi słowy, zwykle masz jedną procedurę obsługi dla każdego typu zdarzenia.
Przykład:MemoryHandler w API Java.
Najbardziej podstawową różnicą jest skojarzenie
Ogólnie rzecz biorąc, będzie tylko jeden centralny Handler Manager, który zarządza wszystkimi zdarzeniami, podczas gdy w przypadku Słuchacza każdy Podmiot, który będzie chciał słuchać, będzie musiał zarządzać własną Kolekcją słuchaczy
Tak to widzę:
A słuchaczy zegarki zdarzenia mają być zwolniony. Na przykład a KeyListenerczeka na KeyEvents, a MessageListenerczeka na przybycie komunikatów do kolejki i tak dalej.
Program obsługi jest odpowiedzialny za obsługę zdarzenia. Zwykle słuchacze i opiekunowie idą ręka w rękę. Na przykład KeyListener informuje ExitHandler, że „naciśnięto literę Q”, a program obsługi wykonuje operacje logiczne, takie jak czyszczenie zasobów i prawidłowe zamykanie aplikacji. Podobnie, ButtonClickListener powiedziałby temu samemu ExitHandler, że został kliknięty przycisk „Wyjście”. Tak więc w tym przypadku masz dwa różne zdarzenia, dwóch różnych nasłuchiwaczy, ale jedną procedurę obsługi.
Odbiornik to obiekt, który jest powiadamiany o wystąpieniu zdarzenia i ma 2 główne wymagania - 1 - musi być zarejestrowany w jednym lub większej liczbie źródeł, aby otrzymywać powiadomienia o określonych typach zdarzeń 2 - musi implementować metody odbierania i przetwarzania te powiadomienia. Handler jest odpowiedzialny za obsługę wydarzeń.
Odbiornik nasłuchuje zdarzeń, które są obiektami wartości danych opisującymi zdarzenie. Kiedy zdarzenie miało miejsce i kolejność wydarzeń jest często ważna. Naciśnięcie klawisza „0”, a następnie „1” różni się od „1” i „0”.
Program obsługi obsługuje złożony obiekt, np. Nowe połączenie Socket. Program obsługi może przetwarzać obiekt przez dowolny czas. Czas powstania obiektu i porządek nie jest tak ważny. Połączenie od klienta client0 lub client1 może nastąpić w dowolnej kolejności.
Myślę, że różnica jest subtelna, ponieważ konkretny Listener jest również programem obsługi zdarzeń lub przynajmniej ma metodę, którą można uznać za obsługę zdarzeń. Oznacza to, że konkretny Listener obsługuje lub zarządza reakcją na zdarzenie po otrzymaniu obiektu zdarzenia (ze źródła zdarzenia) ze wszystkimi użytecznymi informacjami o zdarzeniu, które właśnie zaszło (na źródle zdarzenia). Ponieważ ten Listener musi zaimplementować interfejs xxxListener, który zmusza go do zaimplementowania co najmniej jednej metody, która jest z kolei wykonywana przez obiekt źródła zdarzenia, gdy wystąpi zdarzenie, więc sam Listener może być uważany za procedurę obsługi, a dokładniej, metodę interfejs Listener zaimplementowany przez obiekt Listener można uznać za rzeczywistą procedurę obsługi zdarzeń. Widzę więc procedurę obsługi zdarzeń jako kod, który jest wykonywany w reakcji na zdarzenie. Różni się to od obiektu Listener, który jest elementem bardziej abstrakcyjnej koncepcji, takiej jak wzorzec projektowy Observer. To jest mój osobisty pogląd na ten temat.
Koncepcyjnie są to samo - obiekt, który wykonuje jakąś akcję w odpowiedzi na zdarzenie interfejsu użytkownika. Ogólnie w Swing te obiekty nazywane są „programami obsługi” na poziomie wyglądu (do obsługi zdarzeń widżetów niskiego poziomu) i „detektorami” na bardziej abstrakcyjnym poziomie interfejsu użytkownika (gdzie będziesz implementować logikę aplikacji ).
EventHandler został wprowadzony w JavaFX dla wszystkich kontrolek interfejsu użytkownika. Natomiast Listener jest wypożyczany dla Observables, takich jak właściwości.
EventHandler to sposób na rozróżnienie obserwowalnych zdarzeń i zdarzeń interfejsu użytkownika.
Próbowałem zrozumieć wszystkie informacje i zgubiłem się. Patrzyłem na Delphi (Pascal), C, C ++, java ... nic nie jest jasne, więc po miesiącu jest to problem, jak go widzę. Mogę być całkowicie zboczony, więc proszę powiedz mi ... grzecznie, proszę.
Jeden nadawca zdarzenia, jeden catcher, o ile nadawca rejestruje catcher. Mam 4 okna dialogowe, które muszą być aktualizowane za każdym razem, gdy plik (którego kod obsługi znajduje się w innym module niż 4 okna dialogowe) ulegnie zmianie. Rozważałem aktualizację każdego z nich w staroświecki sposób, ale potem przyjrzałem się zdarzeniom Delphi i obsłudze wiadomości. Zobaczmy:
Plik F (nadawca) skończył czytać i powinien powiadomić Dialog 1..4 o fakcie, że są teraz dane do wyświetlenia i użytkownika do zabawy. Co jest najlepsze?
Spróbuj zarejestrować okna dialogowe 1..4 jako nasłuchiwanie i sprawić, by nadawca w jakiś sposób wywołał OnUpdatedDataEvent?
Spróbuj wysłać wiadomość przez system, mając nadzieję, że Dialogi 1..4 ją złapią?
Zwróć uwagę, że zdarzenie zachowuje powiązania, podczas gdy wiadomości nie ... i są trudne do debugowania.
I zastanawiam się, w jaki sposób blok kodu File będzie mógł zarejestrować 4 słuchacze (okna dialogowe)?
To, na co patrzę, to możliwość wywołania kaskadowego, co oznacza, że dzwoniący dzwoni do jednego słuchacza, który dzwoni do następnego ... aż do końca łańcucha. Zastanawiam się nawet, czy to w ogóle możliwe.
Przykład:
Powiedz plik F to lista języków. Teraz DialogBox 1 robi coś z listą (na przykład dodaje nowy język); to pole kombi aktualizuje plik F; to z kolei wyzwala DataUpdatedEvent. 4 okna dialogowe zawierają, powiedzmy, TComboBoxes, które wyświetlają listę języków, gdy się pojawiają. Chcę, aby 4 pola zauważyły zmianę i zaktualizowały swoją własną zawartość pola kombi o świeżo zaktualizowany plik ... bez martwienia się o to, skąd pola kombi wiedzą, że muszą odświeżyć swoją zawartość. Jeśli zadziała zgodnie z założeniami, parametr Sender zostanie przeniesiony, a okno dialogowe, które wywołało zdarzenie dataUpdateEvent, zostanie pominięte, ponieważ zostanie już zaktualizowane. W końcu if sender = self, a następnie przejdź do następnego programu obsługi zdarzenia, powinno być łatwe do zaimplementowania.
Wszystko to dlatego, że chcę ćwiczyć mózg ... aby zapobiec chorobie Alzheimera, dodam, że niezbyt skuteczne.
To jest semantyka.