Question

成为Akka的新手我需要帮助以简单的方式理解道具的好处。创建常见的OO样式对象有什么问题？

我所知道的是，这遵循工厂模式，您将PROP中的类和属性发送到工厂并为您创建actor。 [纠正我，如果我错了]？

但我没有看到需要，我知道这是根本的。这是我的困境。

你能帮助我理解这可能是通过类比/代码吗？

Answer 1

我认为这种创造演员的方式有两个好处。

第一个很简单：它可以保证在创建Actor对象时，它也在actor系统中正确注册（它必须有一个父actor来监督它，得到被推送的消息调度员等）。所以你永远不会得到一个Actor类型的对象，但实际上存在于actor系统之外。

第二个在actorOf(props: Props): ActorRef方法的定义中可见：它实际上并不返回Actor，而是ActorRef（和ActorRef没有不要公开对底层Actor的引用。

这意味着您永远无法直接访问actor本身，并且无法通过直接调用actor上的方法来绕过Akka API，而不是发送异步消息。如果你自己构建Actor，你显然可以直接访问actor，这样就很容易以违反actor模型的方式访问它。

Answer 2

在Akka中使用Props的主要原因是Actor实例的生命周期完全由ActorSystem管理。

在最简单的情况下，您的Actor会被实例化一次，然后快乐地顺着。如果那是唯一的用例，那么标准的依赖项注入方法可能会起作用。

但是，一旦Akka监督机制启动，最简单的情况就会被抛出窗口。在Akka中，当Actor抛出Exception时，监督机制将决定该参与者应该采取的行动。通常，主管必须决定是否：

该异常是预料之中的，并不会真正引起问题=> actor恢复并继续正常运行。
该异常是致命的，并且无法允许actor继续=> actor被杀死，其邮箱被销毁，并且其包含的所有消息都被发送给无效的信件。
异常不好但可以恢复=> actor重新启动。这意味着现有的Actor实例将被丢弃，但其邮箱将保留。从Actor创建了一个新的Props实例，它将开始处理原始邮箱。

需要Props机制来处理重启情况。

我相信Props机制在创建分布式ActorSystem时也很有用，因为它允许在必要时在另一个JVM上实例化Actor。

所有这些情况都无法通过标准工厂模式或标准依赖项注入机制来处理。

Answer 3

我认为也没有任何优势。实际上，我有理由了解API。

为什么不喜欢这样：

ActorRef actorA = system.getRefByCreateActor(ActorA.class, Props.create(......));

NoSender.tell(actorA, message);