Javascript Refactoring with Higher-order Functions

Refactoring has and always been a part of development. On this article, we’re going to investigate on how we can use higher-order functions to remove code duplication.

Supposed, we are tasked to create functions to sum all the numbers from a given ‘x’ to ‘y’ number, then sum of the doubles, then sum of the square. Then we are tasked to do the same thing but instead of sum we get the product. The first thing that we do is to make everything work first before we do the refactoring.

So, once we have the code working, we can now start refactoring our code. The first step is to see the commonality of the functions. We’re going to start with the functions that has the most common code. So, based on our example we can say that all the add can be grouped together with the most common code, then product functions can be grouped together as well.

Let’s start refactoring all of our add function. As you can see the main difference of all our add function are the lines below.

With that in mind, let’s create a function called sum that accepts another function to do the processing and return a processed number.

With our new sum function, we can then refactor all of our existing add functions.

With the change we were able to remove all the duplicated code on our add functions. We used arrow functions to do the processing of numbers for us as you can see from above. But, we can further refactor our code to execute a the function to return a new function. Let’s do that.

With our recent change, we further reduced the number of lines to all of our add functions to a single-liner.

Let’s do the same thing for our product functions and see the difference from our original code above.

We reduced our code to almost half! But, we still see code duplication between sum and multiply function. In fact,  there are only two lines the differentiates the two as you can see below.

With this knowledge, we can create a generic function that can accept those changes. Let’s look at our new function.

We can choose to wrap the function again but then it will not be as readable as the one that we have now in my opinion.

Look at the wrapped version below and I’ll let you decide.

Well, it’s not as bad as it looks but usually I prefer not to have functions that are too deep. Like the one above, we see a function that returns a function that returns another function. Kind of confusing isn’t it?

Java Optional and Default Value

Null checking has always been part of programming. Before Java 8, we might have a lot of code like the one below.

With the addition of Optional class on JDK 8, It’s never been easy to check for null and return a default value, or throw an exception.

Let’s rewrite the code above using Optional.

Looks fine at first glance but there’s one problem with this code. To better understand the problem, let’s run a simple script.

As we can see, running the code above somehow calls the Dog constructor twice. Why is that? We know that the first one is coming from this line.

But where is the second call coming from? Well, it’s coming from the orElse method of the class Optional. You might be wondering why would it call the orElse method even if we passed a non-null object. The real issue here is that all values passed inside a method will always be evaluated. We should be aware of this when using Optional with “heavy” construction objects.

To avoid this problem, we’re going to use suppliers.

With those changes, we immediately see that Dog construction is not being called when the optional value is not null. We can further simplify the code when constructing new objects with a default constructor.

Simple and better than using if-else statements. Let’s see on our next article on how to simulate this on Scala. I’ll tell you now that it is way better due to one of the best features of the Scala language which is lazy evaluation. Stay tuned! 😀