# Functions as interfaces

An important aspect of functional programming is that, in a sense, all functions are “interfaces”, meaning that many of the roles that interfaces play in object-oriented design are implicit in the way that functions work.

In fact, one of the critical design maxims, “program to an interface, not an implementation”, is something you get for free in F#.

To see how this works, let’s compare the same design pattern in C# and F#. For example, in C# we might want to use the “decorator pattern” to enhance some core code.

Let’s say that we have a calculator interface:

```
interface ICalculator
{
int Calculate(int input);
}
```

And then a specific implementation:

```
class AddingCalculator: ICalculator
{
public int Calculate(int input) { return input + 1; }
}
```

And then if we want to add logging, we can wrap the core calculator implementation inside a logging wrapper.

```
class LoggingCalculator: ICalculator
{
ICalculator _innerCalculator;
LoggingCalculator(ICalculator innerCalculator)
{
_innerCalculator = innerCalculator;
}
public int Calculate(int input)
{
Console.WriteLine("input is {0}", input);
var result = _innerCalculator.Calculate(input);
Console.WriteLine("result is {0}", result);
return result;
}
}
```

So far, so straightforward. But note that, for this to work, we must have defined an interface for the classes. If there had been no `ICalculator`

interface, it would be necessary to retrofit the existing code.

And here is where F# shines. In F#, you can do the same thing without having to define the interface first. Any function can be transparently swapped for any other function as long as the signatures are the same.

Here is the equivalent F# code.

```
let addingCalculator input = input + 1
let loggingCalculator innerCalculator input =
printfn "input is %A" input
let result = innerCalculator input
printfn "result is %A" result
result
```

In other words, the signature of the function *is* the interface.

Even nicer is that by default, the F# logging code can be made completely generic so that it will work for *any* function at all. Here are some examples:

```
let add1 input = input + 1
let times2 input = input * 2
let genericLogger anyFunc input =
printfn "input is %A" input //log the input
let result = anyFunc input //evaluate the function
printfn "result is %A" result //log the result
result //return the result
let add1WithLogging = genericLogger add1
let times2WithLogging = genericLogger times2
```

The new “wrapped” functions can be used anywhere the original functions could be used – no one can tell the difference!

```
// test
add1WithLogging 3
times2WithLogging 3
[1..5] |> List.map add1WithLogging
```

Exactly the same generic wrapper approach can be used for other things. For example, here is a generic wrapper for timing a function.

```
let genericTimer anyFunc input =
let stopwatch = System.Diagnostics.Stopwatch()
stopwatch.Start()
let result = anyFunc input //evaluate the function
printfn "elapsed ms is %A" stopwatch.ElapsedMilliseconds
result
let add1WithTimer = genericTimer add1WithLogging
// test
add1WithTimer 3
```

The ability to do this kind of generic wrapping is one of the great conveniences of the function-oriented approach. You can take any function and create a similar function based on it. As long as the new function has exactly the same inputs and outputs as the original function, the new can be substituted for the original anywhere. Some more examples:

- It is easy to write a generic caching wrapper for a slow function, so that the value is only calculated once.
- It is also easy to write a generic “lazy” wrapper for a function, so that the inner function is only called when a result is needed

We can apply this same approach to another common design pattern, the “strategy pattern.”

Let’s use the familiar example of inheritance: an `Animal`

superclass with `Cat`

and `Dog`

subclasses, each of which overrides a `MakeNoise()`

method to make different noises.

In a true functional design, there are no subclasses, but instead the `Animal`

class would have a `NoiseMaking`

function that would be passed in with the constructor. This approach is exactly the same as the “strategy” pattern in OO design.

```
type Animal(noiseMakingStrategy) =
member this.MakeNoise =
noiseMakingStrategy() |> printfn "Making noise %s"
// now create a cat
let meowing() = "Meow"
let cat = Animal(meowing)
cat.MakeNoise
// .. and a dog
let woofOrBark() = if (System.DateTime.Now.Second % 2 = 0)
then "Woof" else "Bark"
let dog = Animal(woofOrBark)
dog.MakeNoise
dog.MakeNoise //try again a second later
```

Note that again, we do not have to define any kind of `INoiseMakingStrategy`

interface first. Any function with the right signature will work.
As a consequence, in the functional model, the standard .NET “strategy” interfaces such as `IComparer`

, `IFormatProvider`

, and `IServiceProvider`

become irrelevant.

Many other design patterns can be simplified in the same way.