AW: Schon wieder: Warum Interfaces
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
sicher bekomme ich das auch mit einer abstrakten Basisklasse hin. Was ist aber, wenn ich keine gemeinsame abstrakte Basisklasse definieren will / kann? Wenn ich keine Interfaces hätte müsste ich zwangsläufig irgend wo aus dem Framework eine gemeinsame Elternklasse raus suchen und von der einen Erben erstellen - selbst dann wenn ich das nicht will, weil ich damit Abhängigkeiten eingehe. Mit Interfaces muss ich das nicht. Habe ich dagegen ein Interface zur Verfügung muss ich lediglich das implementieren und ich kann eine externe Funktionalität nutzen. Schau dir nochmal mein Beispiel an: TStudent muss von "Framework" um TBrief und TPErson nichts kennen, es musss lediglich IAdresse implementieren und schon kann ich die beiden Frameworks gemeinsam nutzen. |
AW: Schon wieder: Warum Interfaces
Zitat:
Die vom COM bekannten Interfaces kann man sogar mit normalem C implementieren und nutzen. |
AW: Schon wieder: Warum Interfaces
Zitat:
|
AW: Schon wieder: Warum Interfaces
Zitat:
Interfaces und somit OOP stehen für ein Paradigma, dass Wartbarkeit und Erweiterbarkeit, sowie Architektur von Software im Fokus hat. Siehe z.b.: http://openbook.rheinwerk-verlag.de/oop/ Das ist kein Thema, dass man mal eben in 30 Minuten vollständig erfassen kann. Mir kommt es in diesem Thread eh so vor, als ob man beim Begriff Interface(im Sinne von OOP), nicht von der selben Definition ausgeht. Der eine spricht von DLL's oder einer anderen Schnittstellentechnik, der andere missbraucht Interfaces für die sogenannte Mehrfachvererbung. Siehe dazu vielleicht: https://de.wikipedia.org/wiki/Schnit...schnittstellen Vielleicht liegt das an der Geschichte von Pascal/Object-Pascal(als ehemals imperative Programmiersprache) und die stete Bindung an die DLL-Hell. Java sowie C# machen ja eigentlich sehr schnell verständlich, was und wofür Interfaces eingesetzt werden. C++, ich glaube auch Perl und Phyton, sind momentan die einzigen populären Sprachen, die auf Mehrfachvererbung setzen. Es gibt Gründe dafür und auch gute Gründen dagegen. Das muss dann jeder für sich ausmachen. Ich bin da persönlich sehr zufrieden, dass Mehrfachvererbung in Java, C# und Delphi nicht möglich ist. Die Architektur einer Software ist schon kompliziert genug. |
AW: Schon wieder: Warum Interfaces
Headerdateien sind keine Interfaces. Nur, weil in Delphi der Anfang der Quelldatei sich "Interface" nennt, ist der dazu in C++ analoge Teil (die Headerdatei) noch lange keins.
Headerdateien sind dazu da, Vorwärtsdeklarationen und Extern-Deklarationen für die Verwendung der in der C++-Datei enthaltenen Implementierung bereitzustellen. Interfaces (und bei C++ abstrakte Basisklassen) werden verwendet, - um verschiedene Implementierungen von gleichartigem Code verwenden zu können - um Fassaden- und Adapter-Patterns zu realisieren - um Unit-Tests viel (!) einfacher zu machen, selbst wenn die getesteten Klassen im System "mittendrin" verwendet wird. In Delphi wird unglücklicherweise die Interface-Verwendung mit der Referenzzählung und automatischer Freigabe gekoppelt. Deshalb wird das auch häufig missverstanden. |
AW: Schon wieder: Warum Interfaces
Ich weiss nicht, ob es genannt wurde, woltle jetzt keine 6 Seiten lesen :
Mit einem interface kann ich 2 komplett verschiedene Klassen miteinander verbinden, zum Bsp. TTreeView und TListView, da könnte man dann ein AddItem in einem interface hinzufügen und dann ohne die klasse zu kennen über das interface AddItem aufrufen. |
AW: Schon wieder: Warum Interfaces
Nach meinem Verständnis ist genau das der Sinn von Interfaces: Abstraktion. Angenommen, wir haben eine Klassenstruktur mit 2 Zweigen: TFoo und TBar. Wollen wir jetzt einer Methode eine Instanz als Parameter übergeben, welche wiederum eine Methode der übergebenen Instanz aufruft, und diese Instanz soll entweder TFoo oder TBar (oder eine Ableitung einer der beiden) sein, dann haben wir 3 Möglichkeiten:
1. Deklaration einer Basisklasse mit dieser Methode, von der sowohl TFoo als auch TBar abgeleitet werden, der Parameter ist dann vom Typ der Basisklasse 2. Eine Abfrage innerhalb der aufrufenden Methode, ob die Parameter-Instanz TFoo oder TBar ist, der Parameter ist dann vom Typ TObject 3. Definition eines Interfaces, das von irgendeiner (oder auch mehreren) Klasse innerhalb der Struktur implementiert wird und Deklaration des Parameters als Typ dieses Interfaces 2 ist die unsauberste und unflexibelste Lösung, da sind wir uns wohl einig. 1 ist ein gangbarer Weg, kann aber bei mehreren solcher Fälle schnell unübersichtlich werden und dazu führen, dass schon die Basisklasse mit Methoden überfrachtet wird, die erst weiter unten im Zweig tatsächlich benötigt werden. Und zu 3: wie war nochmal der Titel dieses Threads? :mrgreen: |
AW: Schon wieder: Warum Interfaces
Hallo,
Zitat:
Zitat:
Zusammenfassung von Daten und Methoden in Verbindung mit Vererbung ist OOP. Vererbung ist das was dabei die Wiederverwendbarkeit von Sourcecode verbessert. Die Zusammenfassung von Daten und Methoden verbessert die Verständlichkeit. Damit man so viel wie möglich Code wiederverwendet setzt man Vererbung ein wo es nur geht. Interfaces bleiben dann nur für die Spezialfälle, wo Vererbung nicht mehr funktioniert. Bei einer Schnittstelle zwischen DLL und Anwendung kommt man mit Vererbung nicht zum Ziel, da braucht man und sollte man Interfaces einsetzen. Aber bei so simplen wie TAdresse gleich mit Interface anzufangen bläht den Code nur unnötig auf. Zitat:
Zitat:
Delphi-Quellcode:
) bemüht wird.
virtual; abstract;
Zitat:
Zitat:
Zitat:
Und schaue dir doch mal bitte mein Gegenbeispiel mit den LabeledControls an und sag mir wie die Zauberinterfaces (Auch diesen Begriff habe ich aus vielen Aussagen überspitzt zusammengesetzt) das Problem lösen. Interfaces können nicht zauber. Sie sind auch nicht die einzige Möglichkeit Abhängigkeiten aufzulösen. Sie sind sogar in gewisser Weise gefährlich. Zitat:
Zitat:
Was ich noch für Interfases gelten lassen würde, währ das Argument, dass man durch Interfases die Schnittstelle für eine Funktionalität deutlicher abgrenzen kann. Das müsste man aber ohne Zusätzliche Implementierung schaffen können. Also ein einfaches sinnfreies Beispiel. Man hat mehrere Formularklassen. Bei jeder will man die Caption von außen verändern können. Der Teil der Schnittstelle in der Basisklasse von den Formularklassen ist das Property Caption. Den Rest braucht man nicht für diese Aufgabe. Also könnte man jetzt mittels eines Interface den Teil abgrenzen, wie folgt:
Delphi-Quellcode:
Die Implementierung des Interface führt nicht zu mehr Code, da das was im Interface verlangt wird bereit in der Basisklasse vorhanden ist. Leider macht Delphi da einem wieder mitunter einen dicken Strich durch die Rechnung. Bei Properties in Interfaces muss man Getter (wenn man lesen will) und Setter (wenn man schreiben will) angeben. Das führt im konkreten Beispiel dazu, dass man in jeder Formularklasse, welche iFormCaption implementiert auch den Getter und Setter implementieren muss. Die sehen aber immer identisch aus. Selbst wenn man es schafft Getter und Setter in einer Basisklasse zu implementieren, ist das noch ein unnötiges aufblähen des Codes.
iFormCaption= interface
property Caption: string; end; TMyForm= class(TForm, iFormCaption) end; einbeliebigername. |
AW: Schon wieder: Warum Interfaces
Zitat:
|
AW: Schon wieder: Warum Interfaces
Hallo,
Zitat:
Delphi-Quellcode:
,
TAdresse1= class(iAdresse)
Delphi-Quellcode:
und
TAdresse2= class(iAdresse)
Delphi-Quellcode:
hat, dann haben doch die drei Klassen jeweils ein
TAdresse3= class(iAdresse)
Delphi-Quellcode:
. Der Funktionsrumpf sieht doch bei allen gleich aus (
function GetFirstName: string;
Delphi-Quellcode:
). Also kommt man doch zum Schluss GetFirstName in eine Basisklasse zu verschieben. Bestimmt sind 90-100% der Implementierung von iAdresse gleich. Dann kann man doch auch das Interface in der Basisklasse implementieren. Und damit wäre die Basisklasse die einzige, welche das Interface implementiert. Und somit wäre das Interface überflüssig. Sei denn du willst, das jemand auch
begin result:= fFirstName; end;
Delphi-Quellcode:
machen kann, was ich softwaredesigntechnisch für eine absolute Katastrophe halte.
TFormAdresse= class(TForm, iAdresse)
Schon allein der Umstand, dass ein Property im Interface einen Getter in der implementierenden Klasse benötigt, reicht für mich aus, Interfaces ausschließlich nur da einzusetzen, wo es mit Vererbung und abstrakten Klassen keine Lösung gibt. einbeliebigername. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:59 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