[deadlyomen17]

Le Interfacce sono molto legate alla programmazione orientata agli oggetti.

In questo contesto, una interfaccia, che è praticamente una classe totalmente astratta che definisce una serie di metodi senza implementarli, è un modo per consentire l'estendibilità, la riusabilità e la manutenibilità del codice.

Non a caso, il concentto di interfaccia è largamente usato nei design pattern.

In realtà i due approcci che dici tu, solo solo uno...ovvero il secondo:
Si crea una interfaccia che definisce una serie di metodi comuni a oggetti diversi. Si creano tante classi concrete che implementano l'interfaccia, tanti quanti sono gli oggetti che si vuole rappresentare.

Questo perchè si fa una interfaccia per consentire di interagire con qualcosa non nota a priori, e che la cui implementazione potrebbe essere addirittura cambiata nel tempo, senza ripercussioni.
Come questo sia possibile, deriva proprio dall'interfaccia.
L'interfaccia definisce una serie di metodi che sono visibili all'esterno, e che sono implementati, in maniera anche decisamente diversa, dalle varie classi concrete che la implementano.
Usando l'interfaccia, si ha un modo univoco per usare uno qualsiasi degli oggetti concreti che la implementano.

Il fatto che in molti casi pratici si da solo una implementazione di una interfaccia, non significa che questa sia inutile, proprio perchè rende il codice estendibile, riusabile e più facile da manutenere.

Ad esempio, una API grafica fornisce un unico oggetto per rappresentare un quadrato. Se in futuro si vorrà estendere l'API, bisognerà riscrivere quell'oggetto, rischiando di renderlo non più compatibile con alcuni utilizzi.
Se invece già in principio, si forniva l'interfaccia al quadrato, e non l'oggetto stesso, nel momento in cui si vuole estenedere l'API, basta creare una nuova classe che implementa questa interfaccia, e per esempio si può lasciare all'utilizzatore la scelta di quale delle due implementazioni di quadrato usare.