AW: Interfaces + Factorys
Zitat:
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: |
AW: Interfaces + Factorys
Zitat:
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? |
AW: Interfaces + Factorys
Zitat:
|
AW: Interfaces + Factorys
@Dejan Vu
Zitat:
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. |
AW: Interfaces + Factorys
[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] |
AW: Interfaces + Factorys
Zitat:
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* |
AW: Interfaces + Factorys
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:
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.
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; 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) |
AW: Interfaces + Factorys
Zitat:
|
AW: Interfaces + Factorys
Ja danke, das hilft schon mal wenigstens etwas...
|
AW: Interfaces + Factorys
Zitat:
Auch noch hübsch mit override gekennzeichnet und auch im gleichen Sichtbarkeitsbereich (private, protected, ...). Bis auf die Properties, die wandern in den published Teil. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:58 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