我想创建一个由三个代理组成的简单“多代理”系统。对于每个代理，都会创建一个封装邮箱处理器的类型。所有代理（位置，id等）和函数（sendMessage，move）以及代理通过邮箱处理器的实现（如何处理邮件）都有不同的属性。另外，它们可能因特定代理商的其他功能而有所不同。每个代理还应包含（作为其属性之一）其他代理的列表，它将向其发送消息。这是一个非常简单的模型，我计划在F＃中使用邮箱处理器。F＃ - 纯粹的功能设计而不是oop设计
在OOP中，这意味着要创建一个代理接口（或抽象类），并且所有特定的代理将从它们自己的实现继承此接口。
我知道OOP是可能的F＃，但我宁愿坚持纯功能设计。但是，在我看来，在这种情况下，OOP是最合适的方法。如果你能给我任何关于功能（F＃）设计的想法，我会很高兴。谢谢。
为什么要坚持纯功能设计？ F＃允许使用功能和 OOP原则的干净组合，并且我会利用两种机制并利用该语言的力量。
如果你想结合功能和面向对象方面，我会开始使你的对象不可变的。因此，你正在使用对象，但在一个功能范例。
你已经想出了一个OOD，OOP解决方案似乎是最自然的令人惊讶吗？
如果你用流程和数据转换来重写设计描述，它会自然而然地作为一个FP设计出现，而且在OO中有很多呃类的声音真的很尴尬。因为它几乎没有描述数据类型或需要进行什么转换。乍一看，我会说代理是一个邮箱，一个消息处理程序（或消息处理程序列表）和一个其他代理的邮箱列表的三个参数的函数。如果将来的调度是基于消息的，那么消息处理程序是两个参数的函数。邮件和邮箱列表。
首先，F＃中的面向对象风格的功能样式和10并没有真正的冲突。
实用的风格包括使用不变类型，纯函数没有副作用和F＃的数据类型，如识别联合，功能等
面向对象的风格更侧重于你如何组织代码（使用类和接口），但是代码仍然可以是纯粹的功能而不使用任何可变状态。
在基于代理的系统中，在实现代理时使用功能样式，但使用类组织代理非常有意义。我认为这可能是F＃中的最佳做法（另请参阅this article on encapsulating F# agents on MSDN）。
在您的示例中，您说的是代理会保存其发送消息的其他代理的列表。有考虑（如果你想避免接口），值得几个备选方案：
暴露一个F＃事件（Event<'T>）。这样，代理只需公开一个通知，而不必明确管理其他代理的列表（并且此设计还允许其他类型的订户）。
保留功能列表。如果你只需要发送消息给其他代理，那么你基本上只需要一个接口和一个单一的方法。在这种情况下，您可以保留一个功能列表，如
Message -> unit。
我一般喜欢暴露的事件 - 这样一来，系统不太紧密结合，你可以更容易地组成各种方式代理人（他们没有实现特定的接口组成）。本文讨论agent-based architectures from a higher-level perspective，也可能有用。
谢谢Tomas。我喜欢揭露事件的想法。 – user2039784
我知道F＃结合了这两种范例。然而，我的动机是要找出各种范例可以做的各种事情，并且给出的方案很简单，可以从一开始（但是一般而言，也可以用于其他方案）。在这种情况下，我只想使用歧视联盟和记录以及模式匹配。 – user2039784