Refactor to strong types and get help from your IDE

Matthieu
Matthieu
Mar 26, 2018 · 3 min read

We, Java developers, are so proud of using a statically typed language ! So proud that we can’t help but trolling JS or PHP people all day long about how weak their tools are regarding type safety.

With time, we adopted a lot of tricks to leverage strong typing like Compilation Error Driven Development aka Type Driven Development.

But when we go back to our daily routine, the truth is that String is everywhere in our code-bases.

We chose our language because of type safety and we basically encoded everything in a String.

Go directly to JS. Do not pass GO, do not collect $200

I work for years on legacy code-bases. Maybe I like to suffer or maybe I unconsciously believe that greenfield projects are even worse than legacy ones. Or maybe I prefer not being the one trying to build a greenfield project to come with a legacy one.

So I deal with String. A lot. And everytime I see a String, I want to refactor the codebase to introduce a new type.


From String to strong type: the strategy

The strategy is pretty straight-forward :

  • Create the new type (immutable, with equals/hashcode/toString)
  • Provide a builder or a factory method depending on the object complexity
  • Start to replace the String you spotted in the first place with your type
  • Fix compilation errors
  • You’re done

Or maybe you are not and you just broke the entire application.

There’s at least 2 pitfalls that can defeat such a refactoring :

  • implicit calls to toString
  • API taking your instance as Object

So you need a very good testsuite. And even then, you have to be very careful.

Thus, you will fail.

And, eventually, you will stop doing these refactorings or at least think twice before going down that road again.

And life will be so sad because JS people will laugh at you and your String-bloated codebase.

Dry your tears, my gift will put a smile on your face again, because once again you will be able to refactor these Strings out of your code !

And now, let’s do some Intellij magic

Let’s say we have a String that encode a Domain (as in URL). You already did the 5 steps described above and your code compile.

To fix the remaining problems, follow these steps :

Step 1: use IntelliJ.

Step 2: Use Structural Search

Step 3: in “Existing Templates”, take choose “String concatenation”

Here is Structural Search window

Step 4: Use “Edit Variables” to specify that $b$ should be of type Domain

Just match cases where b is of type Domain

Step 5: trigger the search and you’ll find all implicit toString calls due to String concatenation of your object.

Step 6: do the same but put the constraint on $a$ expression instead

Step 7: to detect usage of API using Object as argument, we can use Structural Search too. You can use the “method call” template and put a constraint on the argument type

Be careful to have minimum count set to 1

Now, you will be able to review all method calls taking your new type, here Domain, as an argument of expected type Object. Congratulations!

I don’t know if you like that but I’m so happy about it that I needed to share it!

So James team, expect a lot of Strong Typing coming soon!

Linagora Engineering

We are Open Source Engineers, Hacking Awesome Stuff

Thanks to Benoit Tellier, Raphaël Ouazana, and Lukas

Matthieu

Written by

Matthieu

Linagora Engineering

We are Open Source Engineers, Hacking Awesome Stuff

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade