Где должны быть объявлены сообщения с актерами?

Ответ 1

Команда Akka рекомендует Сообщение должно быть определено в том же месте props метод должен быть: в объекте Companion приемника, поскольку приемник реализует receive частичную функцию и должен знать обо всех сообщениях, которые он поддерживает. Кроме того, несколько отправителей могут отправлять набор сообщений (реализованный получателем), поэтому вы не можете поместить его в одного отправителя.

Ответ 2

Если официальный активатор Activator Activator-akka- scala -seed имеет какое-либо значение в отношении хороших практик Akka, сообщения должны быть часть сопутствующего объекта, как показано в следующем PingActor акторе (скопированном непосредственно из шаблона):

package com.example

import akka.actor.{Actor, ActorLogging, Props}

class PingActor extends Actor with ActorLogging {
  import PingActor._

  var counter = 0
  val pongActor = context.actorOf(PongActor.props, "pongActor")

  def receive = {
    case Initialize => 
      log.info("In PingActor - starting ping-pong")
      pongActor ! PingMessage("ping")   
    case PongActor.PongMessage(text) =>
      log.info("In PingActor - received message: {}", text)
      counter += 1
      if (counter == 3) context.system.shutdown()
      else sender() ! PingMessage("ping")
  } 
}

object PingActor {
  val props = Props[PingActor]
  case object Initialize
  case class PingMessage(text: String)
}

Примечание PingActor, который содержит все принятые сообщения актера (как вы могли заметить, это не соблюдается строго, так как PongActor.PongMessage также принимается, но не определяется в сопутствующем объекте PingActor).

Из другого вопроса Как ограничить рекламные сообщения конкретными типами? Виктор сказал:

Общая практика заключается в том, чтобы объявить, какие сообщения может получить Актер в сопутствующем объекте Актера, что делает его намного проще знать, что он может получить.

Ответ 3

Я не понимаю, почему объект-компаньон является рекомендуемым местом для определения сообщений. Сообщения являются частью протокола связи и, следовательно, являются частью API. С точки зрения архитектуры, знание API является достаточным для взаимодействия и взаимодействия с компонентом, а внешний компонент зависит только (зависимость артефакта) от этого API. Если сообщения определены в сопутствующем объекте, вы тесно связываете реализацию и API. Как вызывающая сторона, я не хочу извлекать всю реализацию, когда я определяю свои зависимости, ни как вызываемого, я хочу представить свою реализацию.

Так что для меня, как уже упоминалось выше, лучше определить их в нейтральном месте, то есть в артефакте API.