AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Schon wieder: Warum Interfaces

Ein Thema von exilant · begonnen am 19. Okt 2016 · letzter Beitrag vom 21. Okt 2016
Antwort Antwort
Seite 5 von 8   « Erste     345 67     Letzte » 
Aviator

Registriert seit: 3. Jun 2010
1.438 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#41

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 15:23
Hmm, ja stimmt auch wieder.

Was sagt denn der TE "Exilant" mittlerweile zu dem Thema? Ist das alles jetzt etwas verständlicher?
  Mit Zitat antworten Zitat
exilant

Registriert seit: 28. Jul 2006
133 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#42

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 16:28
Was sagt denn der TE "Exilant" mittlerweile zu dem Thema? Ist das alles jetzt etwas verständlicher?
Zunächst mal vielen Dank an alle Schreiber hier. Eine Menge Input. So eine Resonanz habe ich nicht erwartet. Das Thema treibt doch viele um. Wie weit mich das weiter gebracht hat kann ich noch nicht abschätzen. Ich muss mir das erst mal in Ruhe zu Gemüte führen. Dazu werde ich etwas Zeit brauchen. Dieser Thread wird dazu sehr nützlich sein. Danke auch besonders an stahli, der mich auf diesen Thread hingewiesen hat.

Das mit der "Verständlichkeit" war wie ich geschrieben hatte nicht so das Problem. Interfaces setze ich seit Ewigkeiten für die Office Atomation ein. Ausserdem kommuniziere ich hier mit OPC Servern (nicht UA) - das ist auch COM/DCOM und das klappt. Auch wenn die Programmierung von dem Zeugs eine Strafe ist.

Ich suche/suchte ja nach dem Nutzen von Interfaces in eigenen Anwendungen. Und in denen verzichte ich natürlich auf COM/DCOM und DLLs solange ich es selbst in der Hand habe. Interfaces als wie Lemmy es sagt "logische oder zwingende Weiterentwicklung klassicher OOP" zu sehen: Da muss ich erstmal hinkommen.

Ich denke das in einigen Beiträgen in diesem Thread echtes Gold steckt und mich die Nützlichkeit von Interfaces in eigenen Anwendungen jenseits von COM erkennen lässt. Ich werde lesen, testen und wieder lesen.

Nochmal vielen Dank an alle. Ich werde mich bestimmt noch zu dem Thema melden sowie ich das hier durchgeackert habe. Ich denke da werden noch ein paar Dinge offen bleiben...
Es gibt 10 Sorten von Menschen: Die einen können Binärzahlen lesen, die anderen nicht.
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
3.768 Beiträge
 
Delphi 10.3 Rio
 
#43

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 16:44
Freut mich.

Ein bisschen kann man das vielleicht auch sehen wie die Sinnhaftigkeit der Trennung von Businesslogik und GUI. (Das werden ja hier alle Beteiligten für nützlich halten.)

Interfaces trennen dann verschiedene Teile eines Moduls nochmal klarer voneinander ab und reduzieren noch weitere vorhandene Abhängigkeiten (und verbessern weiter die Übersichtlichkeit).
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
bra

Registriert seit: 20. Jan 2015
705 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#44

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 16:57
Delphi-Quellcode:
Supports(Test, IIntf2, Intf2);
if Assigned(Intf2) then
  Intf2.SomeMethod3;
Könnte man das nicht kürzen?

Delphi-Quellcode:
if Supports(Test, IIntf2, Intf2) then
  Intf2.SomeMethod3;
  Mit Zitat antworten Zitat
Aviator

Registriert seit: 3. Jun 2010
1.438 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#45

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 16:59
Delphi-Quellcode:
Supports(Test, IIntf2, Intf2);
if Assigned(Intf2) then
  Intf2.SomeMethod3;
Könnte man das nicht kürzen?

Delphi-Quellcode:
if Supports(Test, IIntf2, Intf2) then
  Intf2.SomeMethod3;
Siehe Beitrag von DeddyH. Da hat er es genau so gemacht.
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
26.858 Beiträge
 
Delphi 10.3 Rio
 
#46

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 17:22
Richtig, ich wollte ja nur zeigen, dass es so oder so geht, je nach persönlicher Vorliebe
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
hanvas

Registriert seit: 28. Okt 2010
133 Beiträge
 
#47

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 17:31

