Akka は、有限ステート マシンとunbecome/become という、アクターの状態を管理するための 2 つの重複する方法を提供します。それぞれの利点/欠点は何ですか? それらのいずれかを他のものよりも選択する必要があるのはいつですか?
2 に答える
FSM
は、コア アクター API を使用した場合よりも洗練された読み取り可能なステート マシンを構築できるようにする DSL です。FSM コードをビジネス担当者に見せれば、ビジネス ルールを検証できる可能性があります。
DSL を使用すると、FSM
物事をよりきれいにまとめることができます。たとえば、トランジションを使用すると、アクターの動作全体で複製する必要があるロジックを除外できますbecome
。また、デカップリングとテストに役立つ遷移の通知を受けるために他のアクターをサブスクライブすることもできます。
また、タイマーは DSL にうまく統合されており、キャンセルなどはきれいに処理されます。スケジューラを使用したタイムアウト メッセージのコーディングには、いくつかの問題があります。
欠点FSM
は、それが DSL であり、他のチーム メンバーが理解するための新しい構文であることです。利点は、それが DSL であり、より高度な抽象化であるということです。agilesteel の 2 つの状態のしきい値は良いものだと思います。しかし、2 つの状態を超えると、 のメリットFSM
は非常に魅力的になります。
FSM のドキュメントと、 と を対比させた付属の例を必ず読んでください。become
FSM
1 つの注意事項: を使用してビヘイビアを「ポップ」するunbecome
- デフォルトのビヘイビアは、ビヘイビア スタッキングを使用しないことです。これは、少数のユース ケース (つまり、通常はステート マシンではない) にのみ関連します。
Become/Unbecome は、FSM とは対照的に非常に軽量です。したがって、2 つ以上の状態 (たとえば、オン/オフ) および/または複雑な状態変更ポリシーがない限り、Become/Unbecome を本格的な FSM に変換することはありません。それ以外は、わずかな違いしかないと思います...たとえば、FSM は組み込みのタイマー DSL を提供します。
setTimer("TimerName", msg, 5 seconds, repeat = true)
// ...
cancelTimer("TimerName")
または、たとえば、FSM で前の状態に「戻る」ことが可能かどうかはわかりません。移動する状態を明示的に指定する必要があるため、「進む」しかありません。一方unbecome
、まさにそれを提供します。