This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
This is one of the basic design principles "Code to interfaces and not to concrete classes". I'm sure that you do that all the time, with things as simple as for example. This is typically important with multi-tiered applications, with the extension/integration points of your application, and sometimes with things that you need to generalize or have several implementations for it. Coding to interfaces reduces the coupling between your concrete classes (and more importantly to the layers).
Imagine that you coupled your service layer with a hibernate data access layer, if your architect/technical lead decided for some reason or the other that you're going to re-implement the data access layer using iBatis, JPA or even JDBC. If you're not coding to interfaces, you'll be changing code in the service layer as well as creating the new implementation. Just imagine the number of bugs that could be produced in the already tested and stable service layer. If you are using interfaces and a factory to decide which implementation to use (or better off, dependency injection via spring, seam or EJB3), you won't face such problems.
Of course you'll not be doing that with EVERYTHING. Creating interfaces to domain objects, wrapper classes and utility classes is absurd.
For code that you publish, for example if you provide an API for third party developers, interfaces are a vital part to keep your API flexible for future extensions.
On the other hand, for code that is totally under your control and only used internally in your own systems, today's refactoring tools are powerful enough that introducing an interface for a class later on is so cheap that introducing it before you actually need it just doesn't make sense.
On the third hand , when you unittest your code, for example using JUnit, you will need to introduce interfaces anyway, to make your units reasonably testable. With other words, good unit testing practice already leads to reasonably decoupled systems in general, because to test a unit in isolation, it needs to be well decoupled from other units.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus