F# - pure functional design instead of oop design

Question

I want to create a simple "multi-agent" system consisting of three agents. For each agent, there is a type created encapsulating the mailbox processor. There are attributes common to all the agents (position, id etc.) and functions (sendMessage, move) and agents differs from each other with the implementation of mailbox processors (how the messages are processed). In addition, they may differ by other functions specific to particular agents. Every agent should also contain (as one of its attribute) a list of other agents, to whom it will be sending the messages. This is a just very simple model based on which I plan to play with the mailbox processors in F#.

In OOP, this would mean creating an agent interface (or abstract class), and all the particular agents would be inherited from this interface with their own implementation.

I know OOP is possible in F#, however I would rather stick to pure functional design. However, it seems to me that OOP is the most suitable approach in this case. I would be glad if you could give me any idea with respect to functional (F#) design? Thank you.

Answer 1

First of all, the functional style and object-oriented style in F# are not really in conflict.

• Functional style consists of using immutable types, pure functions without side-effects and F# data types such as discriminated unions, functions etc.

• Object-oriented style is more focused on how you organize code (using classes and interfaces), but the code can still be purely functional without using any mutable state.

In agent-based systems, it makes a good sense to use functional style in the implementation of the agent, but to organize the agents using classes. I think this is probably the best practice in F# (see also this article on encapsulating F# agents on MSDN).

In your example, you're saying that an agent keeps a list of other agents that it sends messages to. There are a few alternatives worth considering (if you want to avoid interfaces):

• Expose an F# event (Event<'T>). This way, the agent simply exposes a notification and does not have to explicitly manage a list of other agents (and this design also allows other types of subscribers).

• Keep a list of functions. If you just need to send messages to other agents, then you essentially need just an interface with a single method. In that case, you could keep a list of functions such as
  Message -> unit.

I generally prefer exposing events - this way, the system is less tightly coupled and you can more easily compose agents in various ways (they do not have to implement a specific interface to be composed). This article discusses agent-based architectures from a higher-level perspective, and may be useful too.

Answer 2

Why would you want to stick to a pure functional design ? F# allows a clean combination of functional and OOP principles and I would make use of both mechanisms and leverage the power of the language.

If you want to combine the functional and OOP aspects, I would start by making your objects immutable. Thus you're using objects, but in a functional paradigm.

Answer 3

You have come up with an OOD, is it surprising that an OOP solution seems the most natural?

If you rewrote the design description with processes, and data transformations in mind it would naturally fall out as a FP design, and sound really awkward in OO with lots of 'er classes. As it is there is almost zero description of the types of data or what transformations need to take place. At first glance I would say an agent is a function of three arguments a mailbox, a message handler(or list of message handlers), and a list of other agents' mailboxes to contact. If future dispatch is based on the message then the message handler is a function of two args. the message, and the list of mailboxes.