Writing concise, elegant and clear code has always been a difficult task for developers. Not only will your colleagues be grateful to you, but you would also be surprised to see how exciting it is to constantly look forward to refactoring solutions in order to do more (or at least the same) with less code. One used to say that good programmers are lazy programmers. True, true... But really good programmers are adding beauty to it.
You can easily improve the readability of your code, exploiting the power of the Java language, even for pretty basic things.
Let's start with a concrete example:
One of the first lessons you probably learned from your Java (or Object-Oriented programming) teacher is the importance of testing the nullity of an object before invoking a method on it. Null pointer exceptions (NPEs) are indeed among the most common (and irritating) faults raised in the code of object-oriented languages.
In the above example, it is safe to ensure the 'color' String object is not null before comparing it to a constant. I personally have always considered this as an unnecessary burden on the programmer – especially for modern OO languages such as Java. As a workaround, there exists a (really stupid) trick for rewriting the condition without having to test for nullity. Remember, the equals() method is symmetric (if a=b then b=a).
At first glance, it might be seen a bit contra-natural when read, but eliminating the polluting code is certainly not worthless.
Let's continue our example, and imagine we now want to compare our color with multiple values. Java beginners would usually write something like:
Sometimes met more experienced Java programmers shortening such long if statement with:
Smart isn't it ? Not that much actually. Playing with substrings can be a dangerous game. For instance the following code might not give the expected results, especially if you are a man:
If you are looking for a good balance between elegance and readability, you had better opt for one of the following alternatives.
Few people know it, but there is still a way to reduce code verbosity when initializing the Set of primary colors:
In the event concision of code becomes an obsession, the Java Collections Framework can also come to the rescue:
The final keyword prevents the PRIMARY_COLORS variable from being re-assigned to another collection of values – this is particularly important when your variable is defined as public. If security is a major concern, you should also wrap the original collection into an unmodifiable collection. This will guarantee a read-only access.
It must be noticed that, though more readable, using a collection of values (especially with large collections) will generally remain slower than classical lazy OR's (ie using '||' instead of '|') because of theshort-circuit evaluation. Nowadays such considerations become futile.
After 16 years of complaints, Java 7 has - at last! - introduced the support of String in switch-case statements. This allows us to code things such as:
Let us finally end with what is probably the most object-oriented solution to our (so to say) problem. Java enumerations are primarily classes, and can therefore have methods and fields just like any other classes. By applying the Template Method design pattern, one can define an abstract method (modeling the test) which has to be implemented by all subclasses (modeling the response of the test applied to a particular item of the enumeration):
The resulting code is clear and self-documenting. Using this pattern is a great alternative in many cases to the more common “if - else if” logic since it is easier to read, extend, and maintain.
To conclude, as very often - and this is the power of the Java language – for one problem, there exist so many different solutions in terms of implementation. But deciding which one is the best is another story...
Let's start with a concrete example:
1 | String color = "green"; |
2 | ... |
3 | if ( color!=null && color.equals("red") ) { |
4 | System.out.println("Sorry, red is forbidden !"); |
5 | } |
In the above example, it is safe to ensure the 'color' String object is not null before comparing it to a constant. I personally have always considered this as an unnecessary burden on the programmer – especially for modern OO languages such as Java. As a workaround, there exists a (really stupid) trick for rewriting the condition without having to test for nullity. Remember, the equals() method is symmetric (if a=b then b=a).
1 | if ( "red".equals(color) ) { |
2 | System.out.println("Sorry, red is forbidden !"); |
3 | } |
Let's continue our example, and imagine we now want to compare our color with multiple values. Java beginners would usually write something like:
1 | if ( "red".equals(color) || |
2 | "yellow".equals(color) || |
3 | "blue".equals(color) ) { |
4 | System.out.println("This is a primary color"); |
5 | } |
1 | if ( "red|yellow|blue".0 ) { |
2 | System.out.println("This is a primary color"); |
3 | } |
1 | String type = "man"; |
2 | ... |
3 | if ( "woman|child".indexOf(0 ) { |
4 | System.out.println("Women and children first !"); |
5 | } |
01 | import java.util.HashSet; |
02 | import java.util.Set; |
03 |
04 | public static final Set< |
05 | static { |
06 | PRIMARY_COLORS = new HashSet<string>(); |
07 | PRIMARY_COLORS.add("red"); |
08 | PRIMARY_COLORS.add("); |
09 | PRIMARY_COLORS.add("blue") |
10 | } |
11 | ... |
12 | if ( PRIMARY_COLORS.contains(color) ) { |
13 | System.out.println("This is a primary color"); |
14 | } |
1 | public static final Set<new HashSet<string>() {{ |
2 | add("red"); |
3 | add("yellow"); |
4 | add("blue"); |
5 | }}; |
1 | import java.util.Arrays; |
2 | import java.util.Collection; |
3 |
4 | public static final Collection"red", "yellow","blue"); |
5 | ... |
6 | if ( PRIMARY_COLORS.contains(color) ) { |
7 | System.out.println("This is a primary color"); |
8 | } |
1 | import java.util.Arrays; |
2 | import java.util.Collection; |
3 | import java.util.Collections; |
4 |
5 | public static final Collection |
6 | Collections."red", "yellow","blue") ); |
7 | </string> |
After 16 years of complaints, Java 7 has - at last! - introduced the support of String in switch-case statements. This allows us to code things such as:
01 | boolean primary; |
02 | switch(color) { |
03 | case "red": |
04 | primary=true; break; |
05 | case "green": |
06 | primary=true; break; |
07 | case "blue": |
08 | primary=true; break; |
09 | default: |
10 | primary=false; |
11 | } |
12 | if (primary) System.out.println("This is a primary color"); |
01 | Color c = Color.valueOf("RED"); |
02 | if ( c.isPrimaryColor() ) { |
03 | System.out.println("This is a primary color"); |
04 | } |
05 |
06 | public enum Color { |
07 | RED() { |
08 | @Override |
09 | public boolean isPri |
10 | return true; |
11 | } |
12 | }, |
13 | BLUE() { |
14 | @Override |
15 | public boolean isPrim |
16 | return true; |
17 | } |
18 | }, |
19 | YELLOW() { |
20 | @Override |
21 | public boolean isPrim |
22 | return true; |
23 | } |
24 | }; |
25 | GREEN() { |
26 | @Override |
27 | public boolean isPrim |
28 | return false; |
29 | } |
30 | }; |
31 | public abstract boolean i |
32 | } |
To conclude, as very often - and this is the power of the Java language – for one problem, there exist so many different solutions in terms of implementation. But deciding which one is the best is another story...
