Konwencje nazewnictwa dla wiadomości i aktorów Akka

Question

Obecnie jestem w trakcie tworzenia całkiem dużej aplikacji Java opartej na Akka i mam kilka problemów, które mnie nie mają końca.

Mój obecny układ pakiet wygląda trochę tak:

Mobile Moja klasa służąc jako nadzorcy aktorów wewnątrz opakowania actors.

Ponieważ nie chcę, aby utworzyć nowy zestaw Aktorzy dla każdego HttpClient i Account mijam tych wokół obiektów w wiadomości, które są przechowywane w opakowaniu wiadomości, wraz z końcowym ActorRef który odbiera końcowy rezultat. To jednak tworzy bardzo zagracony pakiet messages z inną wiadomością dla każdego aktora. Na przykład. MobileForActor1, Actor1ForMobile, MobileForActor2 itd. Teraz moje pytanie brzmi: czy istnieje konwencja, której należy użyć do tego rodzaju rzeczy, która zajmuje się tym problemem i jest moją strukturą (Mobile ->Actor1 ->Mobile ->Actor2 -> itp.) Sposób Akka chce, żeby to było, czy muszę po prostu przeskoczyć wiadomości (Mobile ->Actor1 ->Actor2 -> itp.)?

Teraz jestem wysyłając ConnectMessage do mojego Mobile aktora, który następnie wysyła go do Actor1, Actor1 przetwarza je i wysyła nową wiadomość z powrotem do Mobile, Mobile przesyła tę odpowiedź następnie Actor2 i cykl trwa z nowej wiadomości tworzone w oparciu o starą wiadomość. Na przykład. new Message2(message1.foo, message1.bar, message1.baz, newComputatedResult, newComputatedResult2, etc);

Czy to dobra praktyka, czy też powinienem dołączyć starą instancję (która może zawierać informacje, które nie są już przydatne) i zawierać nowe rzeczy? Na przykład. new Message2(message1, newComputatedResult, newComputatedResult2, etc);

Czy powinienem zrobić coś zupełnie innego?

Pomyślałem o użyciu TypedActors, ale te wymagają użycia wzoru wodospadu i nie wiem, jak przekazać na ActorRef słuchacza, który chce otrzymać końcowy wynik.

Mam nadzieję, że uczyniłem się na tyle zrozumiałym, ponieważ angielski nie jest moim dziewiczym językiem i że pytanie jest jasne dla wszystkich.

Jestem początkującym deweloperem firmy Akka i uwielbiam ten pomysł, ale ponieważ dokumentacja nie obejmuje tego zbyt dobrze, uznałem, że to najlepsze miejsce do zapytania. Dziękuje za przeczytanie!

Answer 1

Będę odpowiedział na kilka uwag w odpowiedzi na to, ponieważ miałem do czynienia z tymi samymi problemami w mojej krzywej uczenia się Akka. Myślę, że pytasz o pewne zasady, więc moje są tutaj zawarte.

Po pierwsze, tworzenie aktorów jest niezwykle tanie; są bardzo lekkie. Dlaczego więc nie utworzyć jednego dla każdego HttpClient i konta i nadać im odpowiednie nazwy pochodzące od ich tożsamości? Pozwala to również uniknąć konieczności ich przekazywania, prawdopodobnie, deklutacji kodu.

Po drugie, zachowaj nazwy swoich wiadomości krótko, koncentrując się i zaczynając od czasownika. Każda wiadomość powinna nakazać aktorowi zrobienie czegoś, więc chcesz, aby nazwa odzwierciedlała to za pomocą czasownika.

Po trzecie, zestawy wiadomości są powiązane z aktorem.Zazwyczaj deklaruję je w obiekcie towarzyszącym klasy aktora, więc używanie ich jest jak ActorClass.MessageName, chyba że jest w zakresie ActorClass, a następnie jest to tylko MessageName.

Po czwarte, dodaj licznik do imienia aktora. Często po prostu łączę licznik (użyj AtomicInteger) z nazwą typu (Car-1, Car-2 itd.).

Jeśli hierarchia jest dla ciebie ważna, polecam tylko dołączenie aktora nadrzędnego do nazwy. Coś w rodzaju Phone-1-in-Car-7 oznacza Phone-1 zawarte jest w Car-7. Następnie można zestawić hierarchię zarówno programowo, jak i ręcznie, podążając za linkami macierzystymi.

Myślę, że "Wiadomość" w numerze ConnectMessage jest zbędna. Po prostu nadaj nazwę wiadomości "Połącz" lub jeszcze lepiej "Połącz wszystko" (cokolwiek to jest, jeśli jest to istotne).

Nie nazwałbym twoich nazw wiadomości zbyt mocno, jak sugerujesz z Message2. Użyj minimalnej ilości informacji, aby była użyteczna dla każdego, kto będzie czytał te nazwiska. Myślę, że brak odpowiedzi na to pytanie wynikał z tej części pytania. Znalazłem to mylące, ponieważ brakuje wielu szczegółów.

Mam nadzieję, że to pomoże.