Program to an Interface

“Program to an Interface” is basically a design principle. How to design the code so that  it will be easy to modify and maintain.
The very first time this principle was defined by GoF (Gang of Four) in their classic Book(Design Patterns) in 1995.
The GoF (Gang of Four) described a basic rule of reusable object-oriented design: "Program to an interface, not an implementation."
So what does “Program to an interface” really mean?
This principle is really about dependency relationships which have to be carefully managed in a large app. – Erich Gamma ( Co- author of the book “Design Pattern”)

“Program to an interface”, really means “Program to a supertype”.

If you don’t use an Interface you are programming to the implementation not the interface.
In other words you can say that you should focus not only on developing version one, but to also think about the following versions. This doesn't mean designing in future extensibility, but just keeping in mind that you have to maintain what you produce and try to keep the API stable for a long time.
:
So the point here is that you should be loosely coupling your classes in your application. When designing your systems you should always think about the interface (coupling) between your components and make sure they make sense. I firmly believe the best way to make a maintainable system is to create loose coupling and high cohesion as a wise man once taught me. But this can and is done in many languages, and at many shops without the need for the Java Interface.

Example  :
So what am I saying? I am saying if I showed you the following code:

public class BankDelegate {
   public void debit(Account account, Amount amount) {
      account.debit(amount);
   }
}

you would have no idea if account was an Interface, Abstract Class, or Concrete Class. And furthermore, I would suggest that it doesn’t matter. Let’s say my bank only has a single account type. This would work great. Now what happens when I need to add a second account type? I can either create a base class, that both my accounts extend from, or I can create an Interface. Either solution will work, and I don’t need to change the code in my delegate. Which means my interface has remained the same.
That is what it means to program to an interface. Because if I had originally wrote the BankDelegate class like this:

public class BankDelegate {
   public void debit(CheckingAccount account, Amount amount) {
      account.debit(amount);
   }
}

Then my interface is only good for classes that are of type CheckingAccount. So let’s apply the same logic as before. I could write this as an Interface, Abstract Class, or Concrete Class and you would have no idea based on the above code. But of course, had I written it as an Interface it would be loosely coupled, and therefore I would be able to change it extremely easy at a later time…Oh wait, errrrr…It doesn’t make sense for a SavingsAccount to extend Checking account. I need to add a new base class or interface of Account and extend that. It will take the same amount of work to change this to accept a SavingsAccount regardless of what notation I used to create the CheckingAccount type.
Because of that I would argue that programming to an interface is more about thinking about the names of your classes and methods than using a special notation to declare them.
Example 2:
Program to an interface means do not tie relationships to classes, instead tie them to interfaces. For example, I have a class C1 which is a parameter to method M2 in class C2. I code M2 method as follows :-
M2( C1 c )
I cannot use M2( C1 ) for processing any other class. Instead if an interface I1 is created and which is implemented by class C1, I can change the method signature to
M2( I1 i )
and this will be able to process objects of any class ( including C1 ) which implement this I1 interface.
Its desirable to always have classes implement interfaces and public methods of the class are always from interfaces ( this is mentioned in some Java coding standards on the net ), but this programming standard / guideline is not strictly followed in realtime projects.

http://www.artima.com/lejava/articles/designprinciples.html
http://www.fatagnus.com/program-to-an-interface-not-an-implementation/
http://www.coderanch.com/t/178299/java-SCJA/certification/describe-apply-program-interface-principle