Interfaces + Factorys

[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:

Zitat von stahli (Beitrag 1288548)

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:

Zitat von Stevie (Beitrag 1288540)

Zitat:

Zitat von Jumpy (Beitrag 1288539)

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:

Zitat von Jumpy (Beitrag 1288602)

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:

Zitat von Stevie (Beitrag 1288610)

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.

[stahli]

@DeddyH
Würde ich zustimmen.

@Jumpy
Wie die Klassen aussehen, ist hier m.E. gar nicht so wichtig.
Wichtig ist, dass es eine abstrakte Schnittstelle gibt, die dann mit mehreren Varianten erledigt werden kann.
In einer Prozedur würde ich eine Fallentscheidung vielleicht nach den vergebenen Nutzerrechten oder der Mondphase treffen (das meinte ich mit meinem case-Beispiel) und bei der Arbeit mit Interfaces würde man seiner Interfacevariable einfach einer Instanz der Klasse A, B, oder C übergeben.
Die Interface-Lösung ist eleganter und flexibler, macht aber letztlich das Gleiche, nämlich ermöglicht es, eine Aufgabe mit unterschiedlichen Codestücken zu erledigen.

@Daniel
Ok, ich dachte, das wäre bei meinen Erklärungen ausreichend klar geworden.
(Ist schon schwierig, hier alle auf einen Nenner zu kriegen ;-))

@all
Sir Rufos Beispiel war ja grundsätzlich zutreffend. Ich fand es nur zu detailliert, um das Wesentliche hervozuhen. Und dieser Code zum Schluss ist (für mich) nicht nachvollziehbar und hat wohl erst die Verwirrung verursacht.

[Stevie]

Zitat:

Zitat von Daniel (Beitrag 1288611)

Zitat:

Zitat von Stevie (Beitrag 1288610)

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.

[stahli]

Ja, das stimmt absolut.
Und genau darauf wollte ich hier hinaus: WIE genau "Flieg" oder "GetData" in den Klassen genau realisiert werden kann, sollte hier nicht unbedingt besprochen werden.
DASS das natürlich aber in den Klassen gelöst werden muss (und nicht in der Schnittstelle) ist natürlich richtig.

[mjustin]

Zitat:

Zitat von Sailor (Beitrag 1288616)

... ist Delphi keine objektorientierte Sprache,
so wie auch C# und insbesondere Java das nicht sind.

Dem ist wohl nichts hinzuzufügen. In diesem Kontext steht die Programmierung
in Delphi, Java und C# dem direkten Schreiben von Maschinencode näher als
echte Hochsprachen wie zum Beispiel Assembler, oder dem seit jeher bewährten
copy con > programm.exe.
:cheers:

[Dejan Vu]

Zitat:

Zitat von Sailor (Beitrag 1288616)

...
Zumindest in dieser Hinsicht ist Delphi keine objektorientierte Sprache,
so wie auch C# und insbesondere Java das nicht sind.
...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.

Welche Programmiersprachen sind dann objektorientiert? Bei welcher Programmiersprache erkenne ich die komplette Spezifikation, ohne die Spezifikation zu lesen?

In einem normalen Kaufvertrag steht doch auch nicht, ob ich eins auffe Fresse kriege oder eine kolumbianische Krawatte bekomme, wenn ich nicht zahle. Es geht bei einem Vertrag doch gerade nicht um das Verhalten der Klassen/Objekte, sondern um die Interaktion. Oder willst Du das Verhalten eines Vertrages gleich mit deklarieren? Das wäre natürlich ein interessanter Ansatz. Wo gibt es das? Oder meinst Du aspektorientierte Programmierung sei ein Schritt in diese Richtung?

[Jumpy]

Zitat:

Zitat von stahli (Beitrag 1288613)

@all
Sir Rufos Beispiel war ja grundsätzlich zutreffend. Ich fand es nur zu detailliert, um das Wesentliche hervozuhen. Und dieser Code zum Schluss ist (für mich) nicht nachvollziehbar und hat wohl erst die Verwirrung verursacht.

