Glimpsing into the functional world from within the old world

Why does this intrigue me and it should probably maybe spark something in you. Well C# has been around for ages, as F# and other functional languages and approaches. But it was never so much in demand as it is today. Or it might just be my current perspective and my exposure to my technical social circle. What this means, simplification of the way we present the world we see in our codebase. Focusing on the domain, and removing the overhead that gives us so much noise instead of understanding the domain which directly means the translation of it into code. Why is this interesting? And why I won’t go much into the topic, because there are so many resources out there on functional programming, that is far greater in targeting the understanding of it. But what matters is that this change in the language is another step in that direction. And that it makes the obscure a bit more clear and better.

…To Live Is To Risk It All…

Rick and Morty

Photo by Samuel Regan-Asante on Unsplash

Why Not Records

Records and the simplicity they bring

When we start to think of functional and domain-driven development we also tend to consider immutable data. Records is something that was introduced with functional languages that target the goal of immutable data. And this is something that will bring us simplicity into our codebase instead of always mutating data, which sometimes just brings so much overhead and confusion that is just so opposite of simplicity that the record types bring.

Because of the closely related nature of the languages, we will be sticking to F# and C#. And let’s just start it off with a clear example from both languages:

Unbreakable Records

The example just shows how much they are all that one would need to define an immutable data type, and that is the simplicity it brings, a small change in the declaration of the data, but a lot of benefits were brought in the context of records from F#. By default Records can be very useful in defining value objects. Its nature says that they are immutable, but they can be defined as mutable(something that you might want to consider carefully before doing so). Using record types, will reduce some boilerplate(such as equality checks and much more) code that will be coming out of the box, declaration just became shorter than usual(making away with overhead that obscures the domain logic). As a showcase, this would be just some of the code that would be required to implement if no record types would have been used:

With value objects, it’s important to have a proper equality check and to follow the immutability principle. And this indeed can be achieved with very little overhead with record types. More on the value equality can be found in this MSDN language reference for record types. Besides having out-of-the-box value equality and immutability it also provides other features, such as nondestructive mutation. And when working with immutable data a common practice is to not modify an existing instance but to copy and modify the necessary values into a new value object, with a clear designation. Which can be used to copy an instance with modifications, with the benefit yet again to reduce some overhead.

Wrap Up

All in all, this is just a short example of what record types can achieve, but they are a great step forward in simplifying our codebase, reducing overhead, and making our value objects life simpler. Although this is not a functional programming language, it does open up a bit of what we can achieve there. Nothing will beat native support and first-level functional programming languages for functional programming.