How is dependency inversion related to higher-order functions?

Question

Today I've just seen this article which described the relevance of SOLID principle in F# development-

F# and Design principles – SOLID

And while addressing the last one - "Dependency inversion principle", the author said:

From a functional point of view, these containers and injection concepts can be solved with a simple higher order function, or hole-in-the-middle type pattern which are built right into the language.

But he didn't explain it further. So, my question is, how is the dependency inversion related to higher order functions?

Answer 1

Dependency Inversion in OOP means that you code against an interface which is then provided by an implementation in an object.

Languages that support higher language functions can often solve simple dependency inversion problems by passing behaviour as a function instead of an object which implements an interface in the OO-sense.

In such languages, the function's signature can become the interface and a function is passed in instead of a traditional object to provide the desired behaviour. The hole in the middle pattern is a good example for this.

It let's you achieve the same result with less code and more expressiveness, as you don't need to implement a whole class that conforms to an (OOP) interface to provide the desired behaviour for the caller. Instead, you can just pass a simple function definition. In short: Code is often easier to maintain, more expressive and more flexible when one uses higher order functions.

An example in C#

Traditional approach:

public IEnumerable<Customer> FilterCustomers(IFilter<Customer> filter, IEnumerable<Customers> customers)
{
    foreach(var customer in customers)
    {
        if(filter.Matches(customer))
        {
            yield return customer;
        }
    }
}

//now you've got to implement all these filters
class CustomerNameFilter : IFilter<Customer> /*...*/
class CustomerBirthdayFilter : IFilter<Customer> /*...*/

//the invocation looks like this
var filteredDataByName = FilterCustomers(new CustomerNameFilter("SomeName"), customers);
var filteredDataBybirthDay = FilterCustomers(new CustomerBirthdayFilter(SomeDate), customers);

With higher order functions:

public IEnumerable<Customer> FilterCustomers(Func<Customer, bool> filter, IEnumerable<Customers> customers)
{
    foreach(var customer in customers)
    {
        if(filter(customer))
        {
            yield return customer;
        }
    }
}

Now the implementation and invocation become less cumbersome. We don't need to supply an IFilter implementation anymore. We don't need to implement classes for the filters anymore.

var filteredDataByName = FilterCustomers(x => x.Name.Equals("CustomerName"), customers);
var filteredDataByBirthday = FilterCustomers(x => x.Birthday == SomeDateTime, customers);

Of course, this can already be done by LinQ in C#. I just used this example to illustrate that it's easier and more flexible to use higher order functions instead of objects which implement an interface.

Answer 2

If you want to change the behaviour of a function

doThis(Foo)

you could pass another function

doThisWith(Foo, anotherFunction)

which implements the behaviour you want to be different.

"doThisWith" is a higher-order function because it takes another function as an argument.

For example you could have

storeValues(Foo, writeToDatabase)
storeValues(Foo, imitateDatabase)

Answer 3

Short Answer:

Classical Dependency Injection/Inversion of Control uses a class interfaces as placeholder for dependant functionality. This interface is implemented by a class.

Instead of Interface/ClassImplementation many dependencies can be easier implemented with a delegate function.

You find an example for both in c# at ioc-factory-pros-and-contras-for-interface-versus-delegates.

Answer 4

Piggy-backing off of LennyProgrammers example...

One of the things that the other examples missed is that you can use higher order functions together with partial function application (PFA) to bind (or "inject") dependencies into a function (via its argument list) to create a new function.

If instead of:

doThisWith(Foo, anotherFunction)

we (to be conventional in how P.F.A. usually is done) have the low level worker function as (swapping arg order):

doThisWith( anotherFunction, Foo )

We can then partially apply doThisWith like so:

doThis = doThisWith( anotherFunction )  // note that "Foo" is still missing, argument list is partial

Which allows us later to use the new function like so:

doThis(Foo)

Or even:

doThat = doThisWith( yetAnotherDependencyFunction )
...
doThat( Bar )

See also: https://ramdajs.com/docs/#partial

... and, yeah, adders/multipliers are unimaginative examples. A better example would be a function that takes messages, and logs them or emails them depending on what the "consumer" function passed in as a dependency was.

Extending this idea, still longer argument lists can be progressively narrowed down to increasingly specialized functions with shorter and shorter argument lists, and of course any of these such functions can be passed to other functions as dependencies to be partially applied.

OOP is nice if you need a bundle of things with multiple closely related operations, but it turns into make-work to make a bunch of classes each with a single public "do it" method, a la "The Kingdom of Nouns".

Answer 5

Compare this:

String[] names = {"Fred", "Susan"};
List<String> namesBeginningWithS = new LinkedList<String>();
for (String name : names) {
    if (name.startsWith("S")) {
        namesBeginningWithS.add(name);
    }
}

with:

String[] names = {"Fred", "Susan"};
List<String> namesBeginningWithS = names.stream().filter(n <- n.startsWith("S")).collect();

The second version is Java 8's way of reducing boilerplate code (looping etc) by providing higher-order functions like filter which allows you to pass the bare minimum (i.e. the dependency to be injected - the lambda expression).