DEV Community: Paolo Sciarra

Currying vs Dependency Injection

Paolo Sciarra — Fri, 29 Dec 2023 09:02:33 +0000

In this article, I want to describe a very simple concept used in functional programming: currying.

We have to imagine that in most functional languages, we deal mainly with functions. I will use Java as language for my examples, but it should be fairly easy to understand them and adapt to your language of choice.

Let's analyse the type of few functions:

public interface ExampleFunctions {
 Integer invertSign(Integer input);
 Integer add(Integer a, Integer b);
 Command createFrom(Properties ps, Pattern p, CommandFactory f);
}

Here we can see we have:

invertSign that has type: Function<Integer, Integer>
add that has type: Function<Integer, Integer, Integer>
createFrom that has type: Function<Properties, Pattern, CommandFactory, Command>

For non Java programmers, the interface Function in Java is generic or parameterised and the first n parameters represent the function inputs or arguments, and the last is the return type.

Now let's focus our attention on the two functions that have more than one argument add and createFrom.

Suppose you want to create an adder object, that adds any integer to a given number, like a fiveAdder.

Using an object oriented style, you can write a class like:

public class Adder {
 private final Integer firstAddend;

 public Adder(Integer firstAddend){
  this.firstAddend = firstAddend;
 }

 public Integer add(Integer number){
   return firstAddend + number;
 }
}

In this class we require a firstAddend integer dependency in the constructor, and then we have a different add method that takes just one parameter.

This way of passing parameters to an object is called Dependency Injection in this case through a constructor.

Using the concept of currying, we could have done this without declaring any class.

Currying is the transformation of a function that takes a structure of n arguments, into a chain of functions each taking one argument.

So for functions that take two arguments, we can write a curry function like this:

Function<A, Function<B, C>> curry(Function<A, B, C> f);

Then using this function we could have written:

var fiveAdder = curry(ExampleFunctions::add).apply(5);

Just like that, we have a function that adds any integer to five.

Now take for example the other function createFrom.

Imagine a situation where you have different Command objects, like TurnOnCommand and TurnOffCommand, and you want to use that method to create them in different ways (using different patterns, and different constructors), but for all of them, you want to use the same Properties object.

We can leverage the currying concept for functions with 3 arguments:

Function<A, Function<B, Function<C, D>>> curry(Function<A, B, C,D> f);

And then write:

var someProperties = ...;
var factory = curry(ExampleFunctions::createFrom).apply(someProperties);
var turnOnFactory = factory.apply(turnOnPattern).apply(TurnOnCommand::new);
var turnOffFactory = factory.apply(turnOffPattern).apply(TurnOffCommand::new);

There you have a factory function variable created after applying the first argument, someProperties, to the curried version of the createFrom method.

Without using currying you could have written:

var someProperties = ...;
var turnOnFactory = createFrom(someProperties, turnOnPattern, TurnOnCommand::new);
var turnOffFactory = createFrom(someProperties, turnOffPattern,TurnOffCommand::new);

or using dependency injection:

public class CommandsFactory{
  private final Properties p;

  public CommandsFactory(Properties p){
    this.p = p;
  }

  public Command createFrom(Pattern p, CommandFactory f){
   ...
  }
}

I hope you now have clear what currying means, and how you can use it as a replacement for new class creation and dependency injection, or how somehow these concepts are related.

Lenses: what they are and why you may want to use them ;)

Paolo Sciarra — Thu, 25 Nov 2021 19:34:52 +0000

This is my first post here, and I hope you will enjoy it.
I was trying to figure out which topic I can talk about and I came up with one I encounter in the last few weeks.

I am a backend software engineer in N26, Barcelona office. In N26 we use kotlin and we build microservices, as you can imagine, to run the digital bank.

We were working on a backoffice microservice, that somehow handled some data about our customers and exposed some endpoints to change them (like a CRUD but not exactly).

So I cannot tell the problem using the same data because those are privileged, but I can explain the same problem using a simpler example.

Suppose you have a model in your application to store information about a Person:

data class Person(
 val name: String, 
 val address: Address
)

data class Address(
 val streetName: String, 
 val number: String, 
 val city: String
)

Now imagine you have an endpoint and so a domain service to update information about the person, let's pretend you have an interface like:

interface UpdateAddressService {

 fun updateStreetName(
   person: Person, 
   newStreetName: String
 ): Person
}

Now if you try to implement such an interface using just kotlin language you can end up with a class like this:

class SimpleUpdateAddressService: UpdateAddressService {

 fun updateStreetName(
   person: Person, 
   newStreetName: String
 ): Person {
  val newAddress = 
    person.address.copy(streetName = newStreetName)
  val updatedPerson = 
    person.copy(address = newAddress)
  return updatedPerson
 }
}

Now you can imagine that things can easily become cumbersome, imagine for example if the streetName was another value object, something like:

data class StreetName(
 val streetType: String,
 val name: String
)

then you would end up with something like:

class SimpleUpdateAddressService: UpdateAddressService {

 fun updateStreetName(
   person: Person, 
   newStreetName: String
 ): Person {
  val updatedStreetName = 
    person.address.streetName.copy(name = newStreetName)
  val newAddress = 
    person.address.copy(streetName = updatedStreetName)
  val updatedPerson = 
    person.copy(address = newAddress)
  return updatedPerson
 }
}

As you can see, as soon as your model starts to become nested the longer you will take to do the simple update you were required to.

There is a simple concept in functional programming, called Lens. A lens is a very simple interface that lets you get something from a source, let's call it a target, and let you also set a new target given a source value.

interface Lens<S, T> {

  fun get(s: S): T
  fun set(s: S, newT: T): S
}

Now the real power as often happens in functional programming is that this structure supports what is called a Semigroup, meaning you can define an operation that takes two lenses and combines them, and also this operation is associative.

So for example you can define this combine method in the Lens interface like this:

interface Lens<S, T> {

  fun get(s: S): T
  fun set(newT: T, s: S): S

  fun <A> combine(l2: Lens<T, A>): Lens<S, A> {
    val self = this
    return object : Lens<S, A> {

      override fun get(s: S): A {
        val function: (s: S) -> A = self::get andThen l2::get
        return function(s)
      }

      override fun set(newT: A, s: S): S {
        val newT1 = l2.set(newT, self.get(s))
        return self.set(newT1, s)
      }
    }
  }
}

This is basically what arrow-kt provides to you without the need of having to define the Lens interface and all yours needed lenses by yourself.

Arrow 1.0 uses kapt kotlin annotation processor, and using the @optics annotation you will be able to leverage the generated code at compile time like this:

@optics
data class Person(
 val name:String, 
 val address: Address
) {
 companion object
}

@optics
data class Address(
 val streetName: String, 
 val number: String, 
 val city: String
) {
 companion object
}

And so with these newly defined data classes we can implement the previous interface in a different way:

class ArrowUpdateAddressService: UpdateAddressService {
 private val lens = Person.address.streetname
 fun updateStreetName(
   person: Person, 
   newStreetName: String
 ): Person {
    return lens.set(source = person, focus = newStreetName)
 }
}

and in case we had the StreetName value object, we just need to change the lens:

class ArrowUpdateAddressService: UpdateAddressService {
 private val lens = Person.address.streetname.name
 // unchanged code

So you can see how powerful and clean this structure is.

I hope you enjoyed this article.

See you!

References

The image in the cover is taken from Wikimedia