java - 最佳实践 - akka actor 中的辅助方法

Question

我最近重构了我的 actor，最终得到了很多作为 actor 一部分的辅助方法。这是正确的做法吗？所有辅助方法都应该是自己的参与者吗？如何进行分离？

  public class MyActor extends UntypedActor {



        public MyActor () {

        }

        @Override
        public void onReceive(Object msg) throws Exception {


        if ( msg instanceof doSomethingComplex) {
                doSomethingComplex message = (doSomethingComplex) msg;
               doSimple(message.prop);
}

private void  doSimple(String prop){
doSimpler(prop);
....
}

private void  doSimpler(String prop){
...
....
}

}

辅助方法应该在哪里？这些也应该是 Actor 吗？

Answer 1

Should all helper methods be an actor of their own? How do I make the separation?

在解决这些问题时，思考一下什么是 Actor 会很有帮助。 Derek Wyatt 在他的书 Akka Concurrency 中，在 Actor 和人之间进行了类比(以下摘录自他的书的免费 fourth chapter):

Your day-to-day world is full of concurrency. You impose it on yourself as well as the people around you, and they impose it on you. The real-world equivalents of critical sections and locks as well as synchronized methods and data are all naturally handled by yourself and the people in your world. People manage this by literally doing only one thing at a time. We like to pretend that we can multi-task, but it’s simply not true. Anything meaningful that we do requires that we do just that one thing. We can pause that task and resume it later, switch it out for something else to work on and then return to it, but actually doing more than one thing at a time just isn’t in our wheelhouse.

So what if we want to do more than one thing at a time? The answer is pretty obvious: we just use more than one person. There’s not much in the world that we’ve benefited from that wasn’t created by a gaggle of talented people.

This is why actors make our application development more intuitive and our application designs easier to reason about: they’re modeled after our day-to-day lives.

后来在同一章中，他写道:

Actors only do one thing at a time; that’s the model of concurrency. If you want to have more than one thing happen simultaneously, then you need to create more than one actor to do that work. This makes pretty good sense, right? We’ve been saying all along that actor programming draws a lot on your day-to-day life experiences. If you want work done faster, put more people on the job.

在设计参与者系统时，将系统的主要部分分配给具有不同职责的参与者是一个很好的原则。例如，在 ETL 管道中，可能有:

1. 订阅新数据队列的参与者。
2. 解析原始数据的参与者。
3. 一个参与者，用于过滤已解析的数据以获取用户感兴趣的信息。
4. 将结果保存到数据库的参与者。
5. 将结果发布到用户可以订阅的队列的参与者。

假设解析器参与者使用辅助方法。该方法是否应该封装在其自己的参与者中取决于该方法的作用。将任务分解为子任务是个好主意，但在某些时候您必须确定任务太“小”——太小而无法成为其自己的参与者。

回到人的类比，让我们将管道中的每个阶段想象为一个人。让我们假设解析器人员需要一支削尖的铅笔来完成他的工作，并且当前解析器自己获得铅笔。雇用一名低级实习生(借用怀亚特书中的另一个插图)是否有意义，他的唯一工作就是削铅笔并在需要时将其交给解析器人员？如果大量数据涌入，是否需要雇用更多解析人员而不雇用任何实习生？让 30 名削铅笔的实习生来代替 10 名解析器可能效率不高。换句话说，我们可能不需要独立地调整与解析器数量相关的实习生数量。如果我们确实需要这样做，那就表明该实习生的工作足够重要，足以证明雇用该实习生是合理的。

总结一下这种主观的思考:

• 将您的系统分解为职责明确且明确的部分。将每个部分分配给一个 Actor 。
• 如有必要，将每个部分分解为子任务。将每个子任务分配给一个参与者。帮助决定是否需要进一步分解的一个关键方法是确定独立扩展子任务是否有效。
• 如果您愿意，可以将太小而无法成为自己的参与者的功能放置在辅助方法中。

<小时/>

Where should the helper methods be?

一些想法:

• 如果辅助方法仅与某个参与者相关，请像您所做的那样在参与者内部声明它。
• 如果辅助方法可以在不同类型的 Actor 中使用，请在 utility class 中声明它。或者，将其声明为 static method Actor 内部。