I am working with a piece of code that I find kinda strange. The code I am working on is part of an import utility that takes a CSV file and imports the data into the database.
Inside the code, I see:
ImportUtils.printf("Validation started");
When I look into this method, it is simply calling System.out.println:
public static void printf(String s) {
System.out.println(s);
}
Is there any advantage to this? Could this pose an issue down the road?
I think this can be a good thing - that way you are free to write to any buffer you wish by simply changing the implementation of the ImportUtils.printf method.
It is necessary? I don't know, it could be overkill but this kind of encapsulation can often prove to be a boon in times of need.
The name printf for the method is bad because printf stands for print formatted and this method has none of the functionality of the printf programmers know.
On the other hand, this indirection might be useful by allowing the logging method to be enhanced and updated in the future without changing the underlying code. I just would not have called it printf.
Not a Java guy but this looks like a classic case of "you can write Fortran in any language" with this case being C.
The only advantage I see is giving a C-programmer a head start in your API. If the method were called "DisplayText" or something relevant, I could see it having some value.
A typical example of obsessive decoupling. Completely pointless since if you really want System.out to write somewhere else, you're free to use System.setOut(). If you need more flexibility, there's not exactly a shortage of logging frameworks to choose from.
Instead of creating a simple System.out.println wrapper consider switching to a full logging API. There are many available ( Commons Logging, Log4j, SLF4J, and many more). These can easily be configured as simple wrappers around the console that are useful for initial development. Down the road these can be modified to write to files, send emails, write to database, ... These also provide contextual information ( like which class is generating the logs ) that is very useful and a pain to put in on your own.
I think somebody tried to be clever and make it easy to change to a logging frame work or something later in the development cycle.
The problem with this is that at the moment you change the call to system.out. to a logging framework all the logging calls are coming from the same class and the same function and they all will have the same priority. This means that you loose much of the useful features a logger automatically provides. Like seeing which class wrote the log message. Setting the debugger to higher log level to only get the most important messages etc.
So I would advise against this. It looks like a nice idea to make a fast change from system.out. to a logger or something more sophisticated but it doesn't help in the long run.