Don’t get me wrong, OOP is a great paradigm, F# implements it well, and OOP is absolutely essential when working within the .NET ecosystem. It’s just that sometimes a class hierarchy can be overkill.
I picked C# to implement the OOP example, but I don’t want the takeaway from this post to be C#==Bad/F#=Good. I want to illustrate the principles, and assume readers will be more familiar with C# than with C++ or F# OOP constructs. (The example does, however, illustrate how the “ceremony” that is C#’s lineage from C can make code more difficult to read. To be fair, the brain trusts behind C# and C++ are working to reduce some of this.)
My example is a rudimentary model of logic gates. Since the inputs to the gates are fixed, it’s not particularly useful, but I wanted to keep things simple.
Here is the OOP implementation. It models the problem using an abstract base class to model a general logic gate, and concrete overrides to model And and Or gates. As you can see, there’s quite a lot of complexity and page space devoted even to this simple implementation. (As always, all the code here is presented "as-is" and without warranty or implied fitness of any kind; use at your own risk.)
using System;using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication3{ // Model.public abstract class Gate
{public List<bool> Input { get; private set; }
public Gate (List<bool> input)
{Input = new List<bool>(input);
}
public abstract bool Test ();
}
public class And : Gate
{public And (List<bool> input) :
base(input) {}public override bool Test ()
{return !Input.Contains(false);
}
}
public class Or : Gate
{public Or (List<bool> input) :
base(input) {}public override bool Test ()
{return Input.Contains(true);
}
}
// Example.class Program
{static void Main(string[] args)
{bool baf =
(new And(new List<bool>()
{true,false,true})).Test();bool bat =
(new And(new List<bool>()
{true,true,true})).Test();bool bof =
(new And(new List<bool>()
{false,false,false})).Test();bool bot =
(new And(new List<bool>()
{false,true,false})).Test();Console.WriteLine("Your breakpoint here.");
}
}
}
And here is the F# discriminated union example, along with a “bonus” example showing the extension of the idea to active patterns. To me, at least, it looks a lot more straightforward and should be easier to understand when first encountered. It also takes up a lot less page space.
// Model.type Gate =
| And of bool list | Or of bool listlet test = function
| And(l) -> List.exists ((=) false) l |> not
| Or(l) -> List.exists ((=) true) l
// Example.let baf = And([true;false;true]) |> test
let bat = And([true;true;true]) |> test
let bof = Or([false;false;false]) |> test
let bot = Or([false;true;false]) |> test
// Bonus extension: active pattern.let (|Test|) (g:Gate) = test g
let fired = function | Test(b) -> b
let bafap = And([true;false;true]) |> fired
let batap = And([true;true;true]) |> fired
let bofap = Or([false;false;false]) |> fired
let botap = Or([false;true;false]) |> fired
printfn "Your breakpoint here."So what *is* the takeaway? It’s this: there may be entire classes of solutions that, under the OOP paradigm, get modeled poorly or not at all, for the no other reason than that the solution adds complexity and code beyond the worth of the model. Secondarily, the same can be for linguistic “ceremony,” which – for historical reasons – often emphasizes syntax at the expense of semantics.
-Neil
p.s. The astute reader will have already noticed that there is an even more succinct representation of the test in F#. It occurred to me as I was feeding Mr. Bun-bun his dinner:
let test = function
| And(l) -> List.exists not l |> not
| Or(l) -> List.exists id l
And the definitions of "Test" and "fired" can be simplified to:
let (|Test|) = test
let fired (Test(b)) = b
Which makes it plain that, in this oversimplified example, "fired" is just a complicated way of calling "test," but you get the picture...
