Was sind Interfaces und wie wendet man sie an? (brauche tut)

[Sir Rufo]

Ein entschiedener Unterschied ist, dass eine Klasse mehrere Interfaces implementieren kann, aber nicht von mehreren Klassen erben kann.

Das funktioniert nicht

Delphi-Quellcode:

type
  TEsel = class abstract
  end;

  THund = class abstract
  end;

  TKatze = class abstract
  end;

  THahn = class abstract
  end;

  TBremerStadtmusikanten = class( TEsel, THund, TKatze, THahn ) // das geht nicht!
  end;

aber mit Interfaces geht es

Delphi-Quellcode:

type
  IEsel = interface
  end;

  IHund = interface
  end;

  IKatze = interface
  end;

  IHahn = interface
  end;

  TBremerStadtmusikanten = class( TInterfacedObject, IEsel, IHund, IKatze, IHahn )
  end;

[Dejan Vu]

Aber sind die Bremerstadtmusikanten nicht eher ein Stack? :mrgreen:

[mkinzler]

Zitat:

Das schafft man auch mit einer abstrakten Basisklasse.

Aber dann könnte eine Klasse nur eine Aufgabe erfüllen/Rolle. Bei Interfaces beliebig viele.

Zitat:

Du kannst eine Klasse unsichtbar machen, sodass Sie nie direkt instantiiert werden kann.

Das mit dem nicht instantiieren gilt auch in vielen anderen Sprachen für abstrakte Klassen ( in Delphi nur in neueren Versionen; in Delphi sind nur Methoden abstrakt).
Aber ich verstehe nicht, was du mit unsichtbar meinst.

Zitat:

Das geht -glaube ich- so nicht in Delphi. Es gibt keinen Zugriffsmodifizierer (private, protected, public) auf Typebene. Leider.

Innerhalb eine Klasse schon. Und wenn du einen Typ im Implementation-Teil deklarierst ist er auch nur in der Unit sichtbar.
Standardmässig gelten die Modifizierer aber nicht innerhalb der Unit, höchstens du deklarierst sie als strict.

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1260384)

Aber sind die Bremerstadtmusikanten nicht eher ein Stack? :mrgreen:

Historisch gesehen waren die zuerst ein Heap und haben sich dann zu einem Stack organisiert :mrgreen:

[Lemmy]

Zitat:

Zitat von Dejan Vu (Beitrag 1260374)

Zitat:

Zitat von Phoenix (Beitrag 1260371)

Die Idee dahinter ist, das viele unterschiedliche Klassen das gleiche Interface implementieren können.

Das schafft man auch mit einer abstrakten Basisklasse.

nur wenn alle Klassen von der abstrakten Basisklasse abgeleitet werden können. Wenn nicht, dann wirfst Du entweder OOP-Prinzipien über Bord oder machst Dein Klassenmodell künstlich komplexer als es sein muss. Und das sehe ich als großen Vorteil von Interfaces an: Ich kann gleiches Verhalten in unterschiedliche KLassen bzw. Klassenmodelle "injizieren", ohne dass diese voneinander wissen müssen. Und damit kannst Du dann Code wirklich wieder verwenden...

[Sir Rufo]

Zitat:

Zitat von Lemmy (Beitrag 1260388)

Zitat:

Zitat von Dejan Vu (Beitrag 1260374)

Zitat:

Zitat von Phoenix (Beitrag 1260371)

Die Idee dahinter ist, das viele unterschiedliche Klassen das gleiche Interface implementieren können.

Das schafft man auch mit einer abstrakten Basisklasse.

nur wenn alle Klassen von der abstrakten Basisklasse abgeleitet werden können. Wenn nicht, dann wirfst Du entweder OOP-Prinzipien über Bord oder machst Dein Klassenmodell künstlich komplexer als es sein muss. Und das sehe ich als großen Vorteil von Interfaces an: Ich kann gleiches Verhalten in unterschiedliche KLassen bzw. Klassenmodelle "injizieren", ohne dass diese voneinander wissen müssen. Und damit kannst Du dann Code wirklich wieder verwenden...

Das Beispiel von Phoenix kann man aber sehr gut auch mit einer abstrakten Klasse erreichen, darum ist der Einwand berechtigt, weil damit nicht wirklich der Vorteil/Unterschied/die Wesensart von Interfaces dargestellt wird.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1260385)

Zitat:

Das schafft man auch mit einer abstrakten Basisklasse.

Aber dann könnte eine Klasse nur eine Aufgabe erfüllen/Rolle. Bei Interfaces beliebig viele.

Da grübele ich jetzt widerum, was Du genau meinst: Was meinst Du da mit 'eine Aufgabe' vs. 'beliebig viele'?

Zitat:

Das mit dem nicht instantiieren gilt auch in vielen anderen Sprachen für abstrakte Klassen ( in Delphi nur in neueren Versionen; in Delphi sind nur Methoden abstrakt).
Aber ich verstehe nicht, was du mit unsichtbar meinst.

Erklärung: Ich möchte nicht, das meine Klasse (keine abstrakte) direkt instantiiert wird. Ich verlange, das sie über eine Factory instantiiert wird. Daher muss ich die Klasse verbergen, denn sie kann ja u.U. mehr, als ich nach außen hin preisgeben will. Wenn Du also die Unit einbindest (Assemblies gibts ja leider nicht), dann siehst Du nur das Interface und die Factory.

Delphi-Quellcode:

Unit myAssembly;
interface
Type
  IMyInterface = interface...
  IInterface1 = interface (IMyInterface)...
  IInterface2 = interface (IMyInterface)

function Factory<T : IMyInterface>() : T; // geht das? 
implementation
Type
  TClass1 : class (TInterfacedObject, IInterface1)
  end;

  TClass2 : class (TInterfacedObject, IInterface2)
  end;

...
end.

Hier sind die Klassen 'TClass1' und 'TClass2' unsichtbar.

Zitat:

Und das sehe ich als großen Vorteil von Interfaces an: Ich kann gleiches Verhalten in unterschiedliche Klassen bzw. Klassenmodelle "injizieren", ohne dass diese voneinander wissen müssen. Und damit kannst Du dann Code wirklich wieder verwenden...

Absolut, ich habe ja nicht gegen Interfaces gewettert.

[Sir Rufo]

@Dejan Vu

Ja, das geht so mit den Factories (allerdings nicht mit den Generics in einer simplen Funktion)

[Lemmy]

Zitat:

Zitat von Dejan Vu (Beitrag 1260392)

Zitat:

Und das sehe ich als großen Vorteil von Interfaces an: Ich kann gleiches Verhalten in unterschiedliche Klassen bzw. Klassenmodelle "injizieren", ohne dass diese voneinander wissen müssen. Und damit kannst Du dann Code wirklich wieder verwenden...

Absolut, ich habe ja nicht gegen Interfaces gewettert.

sorry, ich hatte einen Knoten im Hirn, ich dachte bei abstrakter Basisklasse an das hier:

Delphi-Quellcode:

TLogger = class()
---
end;

TPerson = class(TLogger)
---