从Joe Armstrong的论文中,他指出应该按照以下三个步骤设计一个基于Actor的程序.问题是,我不明白这些步骤如何映射到现实世界的问题或如何应用它们.这是乔的原始建议.
- 我们在现实世界活动中识别所有真正并发的活动.
- 我们识别并发活动之间的所有消息通道.
- 我们写下可以在不同消息通道上流动的所有消息.现在我们编写程序.程序的结构应该完全遵循问题的结构.每个真实世界的并发活动应该映射到我们的编程语言中的一个并发进程.如果问题的1:1映射到程序上,我们说该程序与问题同构.
映射恰好是1:1非常重要.这样做的原因是它最小化了问题和解决方案之间的概念差距.如果此映射不是1:1,程序将很快退化,并变得难以理解.当使用非CO语言来解决并发问题时,通常会观察到这种退化.通常,使程序工作的唯一方法是强制几个独立的活动由同一语言线程或进程控制.这导致不可避免的失去清晰度,并使程序受到复杂且不可重现的干扰错误.
我认为#1很容易弄明白.这是我迷路的#2(和3).为了说明我的挫败感,我在这个要点(带有回调的Ruby服务)中找到了一个小服务.
看看那个示例服务,我可以看到如何回答#1.我们有5个并发服务.
其中一些服务不起作用(或不起作用),具体取决于服务所处的状态.如果服务尚未启动,则登录/注销/订阅没有意义.这种状态信息与Joe的3个步骤有关吗？
无论如何,考虑到该要点中的示例/模拟服务,我想知道如何设计程序以Actory方式包装此服务.我想看一下如何应用Joe的3个步骤的指南列表.写一些代码(任何语言)的奖励积分.