我见过的所有 Actor 系统实现（主要使用 Akka）都假定一个 Web 应用程序，这意味着一个 HTTP 接口可以很自然地由异步 Actor 系统提供服务。
但是，如果我正在编写一个桌面应用程序，或者一个库以用作独立于平台的应用程序的组件，该怎么办？
我希望客户端子例程能够调用val childObj = parentObject.createChild( initParam )，而不必知道我允许的消息类型或一般的参与者系统。例如 Not parentObject ! CreateChild( initParam )，然后处理在另一条消息中收到的响应。
我知道我可以将异步响应隐藏在 Futures 后面，但是还有其他已知的同步系统将计算移交给隐藏的参与者系统的模式吗？
（我意识到这将导致对库的阻塞调用。）
许多适用于库的东西也适用于这里，所以请看下面的部分。如果不出意外，您可以将使用 Akka 的代码部分包装为单独的库。需要注意的是，如果您使用的是 Swing，您可能希望SwingUtilities.invokeLater在与 GUI 交互之前使用它来返回事件调度线程。（另外，不要阻塞该线程。您可能希望使用期货来避免这种情况，因此请考虑设计您的库以返回期货。）
您的示例似乎假设您的演员周围有一个薄包装，或者至少是一个自下而上的设计，您的界面由您的实现细节驱动。相反，以更自上而下的方式设计库，首先弄清楚库的接口，然后（可能）使用 Akka 作为实现细节。（这对于一般的库设计来说是一个好主意。）如果您已经使用 Akka 编写过一些东西，请不要担心，只需将接口与实现分开设计，然后将两者拼接在一起即可。如果这样做，则不需要特定的模式，因为无论您使用 Akka，界面设计的正常模式都适用。
例如，考虑一个编译器。编译方法签名可能很简单：
def compile(sources: List[File]): List[File] // Returns a list of binaries
这里没有提到演员。但这可能会：
compileActor ? Compile(sources)
...并阻止结果。主要的编译器参与者可能依赖于其他参与者，但没有理由通过公共 API 公开这些参与者。