Interfaces + Factorys

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

[Jumpy]

Zitat von stahli:

@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 von Sailor:

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*