Ich suche/suchte ja nach dem Nutzen von Interfaces in eigenen Anwendungen. Und in denen verzichte ich natürlich auf COM/DCOM und DLLs solange ich es selbst in der Hand habe. Interfaces als wie Lemmy es sagt "logische oder zwingende Weiterentwicklung klassicher OOP" zu sehen: Da muss ich erstmal hinkommen.
Eine Sache die schnell einleuchtet ist das man Methoden von Klassen auf Objekte die aus unterschiedlichen Klassenhyrarchien stammen anwenden kann. Ich finde TFortbewegung2 einfacher zu warten, gut zu verstehen und typsicherer als TFortbewegung1.

Code:

type IBeweglich = interface
      end;

     TAuto = class(TSache,IBeweglich)
     end;

     TVogel = class(TLebendig,IBeweglich)
     end;

     TFortbewegung1=class(TAktion)
     public
      function begwege(was : TAuto) : Integer; overload;
      function begwege(was : TLebendig) : Integer; overload;
     end;

     TFortbewegung2=class(TAktion)
      function begwege(was : IBeweglich) : Integer;
     end;
cu Ha-Jö
  Mit Zitat antworten Zitat
frapo

Registriert seit: 8. Feb 2012
Ort: OWL
32 Beiträge
 
Delphi 10.1 Berlin Starter
 
#48

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 17:41
Vielleicht findet man leichter Zugang zu dem Thema, wenn man sich parallel dazu Entwurfsmuster mal ansieht? z.b. https://www.philipphauer.de/study/se...n/strategy.php.

Ein Klassiker für mich wäre eine Anwendung, die verschiedene "Datensenken" verfügbar machen möchte. Beispielsweise möchte man das Speichern in einer oder mehreren Datenbanksystemen möglich machen und/oder auch das Speichern als Plaintext, XML-File, CSV-Datei etc.

Da bietet sich doch die Nutzung von Interfaces gerade zu an.
  Mit Zitat antworten Zitat
einbeliebigername

Registriert seit: 24. Aug 2004
119 Beiträge
 
Delphi XE8 Professional
 
#49

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 19:00
Hallo,

Der einzige Grund, wieso ich bisher bewusst ein Interface eingesetzt habe (von COM und sowas mal abgesehen), war, dass ich Mehrfachvererbung für eine Klasse brauchte.
Was du meins ist, du brauchtest eine Mehrfachschnittstellenvererbung. Die ist ja auch relativ einfach umzusetzen.

Ist mir bis heute unverständlich, wieso Delphi sowas nicht unterstützt.
Was du jetzt meins ist die Mehrfachverhaltensvererbung, welche leider nicht so trivial ist.

Ich finde, Interface-Programmierung verhält sich zu OOP wie die OOP zur prozeduralen Programmierung.
Jetzt fällt mir sofort "Objektorientierte Softwareentwicklung" aus Unizeiten ein. Was hat uns der OOS-Vorleser immer an den Kopf geworfen.
Zitat:
OOP ist nur syntaktischer Zucker.
Ja und da haben wir mit einer nicht OOP-fähigen Programmiersprache OOP-Programmiert und somit das Konzept hinter OOP kennen gelernt.

Eine Klasse besteht aus einer Schnittstelle und deren Implementierung. Eine Klasse kann die Schnittstelle zusammen mit deren Implementierung einer anderen Klasse erben. Und das Vererben der Implementierung ist OOP. Ein Interface ist somit quasi eine halbe Klasse, nämlich die Schnittstelle. Der Vorteil von OOP ist die Codereduzierung. Ohne OOP müsste man bei einem TNumberEdit größtenteils das komplette TEdit bis runter zu TObject nochmal neu implementieren. Mit OOP ist das nur eine klitzekleine Vererbung mit dem überschreiben einer virtuellen Methode. Interfaces bringen keine weitere Codereduzierung. Falsch eingesetzt erhöhen sie sogar die Menge an Code.

Und hiermit stelle ich an die Interface-Prediger mal eine Aufgabe. Baut doch mal TNumberEdit, TEdit bis runter zu TObject Interface-like nach ohne Klassenvererbung und ohne die Klassen aus VCL/RTL einzusetzen. Aber bitte mit Implementierung. Mich würde mal interessieren wie das denn aussehen würde.

Interface-Programmierung kann sich nicht zu OOP verhalten, weil sie teil dieser ist.


Grundsätzlich kannst Du jedes Problem auch ohne Interfaces und ohne OOP lösen.
Ja, aber auch ohne Hochsprache und Assembler.

Und keinen interessiert es.
Doch, denn das wie ist entscheidend. Die Vorteile der Hochsprachen haben dazu geführt das sie sich durchgesetzt haben. Bei OOP ist es das gleiche.

Genauso wenig wie

Delphi-Quellcode:
type
  TFoo = class(TObject)
  public
    procedure DoFoo; //mit 1.000 Zeile Code
  end;
