Ich mir die Erklärung jetzt schon ein paar mal durchgelesen, aber ich verstehe immer noch nicht, wofür ein Interface gut sein soll. Kann mir jemand das für Einsteiger erklären bitte?

Einfach ausgedrückt ist ein Interface ein Vertrag/Contract. Die Klasse, die das Interface verwendet muss daher die im Interface definierten Elemente implementieren.

z.B.

// Das Interface
public interface IMyNameInterface
{
    // Property Id - muss von jedem implementiert werden, der das Interface verwendet
    string Id{ get; set; }
} 

// Die Klasse, die das Interface implementiert
public class MyClass: IMyInterface
{
   // Dieses Property wird vom Interface vorgegeben, MyClass muss es implementieren
   public string Id{ get; set; }
}

Du gibst damit Funktionalität vor, die deineKlasse bietet, wenn sie dein Interface/deine Schnittstelle verwendet.

Hier ist noch ein anschauliches Beispiel

Hier ist das ganz gut erklärt: openbook.galileocomputing - 4.7 Interfaces (Schnittstellen)
Da findet sich auch der schöne Satz:

Eine Schnittstelle legt einen Vertragsrahmen fest, den die implementierende Klasse erfüllen muss.

Möglicherweise fragst Du Dich, warum Du ein Interface benötigst, wenn Du doch in Deiner Klasse dann genau die selben Methoden auch wieder als Signaturen hast. Und so kommen die Interfaces ins Spiel: nach außen hin legen diese einen "allgemeingültigen" Vertrag fest, der jedoch von unterschiedlichen Klassen dann unterschiedlich implementiert werden kann.

Beispielsweise könntest Du Dir ein Interface für Listen vorstellen, dass wir mal IListe nennen. Hätte dieses Interface IListe dann nun Methoden vorgeschrieben wie .FuegeEin() .Iteriere() .Sortiere() usw. dann ließe sich dies auf ganz unterschiedliche Arten und Weisen realisieren: beispielsweise als verkettete Liste implementiert, oder als binärer Baum. Jede Implementierung hat dabei Vor- und Nachteile (bspw. verkettete Liste kann schneller einfügen, aber binärer Baum kann schneller sortieren).

Damit Du nun flexibel bist, gibst Du nach außen hin erstmal nur das Interface IListe bekannt und entscheidest dann später, welche realisierende Klasse Du verwenden möchtest, bspw. um bestimmte Fälle zu optimieren.

="Trenne Realisierung von Konzept mit Hilfe einer Schnittstelle (Interface)"

Grüße
CRegenschein

Ein Interface beschreibt ein erwartetes Verhalten. Eine Klasse, die das Interface implementiert, verpflichtet sich, dieses Verhalten bereitzustellen. Dadurch entsteht (u.a.) folgender Nutzen:

- Wenn man mit einem Objekt irgendwelche tollen Dinge anstellen will und dafür darauf angewiesen ist, dass das Objekt bestimmte Verhaltensweisen hat, kann man diese Verhaltensweisen in einem Interface zusammenfassen und den Code dann gegen das Interface programmieren. Der Code wird dann mit allen Objekten funktionieren, die zu einer Klasse gehören, die das Interface implementiert. Ein schönes Beispiel dafür sind die Erweiterungsmethoden für IEnumerable in der Klasse Enumerable. Damit kann ich in einer Menge Elemente zählen, selektieren, filtern, casten usw., und das einzige, was die Menge dafür können muss: ich muss sie einmal durchlaufen können. Dieses "kann durchlaufen werden" stellt das Interface IEnumerable dar, dass von Arrays, List, LinkedList, Queue und vielen anderen Klassen implementiert wird - auf all diese Klassen kann ich die Methoden aus Enumerable anwenden, weil sie alle das Interface IEnumerable implementieren.

- Man kann verschiedene Implementierungen der gleichen Verhaltensweise gegeneinander austauschen. Wenn ich in meinem Programm einen Speichermechanismus benötige und den durch ein Interface ausdrücke, dann kann ich im Test einen ganz einfachen Dummy-Speicher verwenden und im Live-Betrieb eine Datenbank - ohne den eigentlichen Code anpassen zu müssen.

