Tutorial Interfaces

[stahli]

Eigentlich hatte ich meinen Beitrag vorhin verworfen, aber vielleicht hilft er ja doch noch wem weiter ->

Vielleicht darf ich gleich nochmal auf mein Tutorial verlinken: http://www.delphipraxis.net/183702-i...-factorys.html

Neben der schon erwähnten möglichen Referenzzählung (wenn man es braucht und will) arbeitet man bei Interfaces eher mit Funktionalitäten statt mit konkreten Klassen.

Jedes Objekt kann mehrere Interfaces unterstützen, was bei Verwendung von Basisklassen in Delphi nicht geht.

Ich kann also alle Objekte bewegen, die IMove unterstützen und alle Objekte Loggen, die ILogging unterstützen.
Die konkrete Klasse spielt in dem Moment keine Rolle mehr. Jede im Projekt verwendete Klasse kann kein, eins oder beide Interfaces unterstützen.

Wenn man ohne Interfaces auskommt spricht da überhaupt nichts dagegen.
Der Einsatz von Interfaces erzeugt auch durchaus einigen Mehraufwand und Umstellung beim Umgang mit Objekten.

Bei komplexen Projekten kann sich der aber lohnen, da man u.U. mehr Struktur in das Projekt bekommen und ggf. Klassen später auch leichter austauschen kann. Man ist dann halt nicht von einer bestimmten Basisklasse abhängig.

[DeddyH]

So isses. Immer, wenn es um maximale Flexibilität geht, sind Interfaces das probate Mittel dazu. Für jedes Fitzchen aber nur noch auf Interfaces zu setzen ist in meinen Augen sinnlos. Wie immer hängt es halt vom Einzelfall ab.

[a.def]

Zitat:

Wo ist denn nun der Unterschied zwischen TDings und IDings? Ist I komplizierter als T?

Für doof halten darf man mich aber auch nicht.

[EWeiss]

Zitat von a.def:

Zitat:

Wo ist denn nun der Unterschied zwischen TDings und IDings? Ist I komplizierter als T?

Für doof halten darf man mich aber auch nicht.

Er wollte dir doch nur aufzeigen das es im Grunde genommen Fast das gleiche ist.
Denke nicht das er das böse gemeint hat.

gruss

[a.def]

Zitat:

Denke nicht das er das böse gemeint hat.

War es bestimmt auch nicht.

Aber ich finde, dass Interfaces ganz und gar nicht das gleiche sind wie normale Klassen. ich finde normale Klassen wesentlich angenehmer zu schreiben.
Wenn man X Objekte von Y Objekten ableiten muss, macht man im Grundaufbau irgendetwas falsch wie ich finde. Da helfen auch keine Interfaces.

[EWeiss]

Kommt halt darauf an für was man es verwendet.

Wenn ich eine Funktion aus meiner DLL öffentlich machen will dann verwende ich Interface weil der
Anwender sich dann nicht mehr um das laden der DLL kümmern muss.
Zudem erspart es mir für eine Funktion mehrere Exports zu generieren die ich so mit einer Erledigen kann.

gruss

[hoika]

Hallo,
wenn ich bestehende Klassen, die nicht von einer Basisklasse abgeleitet sind,
um eine gemeinsame Funktionalität erweitern will,
geht das nur über Interfaces.

[stahli]

Das Beispiel in #11 von DeddyH zeigt das eigentlich sehr schön.

Ohne Interfaces müsste man Wuppdi so schreiben:

Delphi-Quellcode:

{ TWuppdi }

procedure TWuppdi.Consume(const O: TObject);
begin
  if (O is TEdit) then
   ShowMessage((O as TEdit).DisplayString);
  if (O is TLabel) then
   ShowMessage((O as TLabel).DisplayString);
  if (O is TComboBox) then
   ShowMessage((O as TComboBox).DisplayString);
end;

Man muss also an der Stelle alle Klassen konkret kennen und darauf casten.

Wenn man irgendwann 2 neue Klassen dort anzeigen möchte, muss man diese in der Prozedur nachträglich mit aufnehmen - und in allen anderen Prozeduren, die diese neuen Klassen kennen müssen.

Auf eine gemeinsame Basisklasse zurückzugreifen geht hier ja nicht.

Mit Interfaces ist es halt einfacher, zu prüfen, ob das vorliegende Objekt von der Prozedur bearbeitet werden kann.
Man schaut sich nur noch an, ob das, was ich da habe displayed werden kann oder nicht. Man muss dann nicht mehr wissen, welche Klasse man konkret vorliegen hat und es kann sogar sein, dass man die konkrete Klasse überhaupt nicht kennt.

Wie gesagt, man MUSS das natürlich nicht verwenden, aber es ist gut, wenn man es kennt und darauf zurück greifen kann, wenn man mit einfachen Klassen mal nicht so gut zum Ziel kommt.

[Fritzew]

Der grösste Vorteil von Interfaces ist das die Consumer Klasse gar nichts von der Implementation mitbekommt.
Keinerlei Abhängigkeiten zu anderen Klassen. Jeder der versucht Unit Tests zu schreiben und das auch konsequent durchzieht
will die Vorteile nicht mehr missen. Die einzige Abhängigkeit ist die Interface Unit, fertig.

Ich arbeite in der CAD-Branche, wir müssen import und export zu verschiedenen Formaten bereithalten.

Unser Klassen haben einfach Methoden die ein Interface entgegennehmen. Welches Format da dann wirklich dahintersteht is egal.
Die verschiedenen Formate werden einfach bei einer Factory registriert.

function readImport(Import : IImport3d) : boolean; Ob da jetzt ein Step, SAT, Igel oder was auch immer ankommt ist egal.
Die einzelnen Bereiche können unabhängig voneinander getestet werden und gut ist..

[Uwe Raabe]

Ich verweise da mal schamlos auf meine Reihe von Blog-Artikeln von 2010 zum Visitor Pattern: The Visitor Pattern – Part 1, Part 2, Part 3 und Part 4

Insbesondere Part 2 und 3 gehen auf die Vorteile bei der Verwendung von Interfaces ein. Ist aber auch schon etwas mehr zu lesen...