objektorientierte Programmierung ist,
Wieso ist das kein OOP. Selbst ein schlichtes
Delphi-Quellcode:
programm Test;
uses
  System.SysUtils;
var
  X: TBytes;
begin
  X:= TEncoding.UTF8.GetBytes('Test');
end;
ist OOP, wegen dem TEncoding.UTF8.GetBytes .

ist die Definition eines Interfaces, die Implementierung und Verwendung davon automatisch auch eine sinnvolle Verwendung eines Interfaces, weil es oft schlicht und ergreifend nur mehr Arbeit ist aber keinen Vorteil bietet, weil man die Technik falsch anwendet bzw. im falschen Kontext.
Das habe ich jetzt auch nach mehrmals lesen nicht verstanden.

Interfaces sind eine logische Weiterführung der OOP, vielleicht müsste man auch sagen, eine zwingende Weiterführung.
Nein. Interfaces sind Teil von OOP.

Aber es ist wie gesagt nicht damit getan ein

Delphi-Quellcode:
type
  IFoo = Interface
    procedure DoFoo;
  end;
zu schreiben und zu Jubeln "Ich kann Interfaces", sondern dann folgen automatisch auch weiter Punkte die dann wichtig werden, denn Interfaces werfen wie vieles andere auch, mehr Fragen auf, als sie beantworten Als ein Stichpunkt werfe ich hier nur mal Dependency Injection ein.


Der große Vorteil von Interfaces eröffnet sich erst in etwas komplexeren Systemen, in denen div. Klassen miteinander kommunizieren müssen. Hier hast Du die Möglichkeit, dass diese Klassen weiterhin miteinander arbeiten könne, sich aber gegenseitig nicht mehr persönlich kennen müssen:
Das bekommst du aber auch ohne Interface hin. Ich sage nur reine abstrakte Klassen. Die haben mit Interfaces was gemeinsam. Denen fehlt auch die Implementierung der Schnittstelle.

Delphi-Quellcode:
TAdresse = class()
...
public
  function GetAnrede: String;
  function GetName1: String;
  function GetName2: String;
  function GetStrasse: String;
....
end;

TPerson = class()
private
  FName, FVOrname: String;
  FStrasse: String;
....
public
  property Adresse: TAdresse read FAdresse;
Und damit wir einen Konsumenten haben:

Delphi-Quellcode:
TBrief = class()
public
  procedure ErstelleBrief(Empfaenger: TAdresse);
end;
hier hast Du einen harte Kopplung wie sie in div. Projekten vorkommt und alles ist OK.
Willst Du jetzt aber TBrief durch einen Unittest jagen hast Du das Problem, dass Du zwingend auch eine Instanz von TAdresse erzeugen und übergeben musst. Kein Problem, solange TAdresse keine weiteren Abhängigkeiten hat. Sobald das System und das BOM komplexer werden, wirst Du hier immer mehr abhängige Klassen vorbereiten müssen, instanziieren müssen bis du zu dem Punkt kommst: Unittests sind scheiße, weil Du für eine Zeile Testcode, 10, 20 Zeilen Code für die Instanziierung und für die Aufräumaktionen brauchst. Und du merkst nicht, dass eigentlich dein Modell ein Problem hat.
Was hindert dich daran erst mal eine rein abstrakte klasse TBasisAdresse zu definieren. Dann kannst du im Unittest eine schicke TUnittestAdresse bauen. Und beim Erzeugen von Objekten helfen Klassenreferenzen, die richtige Klasse zu verwenden. Und sollte es auch noch nach Jahren richtig sein, das bei allen Kindern ein gewisser Teil der Implementierung gleich ist, kann dieser ruhig in der Basis-Klasse verweilen und braucht somit nur einmal Implementiert und einmal gewartet werden.

Mit Interfaces sieht das ganze so aus:

Delphi-Quellcode:
IAdresse = Interface
  function GetAnrede: String;
  function GetName1: String;
  function GetName2: String;
  function GetStrasse: String;
end;

TPerson = class()
private
  FName, FVOrname: String;
  FStrasse: String;
....
public
  property Adresse: IAdresse read FAdresse;
Und damit wir einen Konsumenten haben:

Delphi-Quellcode:
TBrief = class()
public
  procedure ErstelleBrief(Empfaenger: IAdresse);
end;
Nun kann TPerson selbst entscheiden, welche Implementierung von IAdresse (es kann mehrere geben) für seinen Zwecke am besten ist. TBrief ist das aber völlig egal, durch das Interface weiß die Klasse, dass die vertraglich vereinbarten Methoden vorhanden sind und funktionieren, d.h. Du kannst TBrief dann auch damit verwenden:

