私は Akka と Scala を約 1 か月使用していますが、明示的なインターフェイスをメッセージに置き換えるのは少し面倒です。次の単純な Akka アクターを考えてみましょう。
case class DoMyHomework()
class Parent extends Actor {
def receive = {
case d: DoMyHomework => // do nothing
}
}
このアクターに次のような DoMyHomework メッセージを送信するアクターまたは非アクター コード:
ActorRef parent = ...
parent.ask(DoMyHomework)
結果がどうなるかわかりません。答えの種類は何ですか?私は答えを得ることはありますか?例外を認めることはできますか? 等々。
修正はケースクラスを文書化することのようです...しかし、他のアクターも同じケースクラスを受け取ったらどうなるでしょうか。次に、そのメッセージを受信するためのドキュメントは、アクター自体にある必要があります。
これを少しきれいにするために、次のことを考えました。
trait SomeoneSmarter {
def wouldYouDoMyHomework: Future[Boolean]
}
class Parent extends Actor with SomeoneSmarter {
case class DoMyHomework()
def wouldYouDoMyHomework = {
(self ? DoMyHomework()).mapTo(Boolean)
}
def receive = {
case d: DoMyHomework =>
// TODO: If I'm busy schedule a false "No way" reply for a few seconds from now.
// Just to keep their hopes up for a while. Otherwise, say sure right away.
}
}
それで、私はこれについて同僚とおしゃべりをしましたが、反応の 1 つは「俳優モデルに忠実ではない」というものでした。
まず、アクターを長年使用している方からのアドバイスをいただければ幸いです。すべてのメッセージが扱いにくくなりますか? インターフェイスの背後にメッセージの受け渡しを隠すことになりますか?
私が提案しているアクターには、アクター間でメッセージを送信したり、イベント ストリームをサブスクライブしたり、Akka に期待されるすべての機能がまだあります。また、インターフェースは、何と話しているかを知るための定評のある方法を提供します。また、IDE などでコーディングするときにも役立ちます。また、なぜアクターのユーザーはそれがアクターであることを知る必要があるのでしょうか?
私が得たもう 1 つの反応は、「TypedActor が必要なようです」というものでした。しかし、 TypedActor について読んだ後、私は確信が持てません。確かに TypedActor は、これらの内部メッセージを作成する手間を省きます。しかし、少なくとも http://doc.akka.io/docs/akka/snapshot/scala/typed-actors.htmlのコード サンプルからは、TypedActor はブロックの周りのプロキシとしてのみ機能するように意図されているという印象を受けます。カプセル化するか、スレッドセーフにするか、単に現在のスレッドから直接呼び出したくないコードの。コーディングするのは、実装とインターフェースだけです。アクター自体 (プロキシ) を台無しにしないでください。たとえば、実装で定期的な作業を実行したり、イベント ストリームにサブスクライブしたり、インターフェイスに関係のないことをしたりしたい場合などです。
私はhttp://letitcrash.com/post/19074284309/when-to-use-typedactorsも読んだことがありますが、その例がよりわかりやすいとは思いませんでした。私はおそらく TypedActor を理解していないだけです (まだ Actor を本当に理解しているとは言えません)。
助けてくれてありがとう。
ピノ