Interfaces für Projekt sinnvoll bzw wie werden Interfaces verwendet

Sofern ich den Sinn von Interfaces kapiert habe, sind diese für mein jetziges Vorhaben geeignet.

Ich möchte ne kleine Anwendung schreiben, welche Daten in einer Datenbank ablegt. Natürlich kann sich dann später die Datenbank ändern, also dass eine andere verwendet wird.

Von daher kam mir die Idee Interfaces zu verwenden um später die Datenbankklasse einfacher austauschen zu können.
Bzw die schönste Art wäre ja, je nach Einstellung über das Interface eine andere Klasse anzusprechen
Ist sowas möglich?

Hat jemand zufällig gute Tuturials über Interfaces mit C#
Ich hatte die vor Jahren mal in Java aber ehrlich gesagt bis heute noch nicht ganz verstanden

Hallo st@tic,

Ist sowas möglich?

ja, möglich und sinnvoll.

Hat jemand zufällig gute Tuturials über Interfaces mit C#

nö, aber es gibt ein paar Threads, die das ausführlich diskutieren, u.a. Interface, Klassen und Vererbung ? und Was ist ein Interface

herbivore

die threads kenn ich schon und viel weiter helfen die mir eigentlich nicht.

dort beziehen sich klassen auf ein interface und sobald dann in der klasse ne methode ausm interface fehlt meckert der compiler. mehr kann ich da nicht rauslesen und wenn interfaces nur allein für den zweck da sind, finde ich diese mehr als nur unnötig.

kann es sein dass ich diese interfaces mit richtigen schnittstellen verwechsel?

Schnittstellen sind überhaupt nicht unnötig. Ihre Vorteile sind nur nicht gleich auf den ersten Blick ersichtlich.

Beispiele:

Du hast eine schöne Anwendung geschrieben und möchtest anderen Entwicklern/Partnern eine saubere Möglichkeit zum Customizing und zur Erweiterung der Anwendung geben. Natürlich denkst Du sofort an Plugins. Aber wie kannst Du sicher sein, dass die ganzen PlugIns der anderen Entwickler auch "passen"? Mit einem Interface. Du verteilst mit Deiner Anwendung eine Assembly die ein Interface enthält. Das könnte z.B. so aussehen:

public interface IPlugIn
{
    void Connect(MainForm application);

    void Disconnect();

    string PlugInName
    { get; }
}

Wenn eine Klasse dieses Interface implementiert ist sie automatisch ein gültiges Plugin für Deine Anwendung, ansonsten eben nicht. Ein Interface ist wie ein Vertrag. Alle Beteiligten verpflichten sich ihn einzuhalten. Der Compiler ist der Notar, der sicherstellt, dass nur ein gültiger Vertrag zu stande kommt.

Als nächstes stellst Du Dir vor, Du hättest einen Applikationsserver für ein ERP-System geschrieben. Die gesamte Geschäftslogik liegt auf dem Applikationsserver. Die Windows.Forms basierten Clients müssen über TCP/IP auf den Applikationsserver zugreifen, um die geschäftslogikfunktionen konsumieren zu können. Woher soll der Client wissen, welche Methoden es auf dem Server zum aufrufen gibt und was diese für Parameter haben? Die Antwort liegt Dir bestimmt schon auf der Zunge. Die Geschäftslogik-Klassen auf dem Server implementieren Interfaces. Diese Interfaces liegen in einer separaten Assembly auf allen Clients und dem Server. So hat jeder seine "Kopie" des Vertrages. Die Clients können über die Schnittstelle die entsprechenden Methoden auf dem Server aufrufen. So könnte ein solcher Aufruf aussehen:

// Verbindung zum Auftragsdienst herstellen
IOrderService proxy;
proxy=(IOrderService)Activator.GetObject(typeof(IOrderService), "tcp://server:12056/OrderApplication.OrderService");

