Czy zdarzenia są używane tylko do programowania GUI?

Czy zdarzenia są używane tylko do programowania GUI?

Jak sobie radzisz w normalnym programowaniu zaplecza, gdy coś dzieje się z tą inną rzeczą?

Nie. Są naprawdę przydatne do wdrażania obserwatorów i upewnienia się, że klasy są zamknięte na modyfikacje.

Powiedzmy, że mamy metodę rejestrującą nowych użytkowników.

public void Register(user) {
    db.Save(user);
}

Następnie ktoś decyduje, że należy wysłać wiadomość e-mail. Możemy to zrobić:

public void Register(user) {
    db.Save(user);
    emailClient.Send(new RegistrationEmail(user));
}

Ale właśnie zmodyfikowaliśmy klasę, która powinna być zamknięta na modyfikacje. Prawdopodobnie w porządku dla tego prostego pseudokodu, ale prawdopodobnie droga do szaleństwa w kodzie produkcyjnym. Ile czasu zajmuje ta metoda do 30 wierszy kodu, które ledwo związane są z pierwotnym celem stworzenia nowego użytkownika?

O wiele przyjemniej jest pozwolić klasie na wykonanie swojej podstawowej funkcji i wywołać zdarzenie informujące każdego, kto nasłuchuje, że użytkownik jest zarejestrowany, i że może podjąć wszelkie niezbędne działania (na przykład wysłać wiadomość e-mail).

public void Register(user) {
    db.Save(user);

    RaiseUserRegisteredEvent(user);
}

Dzięki temu nasz kod jest czysty i elastyczny. Jednym z często pomijanych elementów OOP jest to, że klasy wysyłają do siebie wiadomości . Wydarzenia to te wiadomości.

Nie.

Klasycznym przykładem zdarzeń wykorzystywanych w logice innej niż GUI są wyzwalacze bazy danych.

Wyzwalacze to kod, który jest wykonywany, gdy zdarzenie ma miejsce (WSTAW, USUŃ itp.). Wydaje mi się wydarzeniem.

Oto definicja wydarzenia z Wikipedii:

W informatyce zdarzenie to czynność lub zdarzenie rozpoznawane przez oprogramowanie, które może być obsługiwane przez oprogramowanie. Zdarzenia komputerowe mogą być generowane lub wyzwalane przez system, przez użytkownika lub w inny sposób. Zazwyczaj zdarzenia są obsługiwane synchronicznie z przebiegiem programu, co oznacza, że ​​oprogramowanie może mieć jedno lub więcej dedykowanych miejsc, w których zdarzenia są obsługiwane, często pętla zdarzeń. Źródłem zdarzeń jest użytkownik, który może wchodzić w interakcje z oprogramowaniem, na przykład naciskając klawisze na klawiaturze. Innym źródłem jest urządzenie sprzętowe, takie jak zegar. Oprogramowanie może również wyzwalać własny zestaw zdarzeń w pętli zdarzeń, np. W celu zakomunikowania zakończenia zadania. Mówi się, że oprogramowanie, które zmienia swoje zachowanie w odpowiedzi na zdarzenia, jest sterowane zdarzeniem, często w celu interaktywności.

Nie wszystkie zdarzenia są generowane przez użytkowników. Niektóre są generowane przez licznik czasu, taki jak crontab, z bazy danych INSERT, jak wspomniałem wcześniej.

Definicja stwierdza również, że niektóre programy lub systemy są „sterowane zdarzeniami, często w celu interaktywności” , z czego można wywnioskować, że celem lub użytecznością zdarzeń nie jest wyłącznie, ale raczej często zapewnienie interaktywności (jak GUI chociaż niekoniecznie GUI, ponieważ programy CLI mogą być również interaktywne).

Programowanie oparte na zdarzeniach jest również używane do bardzo wydajnego programowania serwerów.

Przy typowym obciążeniu serwera większość czasu przetwarzania wyniku pochodzi w rzeczywistości z operacji we / wy. Na przykład ściąganie danych z dysku twardego (7200 obr./min) może potrwać do 8,3 ms. W przypadku nowoczesnego procesora GHz byłoby to około 1 miliona cykli zegara. Gdyby CPU za każdym razem czekał na dane (nic nie robiąc), stracilibyśmy DUŻO cykli zegara.

Tradycyjne techniki programowania omijają ten problem, wprowadzając wiele wątków . Procesor próbuje uruchomić setki wątków jednocześnie. Problem polega jednak na tym, że za każdym razem, gdy procesor przełącza wątek, do przełączenia kontekstu potrzeba setek cykli zegara . Zmiana kontekstu ma miejsce, gdy CPU kopiuje lokalną pamięć wątków do rejestrów CPU, a także zapisuje rejestr / stan starego wątku w pamięci RAM.

