Java Refactor Examples
By Rob van de Vijver, HZ HBO ICT second year student.
Date: 9 January 2022
Code language: Java
Code Editor used: Visual Studio Code
What is refactoring?
Changing existing code to make it understandable and easy to extend and makes it quicker to create complicated systems. While you will be refactoring you have called “Bad Smells” these are common design problems or bad design that is too complicated/unclear or a lot of unnecessary duplication. For example: Duplicated Code, Long Methods, Complex Conditional Statements, Primitive Obsession and many more.
Is this blog something for me?
This blog we show three common refactor options. The skill level of this blog is beginner/intermediate. So if you are a student and want to learn how to refactor, check this blog because this will help you with writing your own code and avoid making these common mistakes.
Purpose:
Today we are investigating how we can improve existing code and refactor it so it gets more readable, efficient and maintainable. We will focus on the indicate “Bad Smells” of Long Methods and Duplicated code. We will explain an indication, opinion and the final refactoring for two examples. After this blog you should be able to indicate “Bad Smells” of Long Methods and Duplicated code. For this blog we use random open source GitHub projects by using the explore option on GitHub.
Bad smell example 1: Long methods
Code source (public git repo): https://github.com/AnySoftKeyboard/AnySoftKeyboard
File name: MainClass.java
GitHub path: https://github.com/AnySoftKeyboard/AnySoftKeyboard/blob/master/buildSrc/src/main/java/MainClass.java
Code (before refactoring):
Indication:
This Code Smell Long methods:
This means that the method contains so much code you don’t know what is going on by first seeing it. Reference to https://sourcemaking.com/refactoring/smells/long-method
There is quoted: “any method longer than ten lines should make you start asking questions.”
This code contains 50 lines where 30 exists of actual code. Treatment that the site recommends is that code that needs comments for understanding has to be put in a new method. By using methods you can give a descriptive name that makes the main method (Build Dictionary in this case) more readable for other developers.
My opinion is that this is long method can be separated in multiple methods for more readable and containable purposes. The reason I picked this set of code is because it does multiple things and its hard to understand what this one method does. By refactoring it into multiple methods you can also navigate quickly and it gives a lot of information without using commenting. My personal rule of thumb is that code of only 2 lines doesn’t get a private method but this is my personal preference.
Refactored code:
Bad smell example 2: Primitive Obsession
Code source (public git repo): https://github.com/AnySoftKeyboard/AnySoftKeyboard
File name: MakeBinaryDictionary.java
GitHub path: https://github.com/AnySoftKeyboard/AnySoftKeyboard/blob/master/buildSrc/src/main/java/MakeBinaryDictionary.java
Code (before refactoring):
Indication:
This Code Smell Primitive Obsession:
This means that the used instance (in this case 255) is unknown for what it stands for. You can spot these by seeing random numbers without understanding why they are chosen. Then you have to check what it stands for and give it a proper name and change it to a constant. https://sourcemaking.com/refactoring/smells/primitive-obsession
There is quoted: “Use of constants for coding information (for example constant: USER_ADMIN_ROLE = 1 for referring to users with administrator rights).”
255 is a specific number but why isn’t clear, that is why this has to be refactored. After looking up 255 stands for the maximum amount of characters that can be used. By refactoring the code becomes more flexible to use, better understandable for the developers and easier to find/use. Also if the maximal amount of characters changes it has to be changed at only 1 location and not at all locations where 255 has been used.
My opinion is that random numbers in general are annoying to see in programs you I didn’t write myself. Most of the time I can’t even find the meaning of the random number. I prefer having constants and work with names because then it has 1 place to maintain (if the number has to be changed). Also numbers are harder to read then words for understanding the code by first seeing it.
Code:
This line has been added:
And has been adjusted to the code:
Lecture Material:
https://sourcemaking.com/refactoring/smells
Used for example 1:
https://sourcemaking.com/refactoring/smells/long-method
Used for example 2:
https://sourcemaking.com/refactoring/smells/primitive-obsession
暂无评论内容