// Auftrag einbuchen
proxy.BookOrder(order);

Hoffentlich konnte ich Dir den praktischen Nutzen von Schnittstellen etwas näher bringen.

Wie Raini schon schrieb sind Interfaces immer dann notwendig, wenn man die Kopplung zwischen den Teilen (Klassen) der Anwendung minimieren will. Kopplung ist grundsätzlich negativ, weil es die Anwendung "monolithisch" und macht.

Allerdings ist dies nicht immer ein Problem, weil man bestimmte Teile der Anwendung einfach "fest" haben will, bzw. sicher ist, dass hier keine "Dynamik" erforderlich ist.

Möchte man aber Anwendung erweiterbar halten (auch zur Laufzeit), dann sind Interfaces die passende Methode. Die bekannten Design Patterns haben dies u.a. zum Ziel und verwenden daher Interfaces recht häufig.

Mit der Verwendung von Interfaces geht fast immer der Verzicht auf Konstruktoren einher. Stattdessen wird das Factory-Pattern eingesetzt.

In der Aktuellen dot.net Magazin Ausgabe hat es 4 Seiten "Alles was man über Interface wissen muss". Kann diesen Artikel nur Empfehlen, wobei ich den Preis des Magazins in der Schweiz (umgerechnet: 11€) zu teuer finde.

.unreal

Über Interfaces wurde ja schon "genügend" aufgeführt.

Wenn Du .net 2.0 verwendest und es speziell um Datenbank-"Klassen" geht,
kannst Du Dir ja auch mal die Klasse "dbProviderFactory" anschauen:

http://msdn2.microsoft.com/de-de/library/system.data.common.dbproviderfactory.aspx

Damit erspart man sich das "selberschreiben" von eigenen Datenbankabstraktionsklassen.

Ich widerspreche gern meinen Vorpostern.

Es ist eine Sache den Sinn von Interfaces zu verstehen(Quasi Intellektuell), den Nutzen erkennt erkennt man erst woanders....
Interfaces sind Werkzeug nicht Lösung.
(selbstverständlich ist ein Hammer geignet um Nägel in die Wand zu Schlagen, beantwortet aber ein Hammer die Frage nach Nagel oder Schraube?)

Meiin Tip: ein Werkzeug ist keine Lösung(Interface ist nur eine Variante der MV, ein Framework nur ne Krücke).
Der Weg ist Lang und es gibt keine ultimative Lösung...
Zu Details gerne(betrachte derzeitige Krücken ur nicht als Lösung).

Ich will dich auch nicht entmutigen, aber so genau kam nicht raus was du meinst. Sicher kann das Verständnis von Interfaces Weiterhelfen, wenn man weiss was zu tun ist und Wiederverwendbarkeit eine Rolle spielt(oder zu viel beteiligte Implementierer).
oder, oder...

ikaros? Du machst mir langsam Sorgen. Hast Du zuviel getrunken, oder steckst Du momentan in einer Sinnkrise?

Es spielt keine Rolle wie lang der Weg ist. Wichtig ist, dass man ihn beschreitet.

Was genau bestärkt dich zu dieser Ansicht?
Welche Punkte gefallen Dir nicht?

Original von ikaros
Meiin Tip: ein Werkzeug ist keine Lösung(Interface ist nur eine Variante der MV, ein Framework nur ne Krücke).
Der Weg ist Lang und es gibt keine ultimative Lösung...
Zu Details gerne(betrachte derzeitige Krücken ur nicht als Lösung).

Naja, das ist doch wirres Zeug. Das versteht kein Mensch.

Was ist "die MV"?
Was meinst Du mit Krücken?

Ich persönlich plapper so ein Zeug so ca. nach einer halben Flasche Vodka (darum meine Annahme), aber man soll ja nicht immer von sich selbst auf andere schließen 😉.

liegt wohl doch weniger am Alk, als am Auseinanderwndern der Terminologie

