Proste wyjaśnienie „wzorca reaktora” z jego aplikacjami [zamknięte]

Wzór reaktora jest wyjaśniony w Wikipedii i jest nieco zbyt abstrakcyjny. Czy możesz opisać ten wzór w bardziej konkretny sposób? Idealnie z fragmentami kodu lub diagramami klas wysokiego poziomu opisującymi niektóre zastosowania wzorca reaktora.

design-patterns

— Eleco
źródło

Znalazłem to pytanie jako świetną odpowiedź - stackoverflow.com/questions/9138294/…

— Ryan Gibbons

Odpowiedzi:

Możesz sprawdzić oryginalny opis go opisujący http://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf

Wzorzec projektowy Reactor obsługuje żądania usług, które są dostarczane jednocześnie do aplikacji przez co najmniej jednego klienta. Każda usługa w aplikacji może składać się z metod serwerowych i jest reprezentowana przez oddzielną procedurę obsługi zdarzeń, która jest odpowiedzialna za wysyłanie żądań specyficznych dla usługi. Wysyłanie programów obsługi zdarzeń jest wykonywane przez dyspozytora inicjacji, który zarządza zarejestrowanymi programami obsługi zdarzeń. Demultipleksowanie żądań usług jest wykonywane przez demultiplekser zdarzeń synchronicznych.

— reese
źródło

Jak zauważysz czytając artykuł, Douglas Schmidt i in. Zaimplementowali wysoce wydajną i modułową strukturę C ++ o nazwie Adaptive Communications Environment, w której wzorzec Reactor odgrywa kluczową rolę. Sam framework wykorzystuje mnóstwo wzorców projektowych i warto go zbadać tylko ze względu na to. Jeśli szukasz przenośnego frameworka do budowania wysoce skalowalnych backendów C ++, to warto przyjrzeć się ACE.

— user2015735

@reese Link jest dziś uszkodzony, człowieku :(

— Allan Chua

@AllanChua Myślę, że to znalazłem - dre.vanderbilt.edu/~schmidt/PDF/Reactor.pdf

— sergeyrar

OP poprosił o „proste, konkretne” wyjaśnienie, a Ty zaproponowałeś coś jeszcze bardziej abstrakcyjnego niż Wikipedia ...

— Zhe

Reaktor umożliwia wydajne przetwarzanie wielu zadań, które blokują się (powiedzmy z powodu operacji we / wy) przy użyciu pojedynczego wątku. Reaktor zarządza pulą programów obsługi i uruchamia pętlę zdarzeń. Kiedy jest wezwany do wykonania zadania, łączy je z nowym lub nieobsadzonym programem obsługi, czyniąc je aktywnym. Pętla zdarzeń (1) znajduje wszystkie programy obsługi, które są aktywne i odblokowane (lub deleguje to do implementacji programu rozsyłającego) (2) wykonuje każdy z tych znalezionych programów obsługi sekwencyjnie, dopóki nie ukończą lub nie osiągną punktu, w którym są blokowane. Ukończone moduły obsługi stają się nieaktywne i puste do ponownego użycia, podczas gdy zablokowane aktywne moduły obsługi dają możliwość kontynuowania pętli zdarzeń. (3) Powtarza się od kroku (1)

— pasztet andrewski
źródło

Głosuj przeciw, ponieważ to nie jest poprawne

— SebNag

Podstawową ideą jest demultipleksowanie zdarzeń synchronicznych. Procedury obsługi zdarzeń są wywoływane tylko wtedy, gdy mogą działać w sposób nieblokujący, np. Cały pakiet danych jest dostępny w gnieździe sieciowym, czekając, aż program obsługi zdarzenia przetworzy dane. Umożliwia to sekwencyjne wykonywanie procedury obsługi zdarzeń w sposób nieblokujący

— SebNag

„wzorzec Reactor jest odpowiedzialny za demultipleksowanie i wysyłanie wielu procedur obsługi zdarzeń, które są wyzwalane, gdy możliwe jest synchroniczne zainicjowanie operacji bez blokowania”. z artykułu, do którego link znajduje się w przyjętej odpowiedzi

— SebNag

To wcale nie jest prawdą. W nie-reaktorze jest tyle wątków, ile jest we wzorze reaktora. Zamiast pętli zdarzeń można mieć pojedynczy wątek „sterujący”, który nie używa wzorca obserwator / detektor zdarzeń. Taka sama wydajność.

— Zombies