Interfaces + Factorys

[Jumpy]

Zitat von Dejan Vu:

PS: Was der TRoutedStreamHandler macht, erschließt sich mir auch nicht.

Ich habe das so verstanden, dass TRoutedStreamHandler "entscheidet" welcher der tatsächlichen anderen Handler-Klassen (die ihm im OnCreate eingeflöst werden) die Anfrage nun bearbeitet. Wäre aber nett zu sehen, wie es bei ihm im Inneren aussieht, denn auch wenn ich glaube verstanden zu haben was er macht, weiß ich nicht wie.

[Stevie]

Zitat von Jumpy:

wie es bei ihm im Inneren aussieht

Genau das ist der Punkt, wenn man mit Interfaces arbeitet.
Sofern man sich an die Regeln hält, dass die Implementierungen der Interfaces sich gemäß der Spezifikationen verhalten, ist es unerheblich, was sie intern machen.

[stahli]

Ja gut, aber das kann auch auf eine einfache Klasse oder Prozedur zutreffen:

Delphi-Quellcode:

procedure LiesDatenEin(Param: Integer);
begin
  case ParamOderRechteOderIrgendwas of
    1: LiesXML;
    2: LiesCSV;
    3: LiesWWW;
  end;
end;

Hier ist es für die Benutzung der Prozedur auch unerheblich, was sie intern macht.

Solche Beispiele finde ich daher ungünstigt, da sie den zu erklärenden Sachverhalt nicht herausgelöst von anderen/allgemeineren Aspekten auf den Punkt bringen.

[Stevie]

Zitat von stahli:

Ja gut, aber das kann auch auf eine einfache Klasse oder Prozedur zutreffen:

Delphi-Quellcode:

procedure LiesDatenEin(Param: Integer);
begin
  case ParamOderRechteOderIrgendwas of
    1: LiesXML;
    2: LiesCSV;
    3: LiesWWW;
  end;
end;

Hier ist es für die Benutzung der Prozedur auch unerheblich, was sie intern macht.

Nicht ganz richtig - in deinem Beispiel ergibt sich aus dem übergebenen Parameter, was sie intern tut.
Bei einem Interface sollte bei einem IKannFliegen.Flieg immer klar sein, was diese Methode macht.
Dementsprechend ist für den Aufrufer der Methode egal, obs durch Flügelschlagen oder Nachbrenner zünden passiert - hauptsache das Ding fliegt.

Wenn man sich nicht drauf einlässt, dass ein Interface (genau wie eine abstrakte Klasse) eine Abstraktion ist - kann man die Geschichte mit den Interfaces auch gleich wieder vergessen.

[DeddyH]

Vielleicht sollte man Interface einmal definieren (falls ich hier Mist schreibe, möge man mich bitte korrigieren): es handelt sich dabei lediglich um eine Vereinbarung, d.h. hinter so einer Interface-Variablen steckt letzten Endes irgendetwas, was die im Interface deklarierten Methoden und Eigenschaften aufweist. Worum es sich dabei konkret handelt (TDings, TBums oder TWuppdi) spielt überhaupt keine Rolle. Das ist somit noch etwas abstrakter als eine abstrakte Klasse, denn dort weiß ich zumindest, dass es sich um eine Ableitung davon handeln muss. Bei Verwendung von Interfaces hingegen muss keine Klassenhierarchie eingehalten, sondern sie können auf einer beliebigen Vererbungsebene implementiert werden.

[Jumpy]

Zitat von Stevie:

Zitat von Jumpy:

wie es bei ihm im Inneren aussieht

Genau das ist der Punkt, wenn man mit Interfaces arbeitet.
Sofern man sich an die Regeln hält, dass die Implementierungen der Interfaces sich gemäß der Spezifikationen verhalten, ist es unerheblich, was sie intern machen.

Bei den Interfaces ja, aber bei den Klassen die diese implementieren ist dies dann aber doch interessant, wenn man was lernen will, wie ich in dem Fall. Schließlich kommen diese Klassen ja nicht einfach aus dem Nirgendwo, nur weil ich ein Interface erstellt habe. Gerade in den Klassen wird doch dann die eigentliche "Arbeit" gemacht.

[Stevie]

Zitat von Jumpy:

