Должны ли актерские сообщения расширять общую черту? - PullRequest
11 голосов
/ 12 июня 2011

В большинстве примеров правильного использования каркасов акторов scala (и akka) люди склонны выводить каждое сообщение из одной черты.Например:

trait Message
object Ping extends Message
object Pong extends Message

Однако и в Scala, и в Akka прием сообщений вообще не печатается.Есть ли основания для реализации общей черты?

Ответы [ 3 ]

5 голосов
/ 12 июня 2011

Это действительно зависит от того, чего вы пытаетесь достичь. Например, недавно я создал небольшое приложение, использующее актеров, которые имели несколько типов актеров, и управляющего актера, который действовал более или менее как маршрутизатор. Теперь работающие актеры могли получать множество разных сообщений, например Foo, Bar и Baz. Без супертипа, в актере я должен был бы написать что-то вроде этого:

react {
    case x:Foo | x:Bar | x:Baz => worker ! x
}

Что, очевидно, излишне многословно. Так что в этом случае супертип WorkerMessage будет иметь большой смысл, потому что он упрощает ваш код:

react {
    case x:WorkerMessage => worker ! x
}

С другой стороны, это делает сообщения Foo, Bar и Baz в значительной степени непригодными для любых других целей, кроме того, что они используются вашими WorkerActors. Например, если вы получили сообщение Stop или Init, это, вероятно, было бы плохо, поскольку вам нужно было бы переопределить его повсеместно.

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

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

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

5 голосов
/ 12 июня 2011
  1. Оба с scala.actors (через InputChannel[T] или Reactor[T]) и Akka (TypedActor) вы можете установить границы типа для входящих сообщений;

  2. В большинстве примеров сообщения расширяются до sealed trait.Это делается по двум причинам:

    • , если обработчик сообщений (частичная функция) вашего субъекта не охватывает все сообщения, расширяющие черту, компилятор генерирует предупреждение ;

    • sealed trait может быть расширен только в исходном файле, где определена черта, и, таким образом, клиент не может определить свои собственные сообщения, которые расширяют черту;

0 голосов
/ 12 июня 2011

Это не обязательно, но это ОО дизайн. Лучше иметь абстрактный тип сообщений вашего домена приложения. Таким образом, вы можете получить преимущества полиморфизма при работе с сообщениями в коде нашего приложения.

  
trait Message

object Ping extends Message
objet Pong extends Message

object Stop
  

Например, если где-то в вашем приложении вам приходится иметь дело с кучей сообщений независимо от их конкретных типов (Ping или Pong), вы будете рассматривать их как объекты типа Message. Это имеет смысл? Нет?

...