Kurz also:
MV: ist ein Kürzel vür Mehrfachvererbung.( vielleich ziehst du auch nur die englische Variante der Kurzform vor)
Die Krücke ist: Die Gegenwart und ihr Umgang mit Problemen.(Krücken haben geile Namen wie: MVC, MVC(GUI), oder einfacher IOC. Muster am Morgen...

Wir können gern weiter diskutieren(mit Aussetzern(Level kann allgemein bis speziell sein)) wenns um die Sache geht, auch gern konkreter und mit Fach-(oder besser Buzz-)wörtern. Eine fachliche Diskussion fängt aber IMHO nicht mit dämlichen Unterstellungen an. Aber was solls jedes Gespräch fängt irgendwie an.

Du musst aber zugeben, dass man Dir da ohne weitere Erklärung nicht folgen konnte.

Mehrfachvererbung zum Beispiel gibts nicht bei C#. Auch wurde in den vorigen Posts dieses Threads nicht von Mehrfachvererbung gesprochen. Der Sprung von Schnitstellen bzw. dem interface-Sprachkonstrukt in C# zu der Abkürzung "MV" ist einfach ein bisschen weit.

Aber das haben wir ja bereits aufgeklärt.

Nimm die Vodka-Geschichte bitte nicht so ernst. Aber wenn ich einen Beitrag fünf Mal lese und ihn dann immer noch nicht verstanden habe, kommen mir derartige Gedanken.

Ok, ich gebe zu ich bin Schuld am Missverständnis. Es ist immer Frage der Sprache, ich nahm die falsche Basis(aufgrund einer falschen Annahme) da ich z.B. dachte MV hat im Bereich IT nüscht mit MassenVernichtung gemein. -> blödes Beispiel(oder auch nicht, jedenfalls sollte ich es wohl Ausschreiben da auch Firmenjargon nicht unbedingt Realitätsbehaftet sein muss).
Ich nehm also gern(Umschreibung für die Seite des Missverständnisses) die Schuld auf mich(mit obengenannter Erklärung zur Dummheit).
Das mit dem Vodka nehm ich natürlich nicht so ernst(finds aber wenig prickelnd).

Zum Thema:

Mehrfachvererbung zum Beispiel gibts nicht bei C#. Auch wurde in den vorigen Posts dieses Threads nicht von Mehrfachvererbung gesprochen. Der Sprung von Schnitstellen bzw. dem interface-Sprachkonstrukt in C# zu der Abkürzung "MV" ist einfach ein bisschen weit.

Das seh ich anders. Da Mehrfachvererbung nicht Implementation sein muss(meine Meinung.
Der Begriff Interface ist IMHO eine Bereicherung, die unterscheiden hilft zwischen Mehrfachvererbung von Implentation und Definition, nicht jedoch ein Ersatz für Mehrfachverbung generell ist.
(ok, der Satz war schlecht - mir fällt aber gerade kein besserer ein, Ich hoffe trotzdem verständlich gewesen zu sein.)

Ich habe den Eindruck, der Thread entwickelt sich nicht gerade zielführend...

Offensichtlich war ja, dass st@tic der Nutzen von Interfaces nicht _ganz _klar ist. Ob nun ein Interface ein Hammer, ein Nagel oder nach einer Flasche Vodka eine Schraube ist, scheint da nebensächlich.

Denke ich auch. Die Diskussion führt nirgends hin, und geht die ziellos weiter, werd ich sie schließen.

An St@tic die Bitte vielleicht mal die Forensuche zu bemühen, da gabs schon viele Beiträge zu dem Thema.

@Ikaros
Ehrlich gesagt sind deine Formulierungen manchmal irreführender als die Aussagen, kein Wunder das Misverständnisse entstehen, etc. Am besten ist immer sich vorm Posten nochmal in der Vorschau den Beitrag durchgucken und schaun ob wirklich jedermann den gleich versteht.