Interfaces + Factorys

[OlafSt]

Ihr seht ja selbst, wohin das führt. Ich als jemand, der man gerade eben geschnallt hat, wie das überhaupt funktioniert (bin noch immer erstaunt, das ich einen Klassenkonstruktor aufrufe, aber ein Interface bekomme), wird hier mit 3 Posts bereits total überfordert.

Spring4D ? Dependency Injection ?

Zitat:

Jetzt kann ich entweder per Programmlogik das Interface nicht am Pool registrieren

Wat fürn Pool denn ? Und was ist GlobalClassManager ? F1 bringt da nix zutage... Natürlich kann ich Google quälen, doch die Ergebnisse, die man dabei präsentiert bekommt, sind einfach vier Hausnummern zu hoch.

Versteht ihr ? Ihr redet hier von Dingen, die im 8. oder 9. oder auch erst 28. Schritt interessant werden. An die Leute, die die anderen 7,8,27 Schritte noch nicht gemacht haben, denkt ihr dabei nicht. Das ist vergleichbar mit dem Lerneffekt, den man hat, wenn man einem Anfänger, der gerade kapiert hat, was eine Schleife ist, versucht eine doppelt verkettete Liste zu erklären. Kann er nicht kapieren, weil zwischen "gerade Schleife verstanden" und "Zeiger auf Objekte" noch ein paar Schritte liegen, die man einfach nicht überspringen kann.

Ergo: Auf genau diese Leute, die ein paar Schritte noch nicht gemacht haben, auf diese zielt Stahli mit seinen drei Videos. Und ich bin ausgesprochen neugierig, wie das wohl weitergeht. Besonders spannend ist es doch, wenn wir an das Thema Daten herankommen.

Ich denke da noch immer an meine Dekoder-Klassen. Spätestend, wenn ich denen irgendeinen Binärkrams zu futtern gegeben habe und die dekodierten Daten bereitstehen, muß ich da ran. Geht sowas und wenn ja, wie ? Und irgendwann sind wir dann so weit, das wir sowas in eine DLL stopfen. Und noch etwa später soweit, das wir diese DLL auch mit C# in .NET-Umgebungen benutzen können.

Meinetwegen dürfen das gerne weiter Enten und Adler und Boote sein - ob diese Art Klassen Sinn machen oder nicht, ist für das Tutorial und das Verstehen echt sensationell unwichtig, solange man die Mechanik kapiert.

[stahli]

Hallo Olaf, freut mich, dass sich noch jemand auf meiner Ebene herum treibt... :-)

Ich will mal noch ein paar Dinge aufgreifen:


@alda

Die Testbarkeit von Klassen wird durch Interfaces erleichtert und eigentlich erst richtig ermöglicht. Das habe ich verstanden.
Man kann also echte Funktionalitäten (z.B. komplizierte Berechnungen oder Datenbeschaffungen) mal schnell durch eine Dummyklasse ersetzen, die mal schnell ein paar statische Testdaten bereitstellt.
Wenn die echte Klasse und die Dummyklasse die gleiche benötigte Schnittstelle unterstützen kann man sie ja einfach mal schnell austauschen.

IDateninterface := TEchteKlasse.Create;
oder
IDateninterface := TDummyKlasse.Create;

Ansonsten funktioniert alles andere unverändert.
Mehr als diese grobe Zusammenfassung kenne ich selbst aber nicht.


@Mavarik
Du hast Recht mit Deiner Bemerkung zur Alternative "Basisklasse".
In meinem ersten Videoversuch bin ich darauf auch noch eingegangen (den habe ich aber aus bestimmten Gründen entsorgt ;-)) und im zweiten habe ich das dann vergessen. Aber zumindest habe ich ja erläutert, dass beide Klassen unabhängig voneinander sind. Das Beispiel bezieht sich also auf Fälle, wo es keine gemeinsame Basisklasse gibt.


@OlafSt

Also auf die Daten bin ich nur aus Zeitgründen nicht eingegangen (und weil ich es schon für so logisch und normal hielt ;-))
Propertys, Getter und Setter definiert man im Interface genau so wie in der Klasse (man muss aber alles komplett definieren - es reicht also nicht, nur "property Value: Integer;" zu schreiben und in der Klasse dann zusätzlich Getter und Setter zuzuweisen).
In der Klasse wird dann natürlich i.d.R. noch ein privates Feld "fValue: Integer" eingeführt, wovon das Interface nichts weiß und nichts wissen soll.
Auf den Wert kannst Du dann ganz normal über IMyInterface.Value zugreifen. Der tatsächliche Speicherung des Wertes in fValue oder im Internet oder einer Datenbank regelt dann (im Verborgenen die Klasse).
Das ist gerade ein schönes Beispiel für den Testfall oben: Die echte Klasse holt den Wert vielleicht aufwendig aus dem Internet und eine vorläufige Testklasse liefert ihn vorläufig mal schnell eben statisch zurück.

Mit dem Einbinden von DLL´s habe ich mich noch nicht befasst. Aber wenn man das tut und z.B. einer Schnittstelle IXyz benutzt (mit einer zugewiesenen GUID) dann könnte in der DLL auch eine Klasse mit dieser Schnittstelle (gleiche GUID) bereitgestellt und vom Projekt benutzt werden.
Heute haben wir TVerbrennungsmotor und TElektromotor und in 5 Jahren kann dem Projekt von außen noch ein TWarpAntrieb bereitgestellt werden wenn er die gleiche Schnittstelle implementiert.
Ich kenne das aber auch nur bis hierher und näheres weiß ich nicht - auch nicht, ob Delphi-Schnittstellen irgendwie von .NET verwendet werden können (oder anders rum).


@all: Mehrfachvererbung und Interfaces

Falls jemand einen Account bei Video2Brain hat oder sonst an das Video kommt möchte ich https://www.video2brain.com/de/video...rosse-training von Mirko Matytschak empfehlen.
Das Tutorial betrifft zwar C# aber die Beiträge
- Mehrfachvererbung und
- Schnittstellen
sind sehr allgemein gehalten und sehr informativ.

[stahli]

Mal noch ein Versuch, die Beziehung Objekt <-> Schnittstellen zu verbildlichen:

- es wird immer zunächst ein OBJEKT erzeugt
- es wird auch immer mit dem (allerdings nicht komplett sichtbaren) OBJEKT gearbeitet
- das Objekt kann mehrere Interfaces implementieren
- alle Interfaces sind Teil des Objektes.
- entsprechend können die Interfaces auch auf die privaten Bereiche und Daten des Objektes zugreifen

- eigentlich SIND die Interfaces das Objekt
- man kann das als eine Art casting ansehen: z.B. SchnittstelleA(Objekt), SchnittstelleB(Objekt) oder SchnittstelleC(Objekt)

- somit kann man ermitteln, ob Objekt InterfaceA implementiert oder das InterfaceC das InterfaceB
- entsprechend kann man dann auch das Interface(Objekt) in InterfaceA casten oder das InterfaceC in InterfaceB

- immer wenn eine Schnittstelle verwendet wird, ist damit letztlich das Objekt dahinter genutzt, aber mit einer Art Maskierung

Bei TInterfacedObject-Ableitungen kommt noch hinzu, dass der Compiler bei jeder ObjektAlsInterfaceX-Verwendung einen Zähler hochzählt (im Bild 1..5) und beim verlassen des Scopes oder Zuweisung eines anderen Objektes (oder NIL) an die Interface-Variable den Zähler wieder verringert. Kommt der Zähler bei 0 an, wird das Objekt freigegeben.

Bei Benutzung eines Interfaces benutzt man also das Objekt, jedoch mit einer eingeschränkten Sicht und einer etwas anderen Verhaltensweise.

Wegen dieser automatischen Referenzzählung und der automatischen Freigabe des Objektes bei "Zähler = 0" sollte man unbedingt vermeiden, das Objekt mal als Objekt und mal als Interface zu benutzten. Auch die Lebenszeitverwaltung über einen Owner wäre fatal.
Entweder das Objekt ganz normal verwenden und dieses später freigeben oder dieses nach dem Create nur noch über Interfaces nutzen und den Lebenszyklus automatisch regeln lassen.


Olaf, entschärft das die Mystik etwas?

[Harry Stahl]

Also mir haben die Videos gefallen, ich finde das ist ein guter Einstieg ins Thema. Sicher kann man noch mehr mit Interfaces machen, aber wenn man da direkt die komplexen Sachen mit erklären würde, wäre es eben kein Einstieg mehr.

Jedenfalls wurden grundlegende Funktionalitäten gut und nachvollziehbar dargestellt. Da ich selber weiß, wieviel Arbeit mit solchen Videos vebunden ist, kann ich nur sagen, vielen Dank Stahli.

Freut mich zudem, das Delphi auch noch weiterhin ein Thema für Dich ist.
:thumb::thumb:

[OlafSt]

Zitat:

Zitat von stahli (Beitrag 1288382)

Hallo Olaf, freut mich, dass sich noch jemand auf meiner Ebene herum treibt... :-)

ich schätze mal, in Sachen Interfaces bin ich kaum vom Boden hochgekommen ;) Aber ich lerne gern und schnell dazu.

Zitat:

Also auf die Daten bin ich nur aus Zeitgründen nicht eingegangen (und weil ich es schon für so logisch und normal hielt ;-))
Propertys, Getter und Setter definiert man im Interface genau so wie in der Klasse (man muss aber alles komplett definieren - es reicht also nicht, nur "property Value: Integer;" zu schreiben und in der Klasse dann zusätzlich Getter und Setter zuzuweisen).

Ich habe mal etwas gegoogelt und bin über einen alten Thread gestolpert. Da gehts dann so:

Delphi-Quellcode:

type
  ITest = interface
    function GetMyProp: Integer;
    procedure SetMyProp(Value: Integer);
    property MyProp: Integer read GetProp write SetProp;
  end;

Nun, in obigem Interface sind nun logischerweise Getter (GetMyProp), Setter (SetMyProp) und das Property selbst

Delphi-Quellcode:

public

. Ich kann die Methoden nicht verstecken, ergo können sie direkt aufgerufen werden. Wozu sind dann Properties überhaupt sinnvoll in Interfaces ? Darüber nachgedacht ist die Frage vermutlich genauso sinnvoll wie die Frage "Was war vor dem Urknall"... Aber lassen wir die Fachleute sprechen.

Zitat:

Mit dem Einbinden von DLL´s habe ich mich noch nicht befasst.

Dann hau mal rein n Schlag ;) Programmierer lernen nie aus ;)

[Dejan Vu]

Zitat:

Zitat von OlafSt (Beitrag 1288393)

Nun, in obigem Interface sind nun logischerweise Getter (GetMyProp), Setter (SetMyProp) und das Property selbst

Delphi-Quellcode:

public

. Ich kann die Methoden nicht verstecken,

Doch. :mrgreen: Machs einfach.

[stahli]

Zitat:

Zitat von OlafSt (Beitrag 1288393)

Nun, in obigem Interface sind nun logischerweise Getter (GetMyProp), Setter (SetMyProp) und das Property selbst

Delphi-Quellcode:

public

. Ich kann die Methoden nicht verstecken, ergo können sie direkt aufgerufen werden. Wozu sind dann Properties überhaupt sinnvoll in Interfaces ?

Ich würde es so zusammenfassen: Die Klasse muss Getter und Setter haben, die müssen aber nicht öffentlich sein.
Bei Benutzung des Interfaces ist dann nur das Property erreichbar.

Ich bin darüber auch immer etwas stutzig geworden weil ja das Interface dann ggf. doch nicht vollständig benutzbar ist. Aber letztlich ist das ganz gut so.

Man muss halt schauen, dass die Klasse alle notwendigen Methoden auch wirklich öffentlich macht.


KORREKTUR:

Ich habe eben gesehen, dass meine Vögel die Methode FLIEG öffentlich deklariert haben, die Ente SCHWIMM aber versehentlich privat (hatte ich einfach nicht aufgepasst).
Benutzen konnte ich aber dennoch beide Methoden. Lediglich die Codevervollständigung hat die private Methode nicht angezeigt.
Also wären die Getter und Setter wohl auch erreichbar, aber nicht so ganz offensichtlich.

[Sir Rufo]

Nur mal so zum Nachdenken:

Ich habe eine

Delphi-Quellcode:

public

Property wo der Getter und Setter jeweils

Delphi-Quellcode:

private

deklariert sind.

Kann man dort eigentlich wirklich von

Delphi-Quellcode:

private

sprechen, denn der Zugriff ist eben über die Property direkt möglich. Ist es nicht eher aus kosmetischen Gründen so gedacht, diese Getter/Setter als

Delphi-Quellcode:

private

zu deklarieren, damit ich in der Codevervollständigung nicht das hier sehe

Delphi-Quellcode:

.Foo
.GetFoo
.SetFoo

Und was passiert bei einem Interface? Exakt das Gleiche, da werden die Getter/Setter nicht angezeigt. In der Codevervollständigung wird mir ausschließlich die Eigenschaft angezeigt, die Getter/Setter sind nicht direkt erreichbar.

[DeddyH]

IIRC stimmt das so nicht ganz. Wenn man das Interface nutzt, zeigt zwar die Codevervollständigung Getter und Setter nicht an, sie lassen sich aber trotzdem direkt aufrufen. Das ist zwar Quark, aber wohl nicht zu ändern.

[stahli]

Ihr habt beide Recht. Habe ich gerade auch noch festgestellt und korrigiert.