Now, what happens if A.fs and B.fs depend on each other? In this case, you have a problem. The easy fix is to merge the two files, but this solution does not scale well. Another solution is to break code into smaller pieces, building small "islands" of circular dependencies, which can each be moved into their own file. Easily said, but not so easily said.
Consider an application involving processes and links. Processes can be executed, and can communicate with each other using unidirectional links.
The code might look like this:
type Process(name, config, ...) =
// Construction
...
// Methods
// Connection to links
member x.AddInputLink(link : Link) = ...
member x.AddOutputLink(link : Link) = ...
// Control execution
member x.ExecuteInSomeWay(args) = ...
member x.ExecuteInSomeOtherWay(args) = ...
member x.CheckIsReady() = ...
member x.MarkAsReady() = ...
// Debugging, and other stuff...
member x.ToggleDebugging(b) = ...
member x.SetDebugOutput(o) = ...
...
and type Link(name, config, ...) =
// Construction
...
// Methods
// Connection to processes
member x.ConnectOutputTo(p : Process) = ...
member x.ConnectInputTo(p : Process) = ...
// Read/Write data
member x.Send(data) = ...
member x.Receive() = ...
// Debugging ...
member x.ToggleDebugging(b) = ...
member x.SetDebugOutput(o) = ...
...
As Process and Link are mutually dependent, their code must be all in one file. That may seem OK at first, but things will become harder to manage as more code is added over time.
A first solution is to introduce interfaces for Process and Link, simply duplicating all their method signatures, and replace all occurrences of classes Process and Link by their interfaces. The interfaces can be moved to a separate file, which should be shorter, as it contains no code. Classes Process and Link can now each live in separate files.
Interfaces.fs:
type IProcess =
// Connection to links
abstract AddInputLink : ILink -> ...
abstract AddOutputLink : ILink -> ...
// Control execution
abstract ExecuteInSomeWay : Args -> ...
...
// Debugging, and other stuff...
member x.ToggleDebugging : bool -> unit
...
and type ILink =
// Connection to processes
abstract ConnectOutputTo Process -> unit
...
Process.fs:
open Interfaces
type Process(name, config, ...) =
// Construction
...
// Interface implementations
interface IProcess with
member x.ExecuteInSomeWay(args) = ...
...
Link.fs:
open Interfaces
type Link(name, config, ...) =
// Construction
...
// Interface implementation
interface ILink with
member x.ConnectOutputTo(p : IProcess) = ...
...
Still, Interfaces.fs may be excessively long, and we may end up in a situation where all interfaces are defined in one large file. Not very pleasant.
The next step consists of breaking up the interfaces. The debugging-related methods obviously belong to a IDebugable interface, which need not be concerned with the details of processes and links.
A process which is connected to the input side of a link has no need to have access to the methods taking care and transferring data from the link to the process, which indicates that ILink could be split in e.g. IInputLink and IOutputLink.
There is another case of excessive method exposure. Links do not control the execution of processes, that's the task of the scheduler. The final decomposition may look as shown below.
IActivable.fs:
type IActivable =
abstract CheckIsReady : unit -> bool
abstract MarkAsReady : bool -> unit
IExecutable.fs:
type IExecutable =
abstract ExecuteInSomeWay : Args -> ...
abstract ExecuteInSomeOtherWay : Args -> ...
InputInterfaces.fs:
type IReceiver =
abstract AddInputLink : ILinkInput -> unit
and type ILinkInput =
abstract Receive : unit -> Data
abstract ConnectOutputTo : IReceiver -> unit
OutputInterfaces.fs:
type ISender =
abstract AddOutputLink : ILinkOutput
and type ILinkOutput =
abstract Send : Data -> unit
abstract ConnectInputTo : ISender -> unit
The techniques shown here are by no means specific to F#, and are part of the "proper programming" techniques every object-oriented programmer should know and use. Before using F#, I almost exclusively used interfaces for polymorphism, on "as-needed" basis. The fact is, interfaces are also useful for modular programming.
Decomposing programs into interfaces and implementation helps writing reusable, readable code. It does have a cost, though, as it requires more typing. As long as keyboards remain cheaper than brains, the benefits should outweigh the costs.
