Соглашения об именах для сообщений и акков Akka

В настоящее время я занимаюсь созданием довольно крупного Java-приложения на базе Akka, и я сталкиваюсь с несколькими проблемами, которые меня не пугают.

Моя текущая компоновка пакетов выглядит примерно так:

Мой Mobile класс, служащий супервизором актеров внутри пакета actors.

Так как я не хочу создавать новый набор Актеров для всех HttpClient и Account, я передаю их в объекты сообщений, которые хранятся в пакете сообщений, вместе с конечной точкой ActorRef, которая получает окончательный результат. Однако это создает очень загроможденный пакет messages с другим сообщением для каждого актера. Например. MobileForActor1, Actor1ForMobile, MobileForActor2 и т.д. Теперь мой вопрос: существует ли конвенция для такого рода вещей, которая касается этой проблемы и является моей структурой (Mobile → Actor1 → Mobile → Actor2 → и т.д.), каким образом Akka хочет, чтобы это было или у меня есть просто вид водопада сообщений (Mobile → Actor1 → Actor2 → и т.д.)?

Сейчас я отправляю ConnectMessage в мой Mobile актер, который затем отправляет его в Actor1, Actor1 обрабатывает его и отправляет новое сообщение обратно в Mobile, Mobile отправляет этот ответ затем до Actor2, и цикл продолжается с созданием нового сообщения на основе старого сообщения. Например. new Message2(message1.foo, message1.bar, message1.baz, newComputatedResult, newComputatedResult2, etc);

Является ли эта хорошая практика или я должен включать старый экземпляр (который может содержать информацию, которая больше не полезна) и включает в себя новый материал? Например. new Message2(message1, newComputatedResult, newComputatedResult2, etc);

Или я должен делать что-то совершенно другое?

Я думал об использовании TypedActors, но для этого требуется использование рисунка водопада, и я не знаю, как я передам ActorRef слушателя, который хочет получить окончательный результат.

Надеюсь, я сделал себя достаточно понятным, потому что английский не мой первый язык и что вопрос ясен для всех.

Я начинаю разработчик Akka и люблю эту идею, но так как документация не очень хорошо охватывает, я подумал, что это будет лучшее место, чтобы спросить. Спасибо за прочтение!

Ответы

Ответ 1

Я отвечу на несколько комментариев в ответ на это, потому что я затронул те же проблемы в моей кривой обучения Akka. Я думаю, вы просите какие-то эмпирические правила, поэтому мои здесь содержатся.

Во-первых, создание актеров невероятно дешево; они очень легкие. Итак, почему бы не создать их для каждого HttpClient и Account и дать им подходящие имена, полученные из их личности? Это также позволяет избежать того, что вы должны передавать их так много, возможно, рекламируя свой код.

Во-вторых, держите свои имена сообщений короткими, целенаправленными и начинающимися с глагола. Каждое сообщение должно сказать актеру что-то сделать, чтобы вы хотели, чтобы имя отражало это, используя глагол.

В-третьих, множество сообщений идет с актером. Обычно я объявляю их в классе-компаньоне класса актеров, чтобы использовать их как ActorClass.MessageName, если он не находится внутри ActorClass, а затем он просто MessageName.

В-четвертых, добавьте счетчик имени актера. Я часто просто объединяю счетчик (используйте AtomicInteger) с именем типа (Car-1, Car-2 и т.д.).

Если иерархия важна для вас, я бы рекомендовал только добавить родительского актера к имени. Что-то вроде Phone-1-in-Car-7, означающее Phone-1, содержится внутри Car-7. Затем вы можете собрать иерархию как программно, так и вручную, следуя родительским ссылкам.

Я думаю, что "Сообщение" в ConnectMessage является избыточным. Просто сделайте имя сообщения "Connect" или даже лучше "ConnectToThing" (независимо от того, что есть, если это актуально).

Я бы не собирал ваши имена сообщений слишком сильно, как вы предлагаете с помощью Message2. Используйте минимальный объем информации, чтобы быть полезной для тех, кто будет читать эти имена. Я думаю, что отсутствие ответа на это могло возникнуть в результате этой части вашего вопроса. Я нашел это сбивающим с толку, так как не хватает подробностей.

Надеюсь, это поможет.