Wozu Interface ??

Nuckey · Beiträge: 78

ich habe hier ein kleines vertsändnissproblem mit dehn sinn von interface`s.
welchen vorteil bringt es mir ?.
laut buch soll es einen "vertrag" zwischen classe und interface geben,die dehn user zwingt die funktion zu implementieren.soweit hab ich es verstanden ,aber dazu brauch ich kein interface .
eigentlich sollte (soweit ich es verstanden habe) das interface ,die mehrfachvererbung "simulieren" oder von der funktionalität nachbilden.

beispiel

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:

public interface ITest
{
     string Print();
}

public class TestA : ITest
{
     public string Print()
     {
        return "Hallo";
     }
}

public class TestB : ITest
{
     public string Print()
     {
        return "Welt";
     }
}

tja und hier erschliest sich mir nicht, warum ich interface einsetzen soll ,wenn ich es auch ohne machen kann !?.

mfg Nuckey

Moderiert von Th69: Code- durch C#-Tags ersetzt

jg72 · Beiträge: 22

Hi,

wenn Du nun an anderer Stelle ein Object vom Typ TestA oder TestB brauchst kannst Du durch das Interface sicher sein, dass es auch wirklich die Methode Print() gibt:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

...

public string PrintThis(ITest test)
{
   return test.Print();
}

...

Ansonsten müsstest Du wohl zwei Methoden PrintThis schreiben.

Moderiert von Th69: Code- durch C#-Tags ersetzt

Ralf Jansen · Verfasst: Fr 13.04.12 10:07

Zitat:

die dehn user zwingt die funktion zu implementieren.soweit hab ich es verstanden ,aber dazu brauch ich kein interface .

Wie? Wenn du jetzt sagst durch eine abstrakte Basisklasse dann fängst du an Interfaces zu "simulieren"

Nuckey · Beiträge: 78

hio jg72.

also ist das interface eigentlich nur zu typensicherheit da ?

da das interface (laut buch) die mehrfachverbung (polydingens) ersetzen sollte.

mfg nuckey

Christoph1972 · Verfasst: Fr 13.04.12 16:25

Also, Thema Interface interessiert mich auch immer wieder, da ich einfach keine Verwendung dafür finde und ich habe schon leichte Komplexe deswegen :-)

Kann das einfach an meinen Aufgaben (Datenverarbeitung) liegen? Oder wird ein Interface einfach überbewertet?

_________________
Gruß
Christoph

Ralf Jansen · Verfasst: Fr 13.04.12 16:38

Zitat:

Kann das einfach an meinen Aufgaben (Datenverarbeitung) liegen?

Datenverarbeitung ist irgendwie ziemlich universell

Oder welche Anwendung verarbeitet letztlich keine Daten :gruebel:

Jedes Softwareproblem kann man auch ohne spezielle Features lösen. Aber um sinnvoll mit dem .Net Framework umzugehen braucht man die eigentlich ständig. Hast du noch nie in einer Klasse IComparable, IEquatable etc. implementiert?

Nuckey · Beiträge: 78

ich merk schon das es etwas längere sitzung benötigt, um das ganze von allen seiten zu beleuchten, oder so.
werde mir einige beispiele ansehn und selber probieren

danke erstmal

mfg nuckey

Christoph1972 · Verfasst: Fr 13.04.12 20:13

Ralf Jansen hat folgendes geschrieben:

Hast du noch nie in einer Klasse IComparable, IEquatable etc. implementiert?

Ne, bisher noch nicht, aber ich hatte auch ehr an eigene Interfaces gedacht.

_________________
Gruß
Christoph

Th69 · Verfasst: Fr 13.04.12 21:01

Hallo Christoph,

da scheinst du bisher aber nur kleine Programme geschrieben zu haben, denn sobald man Mehrschichtenprogramme (und gerade Datenverarbeitung mit GUI - Model - DataLayer ist ja das Standardprojekt dafür) schreibt, kommt man ohne Interfaces ja gar nicht mehr aus. Der Vorteil der Interfaces ist ja die "lose Kopplung" sowie die Wiederverwendbarkeit.

Anstatt konkrete Klassen zu benutzen, programmiert man nur gegen die Interfaces (so daß nachher ein Austausch der Klassen bequem möglich ist - und wenn es z.B. "nur" für Unit-Tests ist).

Evtl. solltest du dich auch mal mit Inversion of Control bzw. konkreter mit Dependency Injection befassen, denn dabei wird (fast) nur mit Interfaces gearbeitet, niemals (bzw. sehr selten - sic) mit konkreten Klassen.

Christoph1972 · Verfasst: Fr 13.04.12 22:01

Vielleicht würde beim mir der Groschen fallen, wenn mir jemand ein gutes Beispiel für meine Aufgaben zeigt? Wie schon erwähnt, habe ich schon häufiger darüber nachgedacht, wie und wann ich ein Interface nutzen kann. Es gibt so gar einen alten Thread von mir dazu.

Auch die Wiederverwendbarkeit von meinen Komponenten ist sehr gering, ich vererbe sehr selten etwas und es gibt nur wenige DLLs von mir, die ich ständig nutze.

Ich erfasse i.d.R. Rohdaten von Laborgeräten, berechne Ergebnisse, zeichne Diagramme und führe diese Daten als Bericht zusammen. Ich Erstelle Programme zum vergleichen von alten und neuen Daten, überlagern von Chromatogrammen und anderen Kurvenverläufen. Da bestehen immer Abhängigkeiten zu der Messtechnik, den Laborprozessen und bestehenden Infrastrukturen. Durch diese Abhängigkeiten sehe ich eigentlich kaum Möglichkeiten etwas häufiger zu verwenden. Klar, sämtliche Schnittstellen zu Hardware, Datenbank-Trafic, Serialisierung von Programmparametern habe ich als Komponenten entwickelt, die man in allen Programmen von mir wiederfindet, auch eigene Buttons und diverse UserControls.

Ja, ich denke es sind kleine Programme, wobei im Hintergrund sind sie doch meist ziemlich Umfangreich.

Ich würde mich ehr als Automatisierer bezeichnen und nicht als Softwareentwickler. Wobei mir die Softwareentwicklung am meisten Freude bereitet.

Aber wie gesagt, vielleicht bin ich einfach Betriebsblind und der Groschen muss erst fallen!?? Ich habe immer das Gefühl das ich was verpasse :roll:

_________________
Gruß
Christoph

Nuckey · Beiträge: 78

eine frage hab ich noch :
beispiel

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:

public interface ITest
{
     void Print();
}

public class TestA : ITest
{
   public void Print()
   {
      return "hallo";
   }
}

public class TestB : ITest
{
   public void Print()
   {
      return "hallo";
   }
}

Meine Frage: da ich jeweils in der klasse die methode print schreiben muss,wie händelt c# dieses ,ob die methode Print intern nur einmal vorkommt und die klassen drauf zugreifen oder exestiert die methode, jede für sich ??
im letzteren fall ,sehe ich keine brauchbare anwendung in bezug vererbung.

mfg nuckey

Ralf Jansen · Verfasst: Sa 14.04.12 12:49

Hier wird nix vererbt. Man spricht ja bei Interfaces auch eigentlich nie von Vererbung sondern von Implementierung. Das sind also verschiedene Print Methoden die zufällig das selbe tun aber über das selbe Interface erreichbar sind. Wenn du bei der Überlegung weitere Klassen zu implementieren die die Print Methode haben sollen bei allen oder fast allen zu dem Ergebnis kommst das der Code in der Print Methode gleich ist wäre ein Interface alleine eine schlechte Wahl sondern man würde eine Klasse dazwischen schalten die schon mal ein Standardimplementierung hat.

Beispiel aus dem Framework (mir fällt grad kein besserer ein) wären Listen. Damit eine selbst geschriebene Liste sich im Framework verhält wie jede andere Liste würde man IList<T> und damit dann auch ICollection<T>, IEnumerable<T> und deren nicht generischen Äquivalente implementieren. Da man aber meist gar keine komplett eigenes Verhalten braucht und obiges zu implementieren doch einen gewissen Aufwand bedeutet gibt es schon mal die Collection<T> bzw. CollectionBase Klassen vorbereitet von denen man dann ableiten kann. Der gesamte .NET Framework Code der mit Listen umgeht (zum Beispiel die foreach Schleife) geht aber nie davon aus das etwas Collection<T> oder CollectionBase ist sondern geht immer nur vom Interface aus damit eine bestimmte Funktion aufrufbar ist. Jeder der was anderes braucht als die Collection Klassen liefern kann so immer noch von Grund auf mit den Interfaces eine andere Liste schreiben und das ganze Listen behandelnde Subsystem im NET. Framework könnte damit umgehen.

Nuckey · Beiträge: 78

jo danke.
hatte mir dieses beispiel mit ildasm angesehn.
und hier wird zb. Print Virtual im interface deklariert

markieren

Quelltext

1:
2:
3:

.method public hidebysig newslot abstract virtual instance string  print() cil managed
{
} // end of method ITest::print

und sieht in prinzip nach einer abstracten virtuellen methode aus ,nackig ohne alles.
und da kann mann nur überschreiben

.
wieder was gelernt.

mfg nuckey

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme