演员的信息是否应该延伸出一个共同的特征？
在正确使用 scala（和 akka）actor 框架的大多数示例中，人们倾向于从单个特征派生每条消息。例如：
trait Message
object Ping extends Message
object Pong extends Message
然而，在Scala和Akka中，消息接收根本不是类型化的。有什么理由去实现一个共同的特征吗？
In most examples of proper usage of the scala (and akka) actor frameworks, people tend to derive every message from a single trait. For example:
trait Message
object Ping extends Message
object Pong extends Message
However, in both Scala and Akka, message reception is not typed at all. Is there any reason to implement a common trait ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这实际上取决于您想要实现的目标。例如，我最近使用参与者构建了一个小型应用程序，该应用程序具有多种类型的参与者，以及一个或多或少像路由器一样的管理参与者。现在，工作参与者可以接收许多不同的消息，例如
Foo、Bar和Baz。如果没有超级类型，在管理演员中我必须写这样的东西：这显然是不必要的冗长。因此，在这种情况下，超类型
WorkerMessage会很有意义，因为它简化了代码：另一方面，这使得消息
Foo、Bar和Baz除了供您的 WorkerActors 使用之外，几乎无法用于任何其他目的。例如，如果您有一条消息Stop或Init，这可能会很糟糕，因为您需要在各处重新定义它。因此，如果您知道您只会拥有不传递消息的演员（也就是说，他们自己处理消息），那么我想您不需要他们的超类型就可以了。
我想人们默认情况下或多或少这样做的原因是，如果您稍后更改代码，则不必随后创建该特征，因为您在一开始就已经这样做了。
就我个人而言，我总是尽力避免不必要的开销，因此除非我真的需要它，否则我可能不会定义超类型。另外，我真的不知道创建超类型是否对性能有任何影响，但我很想知道。
This really depends on what you are trying to achieve. For example, I recently built a small application using actors which had several types of actors, and a managing actor which acted more or less like a router. Now, the working actors could receive lots of different messages, for example
Foo,BarandBaz. Without a Supertype, in the managing actor I'd have to write something like this:Which is obviously unnecessarily verbose. So in this case, a supertype
WorkerMessagewould make a lot of sense, because it simplifies your code:On the other hand, this makes the messages
Foo,BarandBazpretty much unusable for any other purpose than being used by your WorkerActors. If you had a messageStoporInitfor example, this would probably be bad because you'd need to redefine it all over the place.So if you know you'll only have actors which do not pass messages around (that is, they process them by themselves), then I guess you'll be just fine without a supertype for them.
I guess the reason that people do this more or less by default is that if you later change your code you don't have to create the trait afterwards, because you already did in the beginning.
Personally, I always try to avoid unnecessary overhead, so I'd probably not define a supertype unless I really need it. Also, I really don't know if creating a supertype has any effect on performance at all, but I'd be interesting to know.
两者都使用
scala.actors（通过InputChannel[T]或Reactor[T]）和Akka（TypedActor） code>）您可以为传入消息设置类型界限；在大多数示例中，消息扩展了
密封特征。这样做有两个原因：如果你的actor的消息处理程序（部分函数）没有涵盖扩展特征的所有消息，编译器生成警告；
密封特征只能在定义该特征的源文件中进行扩展，因此客户端无法定义自己的消息来扩展该特征；< /里>
Both with
scala.actors(viaInputChannel[T]orReactor[T]) and Akka (TypedActor) you can set type bounds for the incoming messages;In the most examples, messages extend a
sealed trait. That's done for 2 reasons:if the message handler (partial function) of your actor doesn't cover all the messages that extend the trait, compiler generates a warning;
sealed traitcan be extended only in the source file, where the trait is defined, and, thus, client cannot define it's own messages that extend the trait;这不是强制性的，但它是面向对象设计的东西。为您的应用程序域消息提供一个抽象类型是一个更好的设计。因此，在我们的应用程序代码中处理消息时，您可以享受多态性的好处。
例如，如果您的应用程序中的某个地方您必须处理一堆消息，无论它们的特定类型（Ping 或 Pong）如何，您都会将它们全部视为 Message 类型的对象。
有道理吗？不 ？
This is not mandatory but it is an OO design stuff. It is a better design to have an abstract type for you application domain messages. So you can have polymorphism benefits when dealing with Messages in our application code.
For example if somewhere in your application you have to deal with bunch of messages regardless of their specific types (Ping or Pong) you will treat them all as objects of type Message.
It makes sense? No ?