AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Schon wieder: Warum Interfaces

Ein Thema von exilant · begonnen am 19. Okt 2016 · letzter Beitrag vom 21. Okt 2016
Antwort Antwort
Seite 7 von 8   « Erste     567 8      
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.625 Beiträge
 
Delphi 12 Athens
 
#61

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 12:01
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.
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
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.343 Beiträge
 
Delphi 11 Alexandria
 
#62

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 12:23
@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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
einbeliebigername

Registriert seit: 24. Aug 2004
140 Beiträge
 
Delphi XE8 Professional
 
#63

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 13:11
Hallo,

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.

@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).

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.

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;
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.
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.343 Beiträge
 
Delphi 11 Alexandria
 
#64

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 13:18
Ja, so kann ich mich dem anschließen.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#65

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 13:19
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
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
frapo

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

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 15:18
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.

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.

Geändert von frapo (21. Okt 2016 um 15:20 Uhr)
  Mit Zitat antworten Zitat
Sailor

Registriert seit: 20. Jul 2008
Ort: Balaton
112 Beiträge
 
Delphi 2010 Professional
 
#67

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 19:30
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.
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#68

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 20:12
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.
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
frapo

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

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 21:35
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.

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.

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.

...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.

Geändert von frapo (21. Okt 2016 um 21:39 Uhr)
  Mit Zitat antworten Zitat
frapo

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

AW: Schon wieder: Warum Interfaces

  Alt 21. Okt 2016, 21:36
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?
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 7 von 8   « Erste     567 8      


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 17:10 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz