我最近重构了我的演员并最终获得了很多辅助方法,这些方法是演员的一部分。这是正确的做法吗?所有辅助方法都应该是他们自己的演员吗?我如何进行分离?
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){
...
....
}
}
辅助方法应该在哪里?这些也应该是演员吗?
答案 0 :(得分:1)
所有辅助方法都应该是他们自己的演员吗?如何进行分离?
在解决这些问题时,考虑演员是什么是有帮助的。 Derek Wyatt在他的书“ Akka Concurrency ”中,对一个演员和一个人进行了类比(以下是他书中免费提供的fourth chapter的摘录):
您的日常世界充满了并发性。你强加给自己 以及你周围的人,他们把它强加给你。现实中 关键部分和锁的等价物以及同步方法 和数据都是由你自己和你世界的人自然处理的。 人们通过一次只做一件事来管理这个。我们喜欢 假装我们可以多任务,但事实并非如此。有意义的 我们所做的就是要求我们做到这一点。我们可以暂停这项任务 并在以后恢复它,然后将其切换为其他工作 回到它,但实际上一次只做一件事就是不在我们的驾驶室里。
那么,如果我们想要一次做多件事呢?答案是 很明显:我们只使用不止一个人。这里并不多 我们从中受益的世界并非由一群才华横溢的人创造 人
这就是为什么演员让我们的应用程序开发更直观 我们的应用程序设计更容易推理:它们是以我们的模型为蓝本的 日常生活。
后来在同一章中,他写道:
演员一次只做一件事;这是并发的模型。如果你 想要同时发生多个事情,那么你需要 创建多个演员来完成这项工作。这很有道理, 对?我们一直在说演员编程吸引了很多 您的日常生活经历。如果你想更快地完成工作,那就放更多 工作的人。
在设计演员系统时,将系统的主要部分分配给具有不同职责的演员是一个很好的原则。例如,在ETL管道中,可能有:
假设解析器actor使用辅助方法。是否应将此方法封装在自己的actor中取决于方法的作用。将任务分解为子任务是个好主意,但在某些时候你必须确定任务太“小” - 太小而不能成为自己的角色。
回到人物类比,让我们将管道中的每个阶段视为一个人。让我们假设解析器人需要一个削尖的铅笔来完成他的工作,并且解析器当前自己获得了铅笔。雇用一名低级实习生(从怀亚特的书中借用另一个插图)是否有意义,其唯一的工作是锐化铅笔并在要求时将其交给解析者?如果有大量数据流入,是否可以聘请更多的解析员而不雇用任何实习生?对于10个解析器来说,拥有30个铅笔削尖实习生可能效率不高。换句话说,我们可能不需要独立地扩展与解析器数量相关的实习生数量。如果我们确实需要这样做,那就意味着实习生的工作足以证明雇用实习生的合理性。
总结这种主观的思考:
辅助方法应该在哪里?
一些想法:
答案 1 :(得分:0)
辅助方法是一种帮助其他方法执行它的方法 任务。这些通常在方法必须执行时使用 复杂的任务,由几个较小的任务组成。该 较小的任务通常由辅助方法执行。
辅助方法通常仅用于将较大的任务分成更小的更有组织的方法。辅助方法应位于使用它们的类的层次结构中。