This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
Just wondering... I've been using static methods that call stored procedures from our database, for quite some time. I was just wondering if this is something I should NOT be doing, and if not , why, and what's the correct way?
(I have run into a few problems recently, and was wondering if this was causing my problems.)
No problem with that. The only thing is the exception catching...
a static block can throw exception but the managing of those exception is not standard... if any error, SQLException for example are thrown, you will receive a java.lang.ExceptionInInitializerError not a exception...
I think the best thing to do is to write a simple normal class that need to be instanciate and then call a init method to create your connection etc... Try to use static variable only for Constant variable. You can use static variable but the process of loading data in those variable can be not static... but who really mind... if it's working it's working...
I think Alain is talking about static initializers, however Jennifer mentioned static methods.
As for my own answer, I'm fairly new to JDBC, so I don't know all the implications. However, from a more OO point of view, I might balk at using only static methods. Personally, I would need more details to decide whether or not this is a good (or bad) design decision.
Ok, I'll chip in. There is nothing deeply wrong with static methods from a functionality point of view. If you are experiencing problems, it's not the static-ness of the method that is causing them.
Still, it's pretty bad OO design. They are basically global functions. You cannot use standard OO techniques such as inheritance with them. When you're writing unit tests, it is impossible to hand your business code a stub or mock implementation of the data access layer. If you need to plug in a different data access layer - because you're prototyping something, because there's a requirements change but you want to retain the ability to quickly back out - you can't write a second implementation and plug that in.
The correct way is to define an Interface with the DAO methods, write a class implementing that interface, and hand an instance of that class as a collaborator to your business code.
I really have to plug those new-fangled Dependency Injection (aka Inversion of Control or IoC) containers here, such as the Spring bean factory (warning: Spring is huge, don't try to use or even understand all of it at once, all the bits are independently useable). They make this highly object-oriented way of structuring your design really natural and enjoyable. Once the concept "clicks" with you, you'll wonder what masochism drove you to ever do without.