Home » Design Pattern » DRY Code with Higher Order Function in Scala – Part II

DRY Code with Higher Order Function in Scala – Part II

DRY Code with Higher Order Function in Scala – Part II


This post is part II in my series about Higher order function in Scala.
You can find part I here
In this post I am going to introduce:

  • Higher-order function with generics type
  • Function composition

Hope you enjoy!




Higher-order function with generics type


With generics type, Scala give us an opportunity to reduce the duplicated code.
Let’s look at the bellow example:
We have resultSet is data which is object from Infrastructure, now we need to convert it to a model in Domain layer.


It will look up for a string (the key of a map), if it hasn’t any value, we will return an empty Seq. If not we will parse this json value to a model.
It’s quite good but it’s seem not DRY.
Let’s use generic type in this case.
Firstly, we can see the similar logic here is we take a string then parse the json value to Seq of some kind of Model (Country or City or Region or Zip).
Instead of do the same thing all the time, we can call it as type T for abstraction and work with this type.
The function was defined as bellow:


I used implicit value because I don’t wanna pass it into every function and we need a Reads type to working with json format.
Now we can call it to get the Model value here:


It’s shorter and not too hard for reader.
The important thing we care about is just the sequence of Country converted from data of Infra’s object, for example.
But now we have one more step before we can get the Model object.
We need to parse json value to some type, String or Int firstly.


Ok, it’s time to use higher-order function. We just need to pass it into our function here


Then our source code much more readable like this:


The Higher-order function above is quite complex, it’s not easy for beginner at the first time.
So the more flexible function we implemented the more unreadability source we have.
You can custumize yourself parseThenMap or parseThenFilter or parseThenStore any function that you want.
Higher-order function are useful but the complexity of function depends on the context and our team’s convention.
After refactoring, we can see the total different.
Screen Shot 2016-06-15 at 1.28.54 PM

Function composition


One of the feature in Functional Programming that I love the most is composition.
We can combine any pure function into one function very smoothly, it helps us to just need to focus on function in our scope then after that we can easily composite several function to solve our problem.
I recommend you guys to read this article Composing predicates.
The author explained very clear about Function composition.

These function are very interesting for me:


I tried to use its


I think these function very useful while working with any collection and predicates.
It helps our source code more extendable and readable.




Conclusion


Encapsulating common patterns of design into functional forms called higher order functions.
These functions not only shortens programs, but also produce clearer programs because the intended meaning of the program is explicitly rather than implicitly stated.
It is much easier to understand the program and the intention of the programmer is clearly expressed in the code.
Functions which take functions as arguments are much easier to re-use than other functions.

Using higher-order function help us save a lot of time because we don’t repeat ourself and our source code is more maintainable.

Thank you for reading this long post.




Reference


  • http://danielwestheide.com/blog/2013/01/23/the-neophytes-guide-to-scala-part-10-staying-dry-with-higher-order-functions.html
  • http://erlang.org/documentation/doc-4.8.2/doc/extensions/funs.html