When should one use interfaces?

In languages such as Java and C# interfaces provide a means for a class to be have in a polymorphic manner. That is to say a class can satisfy more than one contract - it can behave as multiple different types, a class of one type can be substituted for another. In other languages this can also be provided by multiple inheritance, but there are various disadvantages to this approach. However, having a class behave as more than one type is not the most common motivation for using interfaces.

By programming to interfaces instead of classes you can also decouple your program from specific implementations. This makes it much easier to substitute one class implementation for another. This is particularly useful when writing unit tests where you may wish to swap some heavyweight class implementation with a lightweight mock object. If your program only expects an interface type, and both the heavyweight object and mock object implement said interface, then they are very easy to substitute.

Also, consider a simple Java example where I say have a program that displays pages of data on the screen. Initially I want it to get the data from a database or XML files. If I write my program so that it uses interfaces I can define an interface like so:

public interface PageDatasource {
    public List<Page> getPages();
}

And use it like so:

PageDatasource datasource = // insert concrete PageDatasource implementation here
List<Pages> pages = datasource.getPages();
display(pages);

I can then write separate database and XML implementations that adhere to this interface:

public class DatabasePageDatasource implements PageDatasource {
    public List<Page> getPages() {
        // Database specific code
    }
}

public class XmlPageDatasource implements PageDatasource {
    public List<Page> getPages() {
        // XML specific code
    }
}

Because I used an interface I can now use either implementation - Database or XML - interchangeably without having to change the parts of my program that ask for the page data. The XML and Database implementations likely do completely different things but all my program cares about is that the object supplying the page data implements the PageDatasource interface.

Interface Real Life analogy:

Let say you want to Issue a Book from Library. What you will do:
1) Go to Library
2) Find the Book which interests you
3) Select the Book
4) Go to Librarian Desk to request them to Issue the Book.

Now here Librarian is an Interface, which means you are not interested in who the hell is Librarian, you are only interested in that person sitting on Librarian desk(is the person who agreed to a contract to act as Librarian, which means that person agreed to implement all the behaviors of Librarian)

So let say: Behavior of Librarian are:
1) Issue book
2) Re-Issue Book
3) Return Book.
the person who is designated as Librarian (which means agreed to adapt the above three behaviors), must implement the behaviors in his own way.

Let say PersonA wants to play a part of Librarian, then he needs to adapt the above 3 Behaviors. We as Client don't care how he is performing his Librarian behaviors, we are only interested in that personA is Librarian and he abides to perform the Librarian tasks.
Therefore what you will do, is Reference by Interface[go to Librarian Desk(which will leads you to persons acting as Librarian)] and let say in Future one person left the Librarian post, then as client it won't affect you if you have approached the Librarian desk, instead of specific person acting as Librarian.So code to Interface instead of Concreteness is beneficial.

class PersonA implements Librarian {
    public void IssueBook(){...}
    public void ReIssueBook(){...}
    public void ReturnBook(){...}

    //Other person related tasks...
}