我想创建一个由三个代理组成的简单“多代理”系统。对于每个代理，都会创建一个封装邮箱处理器的类型。所有代理都有共同的属性(位置、ID 等)和功能(sendMessage、移动)，代理因邮箱处理器的实现(如何处理消息)而彼此不同。此外，它们可能因特定代理特有的其他功能而异。每个代理还应该包含(作为其属性之一)它将向其发送消息的其他代理的列表。这是一个非常简单的模型，我计划基于该模型使用 F# 中的邮箱处理器。
在 OOP 中，这意味着创建一个代理接口(interface)(或抽象类)，并且所有特定的代理都将从该接口(interface)继承并具有它们自己的实现。
我知道 OOP 在 F# 中是可能的，但我宁愿坚持纯函数式设计。但是，在我看来，OOP 是这种情况下最合适的方法。如果您能给我关于功能 (F#) 设计的任何想法，我将很高兴？谢谢你。
最佳答案
首先，F# 中的函数式风格 和面向对象风格 并不真正冲突。
函数式风格包括使用不可变类型、无副作用的纯函数和 F# 数据类型，例如可区分的联合、函数等。
面向对象的风格更侧重于组织代码的方式(使用类和接口(interface))，但代码仍然可以在不使用任何可变状态的情况下发挥纯功能性。
在基于代理的系统中，在代理的实现中使用函数式风格很有意义，但使用类来组织代理。我认为这可能是 F# 中的最佳实践(另请参见 this article on encapsulating F# agents on MSDN)。
在您的示例中，您是说代理保留了它向其发送消息的其他代理的列表。有一些值得考虑的替代方案(如果您想避免接口(interface)):
公开 F# 事件 (
Event<'T>)。这样，代理只需公开一个通知，而不必显式管理其他代理的列表(并且这种设计还允许其他类型的订阅者)。保留函数列表。如果您只需要向其他代理发送消息，那么您基本上只需要一个具有单一方法的接口(interface)。在这种情况下，您可以保留一个函数列表，例如
Message -> unit.
我通常更喜欢公开事件 - 这样，系统耦合度较低，您可以更轻松地以各种方式组合代理(它们不必实现要组合的特定接口(interface))。本文讨论 agent-based architectures from a higher-level perspective ，也可能有用。
关于F# - 纯功能设计而不是 oop 设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14688232/