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”
Step 4: Use “Edit Variables” to specify that $b$ should be 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
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!