scala - Untyped vs TypedActors - 为什么要使用 untyped？

Question

我试图理解为什么人们会在 typed actors 上使用无类型的 actor .我已经阅读了几篇关于此的文章，其中一些如下: What is the difference between Typed and UnTyped Actors in Akka? When to use what? http://letitcrash.com/post/19074284309/when-to-use-typedactors

我有兴趣了解为什么无类型的 actor 在以下情况下更好:

• 网络服务器，
• 分布式架构
• 可扩展性，
• 与用其他程序编写的应用程序的互操作性
  语言。

我知道，由于成为/取消成为功能，无类型的 actor 在 FSM 的上下文中更好。

我可以在负载均衡器中看到非类型化的可能性，因为它不必知道消息的内容，而只是将它们转发给其他参与者。然而，这也可以在类型编辑器中实现。

有人可以在上述领域中提出一些用例吗？在这些领域中，无类型的 actors “更好”？

Answer 1

类型角色有一个普遍的缺点:它们很难扩展。当您使用普通特征时，您可以轻松地将它们组合起来构建实现这两个接口(interface)的对象

trait One {
  def callOne(arg : String)
}
trait Two {
  def callTwo(arg : Double)
}
trait Both extends One with Two

Both 特性支持从两个特性组合的两个调用。

如果您使用 actor 方法来处理消息而不是直接调用，您仍然能够以拒绝类型安全为代价扩展接口(interface)。

trait One {
  val receiveOne : PartialFunction[String,Unit] = {
    case msg : String => ()
  } 
}
trait Two {
  val receiveTwo : PartialFunction[Double, Unit] = {
    case msg : Double => ()
  }
}
trait Both extends One with Two {
  val receive : PartialFunction[Any, Unit] = receiveOne orElse receiveTwo
}

Both 特征中的receive 值结合了两个偏函数。第一个只接受 String，第二个 - 只接受 Double。它们有一个共同的父类(super class)型:Any。所以扩展版本应该使用 Any 作为参数并且变得有效无类型。该缺陷存在于支持使用 with 关键字的类型乘法但不支持联合类型的 Scala 类型系统中。您无法定义 Double 或 String。

类型化 actor 失去了轻松扩展的能力。 Actor 将类型检查转移到逆变位置并扩展它需要联合类型。您可以在 ceylon 中查看它们的工作原理编程语言。

并不是无类型和有类型的actors有不同的应用范围。所有有疑问的功能都可以用两者来表达。选择更多的是关于方法论和便利性。

键入可以让您在进行单元测试之前避免一些错误。辅助协议(protocol)声明将花费样板文件。在上面的示例中，您应该显式声明联合类型:

trait Protocol
final case class First(message : String) extends Protocol
final case class Second(message : Double) extends Protocol

而且您失去了简单的回调组合:没有适合您的 orElse 方法。仅手写

val receive : PartialFunction[Protocol, Unit] = {
   case First(msg) => receiveOne(msg)
   case Second(msg) => receiveTwo(msg)
}

如果您想添加一些具有特征 Three 的新功能，那么您将忙于重写该样板代码。

Akka 为 actor 提供了一些有用的预定义增强功能。他们通过混合(例如 receive pipeline )或委托(delegate)(例如 reliable proxy )添加新功能。代理模式在 akka 应用程序中使用得非常多，它们会动态更改协议(protocol)，向其添加控制命令。使用类型化的 actor 无法轻松做到这一点。因此，您将被迫编写自己的实现，而不是预定义的实用程序。被遗弃的实用程序将不受 FSM 的限制。

输入改进是否值得增加工作量由您决定。如果没有对您的项目有深入的了解，没有人可以给出准确的建议。