Tech Tips Digest: 9

So, it's been a very long time.. Hope you're all doing great out there folks :)

Previous Tips: Tip No. 1 | Tip No. 2 | Tip No. 3 | Tip No. 4 | Tip No. 5 | Tip No. 6 | Tip No. 7 | Tip No. 8

Tech Tip No41: Don't declare classes final for the sake of extending them in the future, do it at your 

own risk :)

Sometimes you might feel compelled to declare certain classes as final in order to seal them and protect their behavior from being changed. The sad news is that this is only valid on very rare occasions.

java.lang.String is an example of a JDK class that is final, you will never be able to extend it, and in case you need to provide your own flavor, you’re either left with the options to wrap it or simply construct a String like class with all of its methods and any extra methods you may need. I'm not saying that they should have made the String class extendable, I'm just using it as an example.

Object oriented languages are build with extensibility in mind, so limiting this feature doesn't seem like a very good choice at any given time unless you have a very convincing reason.

Tech Tip No42: Use loggers instead of sending your log statements to the default out or err streams, you'll have more control

Standard output and error streams of the JRE or any other language are only useful for certain occasions, you might wanna use them for debugging, but that is discouraged!

Pushing data over any stream means that you’re performing IO operations, and those sorts of operations as you might know are expensive. Now, using loggers, you’ll have more control over what log severity levels should be actually written to the log output (File, socket …etc) you are also gonna be able to shutdown logging all together if needed.

I’ve been using LOG4J as the logging API for more than 6 years and it’s proven to be simple enough and efficient enough, another very good choice would be SLF4J. But regardless of my choice there are plenty of other APIs’ out there.

Tech Tip No43: When writing enterprise #Java applications, try to avoid making them depend vendor specific configurations

Most application server vendors create their own custom configurations and extensions around the basic JEE specifications. For example, writing an application using Rational Application Developer and assuming it will work immediately on an Open Source application server such as JBoss will prove to be wrong most of the time.

Tools provided for building JEE applications by commercial vendors do give you the option not to use their custom extensions, so if you are planning on making your enterprise application cross platform as much as possible, I encourage you to read more into this subject.

Tech Tip No44: Try not to end up having different versions of the same library in the same project, things will get nasty one day

When you’re working on large scale projects, ones that require lots of libraries, failing to properly manage them will result in you having duplicates and in a worst case scenario, ending up having duplicates with different versions!

You may be expecting a certain version of class, except that the classloader actually had loaded the wrong version. In order to avoid such a scenario, I would recommend grouping libraries in sub folders based on function (See example below).

Tech Tip No45: Make sure you are using an interface driven approach to writing your code, your life will be much easier

Interface driven development has to be the best approach you could ever employ, it will save your neck in the future when you’re about to do maintenance on your code or when you simply wanna extend it.

Think of how easy it is to use JDBC in Java, all you have to do is use the proper driver implementation of the API. Take a look at your JDBC code and you’ll notice that you’re using interfaces all the time!

This subject leads into too many disciplines, such as but not limited to Inversion of Control (IoC), plugin development, …etc

Hope you enjoyed this post, drop a comment if you have more information to share :)