演员信息是否应该具有共同特征？

问题描述

| 在适当使用scala（和akka）actor框架的大多数示例中，人们倾向于从单个特征中获取每条消息。例如：

trait Message
object Ping extends Message
object Pong extends Message

但是，在Scala和Akka中，根本不会键入消息接收。有什么理由要实现一个共同的特征？     

解决方法

        这实际上取决于您要实现的目标。例如，我最近使用一个具有多种类型的actor的actor和一个或多或少类似于路由器的管理actor来构建了一个小型应用程序。现在，工作人员可以收到许多不同的消息，例如

Foo

，

Bar

和

Baz

。没有Supertype，在执行演员中，我必须编写如下内容：

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

这显然是不必要的冗长。因此，在这种情况下，超级类型ѭ5type将很有意义，因为它可以简化您的代码：

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

另一方面，这使得消息

Foo

，

Bar

和

Baz

几乎不能用于您的WorkerActor所用的任何其他目的。例如，如果有一条消息

Stop

或ѭ11probably，则可能很糟糕，因为您需要在整个位置重新定义它。 因此，如果您知道只会有不传递消息的演员（也就是说，他们自己处理消息），那么我想如果没有他们的超类型，您会很好。 我猜人们默认情况下或多或少会这样做的原因是，如果您以后更改代码，则以后不必再创建特征，因为您在一开始就已经这样做了。 就个人而言，我总是尽量避免不必要的开销，因此除非我真的需要，否则我可能不会定义超类型。另外，我真的不知道创建超类型是否对性能有任何影响，但是我很想知道。     ,         既可以使用

scala.actors

（通过

InputChannel[T]

或

Reactor[T]

）也可以使用Akka（you15ѭ）来设置传入消息的类型边界。 在大多数示例中，消息会扩展“ 16”。这样做有两个原因： 如果您的actor的消息处理程序（部分函数）没有涵盖扩展该特性的所有消息，则编译器会生成警告；

sealed trait

只能在定义了特征的源文件中扩展，因此客户端无法定义它自己的扩展特征的消息；     ,        这不是强制性的，但它是OO设计的东西。为应用程序域消息提供抽象类型是一个更好的设计。因此，在我们的应用程序代码中处理Messages时，您可以拥有多态优势。   

trait Message

object Ping extends Message
objet Pong extends Message

object Stop
  

例如，如果您在应用程序中的某处必须处理一堆消息，而不管它们的特定类型（Ping或Pong），则将它们全部视为Message类型的对象。 这说得通？不是吗