- Ein Interface stellt eine bestimmte Sicht auf eine Klasse dar. Wenn Du in eine Bank an den Schalter gehst, dann interessiert Dich von dem Menschen Dir gegenüber nur ihre Bankmitarbeiter-Seite. Sie ist aber vielleicht auch noch Ehefrau, Mutter, Hobby-Chorsängerin, Steuerzahlerin, Inhaberin einer Fahrerlaubnis usw. Das Analogon im Code wäre, dass Du durch die Verwendung eines "Bankmitarbeiter-Interface" dir selbst und anderen Lesern Deines Codes gegenüber ausdrückst, dass an dieser Stelle nur die eine Sichtweise relevant ist. Das macht den Code leichter lesbar, wartbarer und besser wiederverwendbar.

Keine Bange, wenn sich Dir der Nutzen von Interfaces am Anfang noch nicht komplett erschließt. Das kommt im Laufe der Zeit. Was ich Dir noch empfehlen kann, ist ein Buch über Entwurfsmuster (Design-Patterns) zu lesen, z.B. "Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software" von Erich Gamma u.a. oder "Entwurfsmuster von Kopf bis Fuß" von Eric Freeman u.a. (oder natürlich die englischen Originale dazu). Viele der dort beschriebenen Programmier-"best practices" sind de facto Anwendungen der einen Grundidee, ein bestimmtes Verhalten losgelöst von einer Implementierung in einem Interface zu beschreiben.

Also ich find grad Interfaces lasses sich am Besten an einem Beispiel erklären.
Stell Dir vor Du schreibst ein Programm, dass Plugins verwenden kann.
Dann gibst Du anderen Entwicklern eine Schnittstelle an die Hand, die sie implementieren müssen, damit das Plugin in deinem Programm läuft.

interface IPlugin
{
  void Init();
  void LoadSettings();
  //...
}

class MyProgram
{
  static List<IPlugin> Plugins
  publc static void Main()
  {
    Plugins = new List<IPlugin>();
    // Alle DLLs (Assemblies) aus einem definierten Verzeichnis laden
    // und nach Types durchsuchen, die IPlugin implementieren.
    // Die dann instanziieren und an die Liste Plugins anhängen.
    // Hier nur als Beispiel MyPlug auf die Liste gepackt.
    MyPlug mp = new MyPlug();
    Plugins.Add( mp );

    // Diese drei Zeilen bewirken dasselbe.
    // Das Schöne ist, dass Du den Typ MyPlug nicht kennen musst, sondern
    // einfach mit IPlugin arbeiten kannst, ohne Referenzen in Deinem C# Projekt
    // angeben zu müssen.
    IPlugin p = Plugins[0];
    Plugins[0].Init();
    p.Init();
    mp.Init();
  }
}

// Beipiel Plugin
class MyPlug : IPlugin
{
  void Init()
  {
    // do some init
  }

  void LoadSettings()
  {
    // load the settings
  }
}

Bezugnehmend auf den Beitrag von CRegenschein möchte die das ganze noch etwas ausweiten.

Zum einen sind da verteilte Architekturen (Client-Server z.B.). Der Client benötigt eine Beschreibung der Schnittstelle (oder API) die der Server zur Verfügung stellt. Der Server wiederum muss sich genau an diese Beschreibung halten. Für diese Beschreibung verwendet man ein Interface was aus diesem Grunde auch "Contract" (Vertrag) genannt wird, weil sich Client und Server über diesen "Vertrag" auf eine einheitliche Schnittstelle einigen und beide Zusichern, diese auch einzuhalten. Die genaue Implementierung dieser Schnittstelle auf der Gegenseite interessiert die jeweilige Partei nicht. Zudem kann ich dadurch die Implementierung ändern, verbessern, optimieren wenn dies nötig ist ohne inkompatibilitäten zu befürchten.
Diese verteilten Architekturen müssen nicht zwangsweise auf mehrere Rechner getrennt sein. Auch ein Plugin-System für deine Anwendung würde genau den selben Regeln unterliegen.

Der zweite Punkt auf den ich eingehen möchte bezieht sich direkt auf CRegenschein beschriebenes Problem der Listen. Alternativ zu einem Interface könnte man hier auch Abstracte Klassen verwenden von denen man Ableiten muss. Das Problem hierbei ist, das man in .Net nicht von mehreren Klassen erbene kann. Hingegen schon von mehreren Interfaces.