Dann ziehe ich meine Frage nach der Implementierung des TRoutedStreamHandler als OT zurück. Vielleicht hat Sir Rufo oder jemand anders ja Lust das in einem fortgeschrittenen Thread zu erläutern. Der Threadtitel hier heißt ja Interfaces + Factories und die Idee hinter dem TRoutedStreamHandler ist ja wie ich das verstehe eine alternative zu einer Factory(klasse/methode), welche einem die für eine Aufgabe passende Klasse erzeugt und auf das Interface liefert. Stattdessen werden ja scheinbar alle Möglichen Klassen für das Interface erzeugt und innerhalb von TRoutedStreamHandler verwaltet.

[Sailor]

@Dejan Vu

Zitat:

Welche Programmiersprachen sind dann objektorientiert? Bei welcher Programmiersprache erkenne ich die komplette Spezifikation, ohne die Spezifikation zu lesen?

Bei keiner. Deshalb ist der Ansatz über Interfaces bestenfalls der erste Schritt in die richtige Richtung. Der müßte aufgebohrt werden:
1. Welche Bedingungen müssen die Parameter (nicht 0, nicht NIL, x < y usw.) einer Prozedur/Funktion erfüllen?
2. Was macht die Funktion/Prozedur? Aber ohne auf die Implementierung einzugehen. Da gibt es einige Ansätze, nur sind die eben sehr mathematisch und so schlecht unter die Masse zu bringen. Vielleicht läßt sich da etwas mit dem Gherkin/Cucumber approach machen.
Und dann gibt es noch die Möglichkeit, auf die operationale Programmierung zu verzichten und lokale, mathematisch fundierte, das aber gut versteckende Theorien zu benutzen. Beispiel Grammatiken: Mit wenigen Zeilen beschreibst Du eine komplexe Aufgabe. Dann ein Klick und Du hast ein ausführbares Programm. Letzteres ist entscheidend. Wenn ich eine solche Beschreibung zu Fuß in ein Programm umwandeln muß, ist sie nutzlos. Leider hat sich das bis zu den Theoretikern noch nicht rumgesprochen.
Irgendwas wird sich tun müssen. Die Hartware hat riesige Fortschritte gemacht, aber die Weichware wird zum großen Teil immer noch wie anno dunnemals hergestellt. Na ja, ist wohl nun ziemlich OT.

[stahli]

[OT]
Ja das ist schon mehr als OT ;-)
Aber die Idee ist nicht uninteressant - wobei mein Ansatz ein anderer wäre.
Wenn Deine Profilangaben ernst zu nehmen sind, dann scheinst Du Dich ja in dem Bereich auszukennen.
Für weiterführende Diskussionen sollte man das aber mal aus dem Thread hier heraus ziehen...
[/OT]

[Dejan Vu]

Zitat:

Zitat von Sailor (Beitrag 1288748)

Bei keiner. Deshalb ist der Ansatz über Interfaces bestenfalls der erste Schritt in die richtige Richtung. Der müßte aufgebohrt werden:
1. Welche Bedingungen müssen die Parameter (nicht 0, nicht NIL, x < y usw.) einer Prozedur/Funktion erfüllen?

Das ist, soweit ich mich erinnere, ein Ansatz, er vor 40 Jahren aufgegeben wurde. Ich kann mich dunkel an Ansätze dieser Art erinnern. In Ansätzen ist er jedoch mit den Schrottsprachen C# und Delphi (und den ganzen anderen Müll) über Attribute abzubilden und ein alter Hut.

Den Rest (also die mathematische Formulierung, das Kalkül, oder?) hatte ich im Studium in den 80er Jahren. Da wurde das mal versucht aber aufgegeben, da die beiden einzigen, die das weltweit verstanden haben, sich nicht mehr leiden konnten.

Insofern ist dein Einwand, das Delphi, C#, Java keine objektorientierten Sprachen seien, ziemlicher Quark, findest du nicht auch? Genauso könnte ich ja sagen, das das noch nicht mal Sprachen seien, also richtige Sprachen, richtig tolle, mit denen man richtig programmieren kann. Ich hab zwar auch keine Ahnung, wie eine richtige Sprache dann aussehen soll, aber 'NEIN!1!11' kann man schon mal präventiv sagen. Schadet ja nichts.

*Kopfschüttel*

[stahli]

Noch eine kleine Überlegung zu Properties...

Es wäre m.E. sehr hilfreich und der Übersichtlichkeit dienlich, wenn man die Getter und Setter im Interface nicht komplett definieren müsste:

Delphi-Quellcode:

  IFlieg = interface
     ['{0E839812-DAB3-47F0-AF3E-AB05FFDD6CE6}']
     procedure Flieg;
     // function get_X: Integer;
     // procedure set_X(Value: Integer);
     property X: Integer read write; // read get_X write set_X;
   end;
 
  TVogel = class(TInterfacedObject, IFlieg)
   private
     fX: Integer;
     function get_X: Integer;
     procedure set_X(Value: Integer);
   public
     procedure Flieg;
     property X: Integer read get_X write set_X;
   end;

Dann würde im Interface nur vorgegeben, DASS es eine Property mit Getter und/oder Setter geben muss und in der Klasse werden die Details geregelt.

Die Funktionalität der Interfaces müsste ja nicht verändert werden. Lediglich der Parser müsste das Konstrukt akzeptieren und der Compiler daraus alles ganz normal wie gehabt zusammenbauen.

Ich würde dies für eine nützliche Vereinfachung halten.


PS: Eine ShortKey für das Vervollständigen eines Klassenrumpfes mit den notwendigen Interface-Methoden gibt es nicht oder? (Ich meine: Taste drücken und der Klasse werden alle fehlenden Methoden der verwendeten Interfaces eingebaut)

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1290633)

PS: Eine ShortKey für das Vervollständigen eines Klassenrumpfes mit den notwendigen Interface-Methoden gibt es nicht oder? (Ich meine: Taste drücken und der Klasse werden alle fehlenden Methoden der verwendeten Interfaces eingebaut)

Fast! Wenn du in der Klassendefinition die Code-Vervollständigung mit <Ctrl>-<Space> aufrufst, zeigt Delphi dir die fehlenden Interfacemethoden an. Die kannst du dann alle markieren und mit <Enter> werden die Deklarationen erzeugt. Der Rest geht mit der Klassenvervollständigung <Ctrl>-<Shift>-C dann wie üblich.

[stahli]

Ja danke, das hilft schon mal wenigstens etwas...

[Sir Rufo]

Zitat:

Zitat von stahli (Beitrag 1290809)

Ja danke, das hilft schon mal wenigstens etwas...

Diese Shortcuts sollten aber bekannt sein, denn damit kann man nicht nur die Interface-Methoden ratzfatz implementieren, sondern auch die virtuellen Methoden vom Klassenvorfahr (und denen davor ...).

Auch noch hübsch mit override gekennzeichnet und auch im gleichen Sichtbarkeitsbereich (private, protected, ...). Bis auf die Properties, die wandern in den published Teil.

[stahli]

[OT]
Ctrl+Space kenne ich schon ;-)
Benutzte das bereits erfolgreich zur Codevervollständigung. :-)

Ich hatte das natürlich auch im Klassenrumpf versucht.
Irgendwie führte das aber nicht zum Erfolg - hatte ich sicher irgendwas falsch gemacht oder interpretiert.

Jedenfalls funktioniert es jetzt - wobei ich es noch nicht als optimale Lösung ansehen würde.
[/OT

[Sir Rufo]

Bei Überladungen hat das auch seine Probleme und sobald ein generisches Interface ins Spiel kommt ist eh komplett Schluss mit Lustig.

[stahli]

Ah, ich habe gerade festgestellt: Der Cursor darf nicht hinter einem // stehen.
Vielleicht war das bei meinem Test das Problem.