Java is a good language to write in because it has evolved slowly over the years, letting programmers master it before new iterations and functionalities are introduced. Yet, there are still some best practices that you might need. These best practices include:
- Don’t be tricked by SPI evolution evaluation. SPI is a good way to let customers insert custom behavior into your code or library. The thing is, you might need to use context and parameter objects when you work with SPI rather than write methods into your code. With dozens of methods to anticipate your customers’ actions, it would mean you would have a bloated code.
- Avoid local, inner or anonymous classes. Using these classes might have some benefits, but you should not overuse them. This is because these classes refer to an outside instance and can be a source of memory leaks.
- Keep your C++ destructors in check. Destructors are just the opposite of constructor functions, and are called when you destroy or de-allocate objects. If you are using Oracle or Sun, then you might never have to debug the code that leaves memory leaks when allocated memory is not freed after removing an object. When dealing with destructors, it is best to free the memory in the inverse allocation order, meaning you free up the last allocated memory first and work backwards. This is also applicable to semantics that are similar to destructors, such as when you are using @after or @before JUnit annotations, when freeing or allocating JDBC resources or when calling super methods. The general rule is to consider where you should perform stuff in inverse when you are dealing with free/allocate, before/after and return/take semantics.
- Avoid null from API. You should make sure that you avoid returning null from your API methods as much as possible. The only times you should be returning nulls is when you are dealing with absent or uninitialized semantics.
- No returning null arrays from your API methods. While returning nulls is okay for some cases, you should remember that it is NEVER okay to return null collections or arrays!
- Use SAMs. With the coming of Java 8, it makes sense to write your API to accept single abstract method or functional interface. This will help you and your customers make use of Java 8’s lambdas, further simplifying the codes that you have to write. The thing is, you and your API customers might want to use lambdas as often as possible, so you must write your API to let them do just that!
- Set methods to be final by default. Java programmers might not agree with this simply because they are quite used to doing it the other way. But it makes sense to make your methods to be final by default because this assures that you will never override any method by accident and if you need to override a method, you can just remove the final keyword. This is ideal when you have full control of your source code and in static methods where shadowing does not make sense.
- Always be functional. Code using a more functional style rather than deal with states. You can pass state via method arguments, rather than manipulating a lot of object state.
- Try to avoid accept-all signatures as much as possible.
- Short circuit your equals() to gain better performance. This is especially true if you have large object graphs.
Need help with your Java development? Contact Four Cornerstone today!
Photo courtesy of Heidi Ponagai.
