AW: Schon wieder: Warum Interfaces
Zitat:
|
AW: Schon wieder: Warum Interfaces
@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:
angeben müsste (wobei "read write" auch Standard sein, also weggelassen werden könnte)
IMyIntf = Interface
property MyProp: Integer read write; end; Dann könnte man in der Klasse
Delphi-Quellcode:
oder auch Getter und Setter verwenden.
TMyClass = class(TInterfacedObject, IMyIntf)
... property MyProp: Integer read fMyProp write fMyProp; end; 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. |
AW: Schon wieder: Warum Interfaces
Hallo,
Zitat:
Zitat:
Zitat:
Zitat:
Delphi-Quellcode:
iMyInterface
property ReadWritProp: Integer; property ReadonlyProp: Integer readonly; Zitat:
einbeliebigername. |
AW: Schon wieder: Warum Interfaces
Ja, so kann ich mich dem anschließen. :thumb:
|
AW: Schon wieder: Warum Interfaces
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 :) |
AW: Schon wieder: Warum Interfaces
Zitat:
Zitat:
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. |
AW: Schon wieder: Warum Interfaces
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. |
AW: Schon wieder: Warum Interfaces
Zitat:
Interfaces sind ein eigenständiges Konzept, das auf der OOP aufbaut :) Ansonsten kann ich mich deinem Post nur anschließen frapo. Zitat:
davon, das das nix mit dem Interface-Konzept etwas zu tun hat. |
AW: Schon wieder: Warum Interfaces
Zitat:
Zitat:
Zitat:
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:
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. |
AW: Schon wieder: Warum Interfaces
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:49 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