Dodatkowo każdy wątek musi zużywać pewną ilość pamięci do przechowywania swojego stanu.

Dzisiaj nastąpił nacisk na serwery, które mają jeden wątek, który działa w pętli. Następnie prace są przekazywane do pompy komunikatów , która działa jak kolejka dla pojedynczego wątku (podobnie jak w wątku interfejsu użytkownika). Zamiast czekać na zakończenie pracy, CPU ustawia zdarzenie wywołania zwrotnego, na przykład na dostęp do dysku twardego. Co zmniejsza przełączanie kontekstu.

Najlepszym przykładem takiego serwera jest Node.js , który, jak wykazano, jest w stanie obsłużyć 1 milion jednoczesnych połączeń przy użyciu skromnego sprzętu, podczas gdy serwer Java / Tomcat miałby problemy z kilkoma tysiącami.

Zdarzenia są również intensywnie wykorzystywane w programowaniu sieciowym (np. Nginx), aby uniknąć kosztownych pętli zajętości i zamiast tego zapewniają przejrzysty interfejs, aby dokładnie wiedzieć , kiedy dostępna jest określona operacja (operacje we / wy, pilne dane itp.). Jest to również rozwiązanie problemu C10k .

Podstawową ideą jest zapewnienie systemowi operacyjnemu zestawu gniazd (tj. Połączeń sieciowych) do monitorowania zdarzeń, wszystkich lub tylko niektórych, które są szczególnie zainteresowane (na przykład dane dostępne do odczytu); po wykryciu takiej aktywności przez system operacyjny na jednym z gniazd na liście otrzymasz powiadomienie o zdarzeniu, którego szukałeś przez interfejs API, a następnie będziesz musiał ustalić, skąd pochodzi i odpowiednio działać .

Teraz jest to abstrakcyjny widok niskiego poziomu, a ponadto trudno jest go dobrze skalować. Jednak istnieje wiele platform wyższego poziomu, które radzą sobie z tym w sposób nawet wieloplatformowy: Twisted for Python, Boost.Asio dla C ++ lub libevent dla C przychodzą mi na myśl.

Systemy wbudowane prawie zawsze są z natury sterowane zdarzeniami, nawet jeśli nie są wyraźnie zaprogramowane jako takie.

Te zdarzenia pochodzą z przerwań sprzętowych, naciśnięć przycisków, okresowych odczytów analogowo-cyfrowych, upływu czasu itp.

Wbudowane systemy o niskiej mocy są jeszcze bardziej podatne na zdarzenia; spędzają większość czasu na spaniu (procesor śpi w trybie niskiego poboru mocy), czekając, aż coś się wydarzy (to „coś” jest zdarzeniem).

Jednym z najbardziej popularnych i popularnych platform dla systemów osadzonych sterowanych zdarzeniami jest platforma kwantowa (QP) (QP działa również w systemie Linux, Windows i dowolnym systemie operacyjnym uniksopodobnym). Maszyny stanowe w naturalny sposób nadają się do programowania sterowanego zdarzeniami, ponieważ program nie jest „sekwencyjny” w typowym znaczeniu, jest to raczej zestaw „wywołań zwrotnych”, które są wywoływane w zależności od stanu systemu i bieżącego zdarzenia.

Wiadomości o wydarzeniach Gregor Hohpe.

Architektury napędzane wydarzeniami Gregor Hohpe.

Architektura SEDA , walijski, Culler, Brewer.

jak sobie radzisz w normalnym programowaniu backendowym, gdy coś się dzieje, czy to coś innego?

Maszyna stanów skończonych jest jednym powszechnym podejściem

Given(State.A)
When(Event.B)
Then(State.C)
    .and(Consequences.D)

W systemach wbudowanych zdarzenia występują podczas przerwań. Istnieje wiele źródeł przerwań, od timerów po I / O.

Również RTOS może mieć zdarzenia. Jeden przykład czeka na wiadomość z innego zadania.

Dla systemu niewbudowanego, ale czymś, co robiłem w C #, był system SCADA. Było wiele zdarzeń związanych z tym, co działo się w magazynie, gdy rozładowano ładunek część zdarzenia generowanego przez system, a inna część zapisywała nowy stan do bazy danych. Oczywiście mieliśmy klienta GUI, ale miał on tylko pokazać stan bazy danych, który odzwierciedlał stan magazynu. Było to oprogramowanie serwera zaplecza oparte na zdarzeniach i wątkach. Trudne do opracowania.

https://en.wikipedia.org/wiki/SCADA