Schon wieder: Warum Interfaces

[DeddyH]

Zitat von einbeliebigername:

Aber wie schaffst du es, ohne über Klassenstrukturen nachzudenken, bei der Implementierung eines Interfaces in mehreren Klassen Codeduplikate zu vermeiden.

Das ist doch in meinem genannten Framework-Beispiel gar nicht meine Baustelle, sondern die des Anwenders. Und ich habe nie behauptet, dass man sich bei Verwendung von Interfaces keine Gedanken über die Klassenstruktur machen soll, das eine schließt doch das andere nicht aus.

[stahli]

@beliebigbenannter

Ich denke (wie DeddyH) auch, dass man beide Bereiche nicht durcheinander werfen sollte.

Vererbung ist eine Sache und die Verwendung von Interfaces eine weitere.
Für eine Vererbung ist man auf geneinsame Basisklassen beschränkt.

Mit Interfaces erreicht man eine bessere Entkopplung.

Man muss halt abwägen, wann der Mehraufwand der Interfaces Sinn macht und wann nicht.
Mir gefällt die Umsetzung der Interfaces in Delphi auch nicht so ganz.
Es wäre schön, wenn man nur

Delphi-Quellcode:

IMyIntf = Interface
  property MyProp: Integer read write;
end;

angeben müsste (wobei "read write" auch Standard sein, also weggelassen werden könnte)

Dann könnte man in der Klasse

Delphi-Quellcode:

TMyClass = class(TInterfacedObject, IMyIntf)
  ...
  property MyProp: Integer read fMyProp write fMyProp;
end;

oder auch Getter und Setter verwenden.
Das würde die Schreibarbeit, Refactoring und die Übersichtlichkeit deutlich verbessern.

So ist es jetzt leider etwas mehr Aufwand.
Aber den nehme ich u.U. gern in Kauf, weil ich das Projekt durch Verwendung von Interfaces insgesamt deutlich besser strukturieren kann.


Vererbung und Benutzung von Klassen ist ja ohne Frage ohnehin gegeben und Einzusetzen. Interfaces bringen ggf. jedoch noch einmal zusätzliche Struktur in das Projekt.

Ich würde nicht zwanghaft Interfaces einsetzen, aber bei etwas komplexeren Projekten im Regelfall schon.

[einbeliebigername]

Hallo,

Zitat von DeddyH:

Das ist doch in meinem genannten Framework-Beispiel gar nicht meine Baustelle, sondern die des Anwenders.

Das werde ich wohl nie nachvollziehen können, da bei meinen Frameworks ich der Anwender bin und diese immer aus einer konkreten Problemstellung entstehen. Und dann stecke ich bereit mitten in Klassenstrukturen und dann wird das auch damit gelöst.

Zitat von stahli:

@beliebigbenannter

Ich denke (wie DeddyH) auch, dass man beide Bereiche nicht durcheinander werfen sollte.

Ja, vieleicht übertreibe ich hier und da etwas, wie diejenigen die Interfaces als alleiniges Allheilmittel ansehen (oder es zumindest so aussehen lassen).

Zitat von stahli:

Man muss halt abwägen, wann der Mehraufwand der Interfaces Sinn macht und wann nicht.

Vollkommen ja, bloß bei mir kommt es oft so an das Interface die einzige Lösung sind und der Mehraufwand einfach unter den Teppich gekehrt wird.

Zitat von stahli:

Mir gefällt die Umsetzung der Interfaces in Delphi auch nicht so ganz.
Es wäre schön, wenn man nur

Delphi-Quellcode:

IMyIntf = Interface
  property MyProp: Integer read write;
end;

angeben müsste (wobei "read write" auch Standard sein, also weggelassen werden könnte)

Du hast recht, read write müsste der Standard sein. Dann vieleicht auch so:

Delphi-Quellcode:

iMyInterface
  property ReadWritProp: Integer;
  property ReadonlyProp: Integer readonly;

Zitat von stahli:

Ich würde nicht zwanghaft Interfaces einsetzen, aber bei etwas komplexeren Projekten im Regelfall schon.

Erst mal schauen wie breit und tief das Problem ist. Ist es er flach und breit dann Klassenstruktur. Ist es tief und schmal dann Intefaces. Beim Übergang von einem zum andern, der fließend ist, aber darauf achten das Intefaces auch Nachteile haben. Ein Nachteil kann auch sein, dass wenn man nicht selbst der Anwender ist, es dieser auch falsch benutzen kann, was einem später wieder schlimm auf den Kopf fallen kann.

einbeliebigername.

[stahli]

Ja, so kann ich mich dem anschließen.

[Ghostwalker]

Hab grad die letzen Beiträge hier im Thread gelsen...uijuiui....

Also..mal gaaanz locker bleiben

Da auch einiges an Begriffen (imho) durcheinander gewürfelt wird, hier mal (nach besten Wissen) die Definitionen dafür, wie sie mir bekannt sind und von unterschiedlichster Seite auch so bestätigt wurde:


OOP:
Die logische Weiterentwicklung der Prozedurealen Programmierung (Erfinder: Prof. N.Wirt), in
dem man Daten und die Prozeduren, die diese Daten manipulieren, zu einer Einheit zusammenfasst.
Vererbung, Polymorphy usw. sind alle Teil dieses Konzepts. Erfinder ist ebenfalls Prof. N.Wirt
(siehe Oberon/Smalltalk)


Interfaces:
Interfaces sind Regeln, welche Methoden und Eigenschaften eine Klasse, die dieses Interface
unterstützen möchte, mindestens Implementieren muss. Ich kann nicht sagen, wers erfunden
hat,(nein...nicht die Schweizer von Rikola) aber da die Verbreitung von Interfaces insbesondere
durch COM/ActiveX zeitlich in den gleichen Rahmen fällt, vermute ich mal MS dahinter.


Vorteile von Interfaces:

- Übersichtlichkeit

Insbesondere wenn man mit vielen verschiedenen Klassen hantiert, erleichtern Interfaces
den Überblick zu behalten. Auch bei Teams sind Interfaces recht nützlich, da Programmierer
A nur über das Interface einer Klasse bescheid wissen muss, die Programmierer B grad baut.

- Sprachunabhängigkeit

Als "Anwender" ist mir egal, ob die Implementierung einer Interface-Klasse jetzt in C, C++ ,
Brainfuck oder was auch immer geschrieben ist, noch nicht einmal die Implementierung ist
relevant. Den "Anwender" interressieren nur die Methoden und Eigenschaften des Interfaces.


Nachteile:

- Mehr Code

Da ich die Interfaces ja irgendwo definieren muss, wird zusätzlicher Code notwendig.

- Mehr Fehlerquellen

Zumindest bei den COM-like Interfaces, wg. Referenzzählung und automatischer Freigabe.


Ob man nun auf Interfaces setzt oder nicht, muss jeder selbst entscheiden. In manchen Fällen gehts
nicht anders (Stichwort Mehrfachvererbung in Delphi). Man sollte sich aber immer bewust sein, da man sich mit den Vorteilen auch immer Nachteile einhandelt

[frapo]

Zitat von Ghostwalker:

Hab grad die letzen Beiträge hier im Thread gelsen...uijuiui....

Also..mal gaaanz locker bleiben

Da auch einiges an Begriffen (imho) durcheinander gewürfelt wird, hier mal (nach besten Wissen) die Definitionen dafür, wie sie mir bekannt sind und von unterschiedlichster Seite auch so bestätigt wurde:

Das geht mir schon die ganze Zeit so. Siehe meinen Post #54.

Zitat von Ghostwalker:

Interfaces:
Interfaces sind Regeln, welche Methoden und Eigenschaften eine Klasse, die dieses Interface
unterstützen möchte, mindestens Implementieren muss. Ich kann nicht sagen, wers erfunden
hat,(nein...nicht die Schweizer von Rikola) aber da die Verbreitung von Interfaces insbesondere
durch COM/ActiveX zeitlich in den gleichen Rahmen fällt, vermute ich mal MS dahinter.

Zumindest bei den COM-like Interfaces, wg. Referenzzählung und automatischer Freigabe.

Auch hier wird meines Wissens nach der Begriff Interface nicht im Sinne der OOP angewandt. COM/ActiveX klingt doch einfach schon zu konkret. Der Begriff Interface wird hier eher aus technischer Sicht gesehen (also das Wie und nicht das Was).

In der OOP ist der Begriff Interface doch eher konzeptionell gemeint, also ohne konkrete technische Abbildung.

Drum hatte ich ja in Post #54 auch Links gepostet, die etwas Konkretisierung in das Konzept bringen könnten.

Interfaces sind aus OOP Sicht Vereinbarungen, Regeln, Verhalten, die eine implementierende Klasse einhalten muss. Dabei ist das "wie" egal, Hauptsache die Implementierung entspricht den Vorgaben. Dadurch werden die implementierenden Klassen in gewisser Hinsicht ja auch austauschbar, Stichwort Polymorphie(Vielgestaltigkeit).

Interfaces sind auch keine abstrakte Klassen, dass ist ja auch der Grund warum sie nicht zum Klassen-/Vererbungsbaum gehören. Von daher "verbietet" es sich schon konzeptionell Interfaces als Weg für die Mehrfachvererbung zu sehen.
Sprachen die Mehrfachvererbung zulassen, bietet dafür schließlich Konzepte an.

[Sailor]

Gehen wir mal so 40 Jahre zurück. Da wurde neben dem Modulkonzept das Prinzip Information Hiding (heutzutage Encapsulation, Kapselung genannt) propagiert. Der Verwender einer Komponente (ich will hier nicht Objekt sagen, um keine Verwirrung zu stiften) sollte nur noch über Funktionen/Prozeduren auf deren Funktionalität zugreifen dürfen, ohne darüber informiert zu werden, wie diese Funktionalität realisiert worden ist. Warum das? Nun, neben den öffentlichen Eigenschaften kann eine Implementierung zusätzliche, nur ihr zukommende Eigenschaften haben. Der clevere Programmierer nutzt die natürlich. Da helfen keine Verbote. Und wenn jetzt aus irgendwelchen Gründen was geändert werden muß, dann ist diese implizite Eigenschaft möglicherweise weg, eventuell mit katastrophalen Folgen. Um das zu vermeiden, ist Kapselung eines der Grundprinzipien der OOP geworden. Leider ist in den gängigen OOP-Sprachen die konsequente Trennung von Interface und Realisierung aus mir unerfindlichen Gründen "vergessen" worden. In Delphi sind zwar zarte Versuche in dieser Richtung zu erkennen. Man hätte aber z. B. Interface und Implementation auf 2 Dateien aufteilen müssen. Und in einem Interface dürfen nur die öffentlichen Funktionen/Prozeduren auftauchen. Alles andere wie Felder oder private Funktionen gehören in die Implementation. Und von C# oder Java will ich gar nicht erstreden, die haben das ganz fallengelassen. Und so weiß der Anwender immer noch, wie es gemacht wurde. Offensichtlich haben sich einige daran erinnert, daß das eigentlich verhindert werden sollte und das meines Wissens von COM herrührende Interface umgebogen, um dem Mangel abzuhelfen und stoßen nun kräftig ins Horn. Kann man machen, aber ob das zu besser lesbaren Programmen führt, wage ich zu bezweifeln. Auch die Themen Vererbung/Mehrfachvererbung, Parametrisierung von Klassen, Benutzung unterschiedlicher Implementierungen einunddesselben Interfaces in einem Programm sollten besser innerhalb einer OOP-Sprache gelöst werden.
Fazit: Ich verwende (COM-)Interfaces zur Realisierung von OOP-Interfaces nur dort, wo es angeraten erscheint, die Interna einer Implementierung vor dem Nutzer einer Klasse zu verbergen, mangels geeigneter Sprachkonstrukte. Aber vielleicht sehen wir in naher Zukunft ein Delphi 2.0, in dem das in aller Schönheit vorhanden ist.

[Ghostwalker]

Zitat von frapo:

Auch hier wird meines Wissens nach der Begriff Interface nicht im Sinne der OOP angewandt.

OOP hat mit Interfaces erstmal garnix zu tun (waren nie Bestandteil der OOP Definition).
Interfaces sind ein eigenständiges Konzept, das auf der OOP aufbaut

Ansonsten kann ich mich deinem Post nur anschließen frapo.

Zitat von Sailor:

Man hätte aber z. B. Interface und Implementation auf 2 Dateien aufteilen müssen.

Warum ? Das hätte nur zu Folge, das, analog C/C++, noch mehr Dateien rumfliegen. Mal abgesehen
davon, das das nix mit dem Interface-Konzept etwas zu tun hat.

[frapo]

Zitat von Sailor:

Gehen wir mal so 40 Jahre zurück. Da wurde neben dem Modulkonzept das Prinzip Information Hiding (heutzutage Encapsulation, Kapselung genannt) propagiert.

Lass uns ruhig so mutig sein, 50 Jahre zurück zu gehen. Simula67 gilt, so weit ich weiß, als erste Sprache die OOP-Konzepte wie new, class und so eingeführt hat. Wie der Name schon andeutet, passierte das in den 60ern, also noch vor Pascal, Modula2 oder Oberon.. von Smalltalk mal gar nicht zu sprechen.

Zitat von Sailor:

Der Verwender einer Komponente (ich will hier nicht Objekt sagen, um keine Verwirrung zu stiften) sollte nur noch über Funktionen/Prozeduren auf deren Funktionalität zugreifen dürfen, ohne darüber informiert zu werden, wie diese Funktionalität realisiert worden ist. Warum das? Nun, neben den öffentlichen Eigenschaften kann eine Implementierung zusätzliche, nur ihr zukommende Eigenschaften haben. Der clevere Programmierer nutzt die natürlich. Da helfen keine Verbote. Und wenn jetzt aus irgendwelchen Gründen was geändert werden muß, dann ist diese implizite Eigenschaft möglicherweise weg, eventuell mit katastrophalen Folgen. Um das zu vermeiden, ist Kapselung eines der Grundprinzipien der OOP geworden.

Genau. Bei der Kapselung interessiert die konkrete Implementierung keinen.

Zitat von Sailor:

Leider ist in den gängigen OOP-Sprachen die konsequente Trennung von Interface und Realisierung aus mir unerfindlichen Gründen "vergessen" worden. In Delphi sind zwar zarte Versuche in dieser Richtung zu erkennen. Man hätte aber z. B. Interface und Implementation auf 2 Dateien aufteilen müssen. Und in einem Interface dürfen nur die öffentlichen Funktionen/Prozeduren auftauchen. Alles andere wie Felder oder private Funktionen gehören in die Implementation. Und von C# oder Java will ich gar nicht erstreden, die haben das ganz fallengelassen.

Hättest du da mal ein Beispiel? In Jave, C# und Object-Pascal(also auch Delphi) klappt die Trennung eigentlich wunderbar. Ein Interface implementiert rein gar nichts. Dort sind nur Definitionen oder Vereinbarungen beschrieben.
Die eigentliche Konkretisierung bzw. Implementierung findet in den Klassen statt, die dieses Interface auch benutzen bzw. implementieren.

Das ist ja auch der Sinn der Kapselung.

Anders Hejlsberg, der Schöpfer von Turbo Pascal, Delphi und C#, wird sich da was dabei gedacht haben sich bei der Entwicklung von Delphi und später C#, eher an Java als an C++ orientiert zu haben. Die genauen Beweggründe kannst du ja bei ihm erfragen.

Auch du wirst nicht abstreiten können, dass sein Konzept in der Fachwelt "relativ" anerkannt ist. Man durchforste einfach mal die Stellenanzeigen und den aktuellen Stand der universitären Lehre.
Funktionale Programmierung ist und war auch immer ein Thema, hat bisher aber nie die Masse erreicht.

Wenn du andere Konzepte, Ideen, Kritik vorlegen kannst, fände ich es klasse davon zu lesen, vor allem was du konkret damit meinst, das Interface und Implementierung nicht voneinander getrennt sind, in deinen Worten "vergessen" wurden.

Zitat von Sailor:

...und das meines Wissens von COM herrührende Interface umgebogen...
Fazit: Ich verwende (COM-)Interfaces zur Realisierung von OOP-Interfaces

[/QUOTE]

Und da haben wir wieder COM etc. Das hat alles erstmal nichts mit OOP zu tun!

Interface(Schnittstelle) scheint einfach ein überstrapazierter Begriff zu sein und für alles zu stehen.. für manch einen.
Natürlich steht Schnittstelle erst mal für alles mögliche. In den 80ern unter TP hat man Schnittstellen programmiert um Drucker zu steuern, um beispielsweise auf DBase-Files zugreifen zu können etc. Das hatte aber alles nichts mit Interfaces im Sinne der OOP zu tun :/

Es gibt Unterschiede zwischen technischer und konzeptioneller Sicht.

COM, ActiveX, Dll sind übrigens ein Konzept eines Betriebssystems.. soweit ich weiß. Dennoch funktioniert die OOP auf jeder Plattform, weil sie einfach als Konzept was völlig anderes darstellt, als API-Calls oder so was zu verwursten.

[frapo]

Zitat von Ghostwalker:

Zitat von frapo:

Auch hier wird meines Wissens nach der Begriff Interface nicht im Sinne der OOP angewandt.

OOP hat mit Interfaces erstmal garnix zu tun (waren nie Bestandteil der OOP Definition).
Interfaces sind ein eigenständiges Konzept, das auf der OOP aufbaut

Hättest du dazu Quellen, gerne auch Literatur?