Bei den Interfaces ja, aber bei den Klassen die diese implementieren ist dies dann aber doch interessant, wenn man was lernen will, wie ich in dem Fall. Schließlich kommen diese Klassen ja nicht einfach aus dem Nirgendwo, nur weil ich ein Interface erstellt habe. Gerade in den Klassen wird doch dann die eigentliche "Arbeit" gemacht.

Schon, ist aber für die Thematik hier (Interfaces und Factories) irrelevant.
Denn wie DeddyH korrekt angemerkt hat, handelt es sich bei den Interfaces um Vereinbarungen, dass das Dings dahinter etwas bestimmtes macht.
So wie aus ner Steckdose Strom kommt, ob der aus Wind, Sonne, Wasser, Kohle oder Kernkraft gewonnen wird,
ist für die Funktion des Geräts, was du anschließt nicht ausschlaggebend.

Ich erwähne das, weil es im Umgang mit Interfaces wichtig ist, sich nicht auf irgendwelche Implementierungsdetails zu verlassen.

[Daniel]

Zitat von Stevie:

Ich erwähne das, weil es im Umgang mit Interfaces wichtig ist, sich nicht auf irgendwelche Implementierungsdetails zu verlassen.

Klar, sehe ich auch als wichtig an. Dennoch: Gerade als Einsteiger fragt man sich schon - und völlig zurecht - wo denn am Ende die Arbeit getan wird, wie man also dann die jeweiligen Klassen implementiert. Und auch das gehört zu einem Einstieg in Interfaces.

[Stevie]

Zitat von Daniel:

Zitat von Stevie:

Ich erwähne das, weil es im Umgang mit Interfaces wichtig ist, sich nicht auf irgendwelche Implementierungsdetails zu verlassen.

Klar, sehe ich auch als wichtig an. Dennoch: Gerade als Einsteiger fragt man sich schon - und völlig zurecht - wo denn am Ende die Arbeit getan wird, wie man also dann die jeweiligen Klassen implementiert. Und auch das gehört zu einem Einstieg in Interfaces.

Das ist aber mMn schon in den Videos von Stahli erklärt worden - die Implementierung des TRoutedStreamHandler würd ich nich gerade ins Interfaces 101 packen
Das zu erklären wäre - um bei dem Beispiel von der Steckdose zu bleiben - so, als ob ich jemandem der nen Haushaltsgerät an ne Steckdose anschließt, erklären müsste, wie nen Atomkraftwerk funktioniert

[Sailor]

Die wesentliche Grundidee der Objektorientierung ist Information Hiding,
auch Datenkapselung genannt. Der Nutzer soll nur gewisse Gebrauchswerte
kennen, die er ausschließlich verwendet. Er weiß über den internen Ablauf nichts.
Beispiel Tabelle: Die Nutzerfunktionen seien Eintragen eines Elementes und Abfragen,
ob ein Item Element der Tabelle ist. Je nach Anwendungsfall kann das nun unterschiedlich
implementiert werden, als lineare Liste, als Hashtabelle, als Datenbank etc.
Zumindest in dieser Hinsicht ist Delphi keine objektorientierte Sprache,
so wie auch C# und insbesondere Java das nicht sind.
In dem hier verwendeten Kontext sind Interfaces nun die Krücke, mit der versucht wird,
das nachträglich in Delphi hinzubekommen. Das geht aber nur auf der syntaktischen
Ebene, denn es gibt in diesen Sprachen keinerlei Mittel, mit denen man die Semantik
auf der abstrakten oder Nutzerebene ausdrücken kann. Die Benennung einer Prozedur
als "Flieg" hindert doch niemanden daran, die als "Schwimm" zu implementieren. Um auf
das oben angedeutete Beispiel zurückzukommen: Was passiert, wenn ein Element
mehrfach eingetragen wird? Ist es dann nur einmal drin? Wie reagiert die Funktion Abfragen,
wenn das Element nicht in der Tabelle vorhanden ist? Ohne Einsicht in die Implementierung
lassen sich diese Informationen nicht gewinnen. Man kann durch die Verwendung von Interfaces
oder abstrakter Klassen sicher einiges entkoppeln, aber letztendlich bleibt der Einblick in das
Innere einer Klasse unverzichtbar, wenn man in Delphi & Konsorten programmiert, leider.