Delphi-Quellcode:
type
  TStudent = class(X,IAdresse)
  ...
  public
    function GetAnrede: String;
    function GetName1: String;
    function GetName2: String;
    function GetStrasse: String;
und TStudent muss kein weiteres Element deines TPerson-Frameworks kennen, muss nicht von einer gemeinsamen Basisklasse abgeleitet werden,....
Und du musst in jeder Klasse die Implementierung komplett neu hinschreiben, ob wohl sie bestimmt zu 90% identisch sind.

Kommen wir aber nochmal zurück zur TPerson: ich habe oben geschrieben, dass TPerson entscheidet welche Implementierung von IAdresse es verwendet. Das ist aber schon wieder ein Fehler! Weil du baust dir hier wieder über die Hintertür eine harte Kopplung von 2 Klassen ein. Und genau das kann später wieder zu einem Problem werden, weil du dann an dem Punkt bis: Verflixt, jetzt wollte ich harte Kopplung vermeinden, muss aber halt irgend wo implementieren:

Delphi-Quellcode:
TPerson = class()
private
  FName, FVOrname: String;
  FStrasse: String;
....
public
  property Adresse: IAdresse read FAdresse;

...

TPerson.Create()
begin
  FAdresse := TFooAdresse.Create();
end;
Lösung für dieses Problem bietet die Dependency Injection: Ich kopple das Interface nicht an einer bestimmten Stelle mit einer konkreten Implementierung sondern biete über eine Liste (sog. Container) verschiedene Möglichkeiten an (oder vielleicht auch nur eine) wie IAdresse implementiert sein soll. TPerson instanziiert dann die IAdresse nicht selbst, sondern fragt bei der Liste an: Gib mir eine Instanz von IAdresse. Aber den Part könnte Stefan G. nun wirklich besser erklären
Um diese Abhängigkeiten aufzulösen brauchst du aber nicht zwingend Interfaces. Das geht auch mit Klassenreferenzen.

wie auch bei der OOP ist auch bei Interfaces das Problem: Mit 2 Sätzen und einem einfachen Beispiel ist das nicht erklärt....
Ja, die Entscheidung Interfaces einzusetzen ist nicht einfach. Denn sie haben auch Nachteile.

Ich verwende auch Interfaces, aber sparsam. Bei mir ist das Verhältnis zwischen Interfaces und reiner Klassenvererbung gefühlt gleich dem in der VCL/RTL. Eigentlich benutze ich Interfaces nur da wo ich bei gemeinsamer Schnittstelle keine gemeinsame Vererbungslinie aufbauen kann. Für dieses Problem wünsche ich mir aber eine andere Lösung. Und jetzt mal ein Beispiel wie die andere Lösung aussehen müsste und wo Interfaces absolut nicht helfen.
Delphi-Quellcode:
Type
  TCustomLabeledControl<T: TControl>= class(T)
  strict private
    fLabel: TLabel;
  strict protected
    function GetLabelControlClass: TLabelClass; virtual;
  protected
    // Und viele override
  public
    constructor Create(AOwner: TComponent); override;
    procedure SetBounds(ALeft: Integer; ATop: Integer; AWidth: Integer; AHeight: Integer); override;
    // Und noch mehr override
  end;

  TLabeledEdit= class(TCustomLabeledControl<TEdit>);
  TLabeledComboBox= class(TCustomLabeledControl<TComboBox>);
  TLabeledMemo= class(TCustomLabeledControl<TMemo>);
  TLabeledRichEdit= class(TCustomLabeledControl<TRichEdit>);

implementation

constructor TCustomLabeledControl<T: TControl>.Create(AOwner: TComponent);
begin
  inherited;
  fLabel:= GetLabelControlClass.Create(nil); // Oder auch Self wie man mag
end;
 
function TCustomLabeledControl<T: TControl>.GetLabelControlClass: TLabelClass;
begin
  Result:= TLabeledControlManager.Instance.GetLabelControlClass(…); // Einen String, Enum, Self oder was auch immer passent ist übergeben
end;

procedure TCustomLabeledControl<T: TControl>.SetBounds(ALeft: Integer; ATop: Integer; AWidth: Integer; AHeight: Integer);
begin
  inherited;
  fLabel.SetBounds(…);
end;
einbeliebigername.
  Mit Zitat antworten Zitat
Jim Carrey
(Gast)

n/a Beiträge
 
#50

AW: Schon wieder: Warum Interfaces

  Alt 20. Okt 2016, 19:35
Wenn ich das bisher richtig verstehe geht es bei Interfaces quasi vordergrundig um die Komprimierung des Codes.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:45 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf