Ich hab es in eine Klasse gepackt, da man dann in der Klasse die funktionen findet um Properties von der Klasse zu laden.
Ausserdem macht man dies nur für TGUI_Widget und die anderen Widgets bauen dann auf TGUI_Widget auf.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich würde gerne mal eine Antwort auf meine Frage haben. Sonst hätt ich das Bsp. nicht erstellen brauchen -.-

_________________
(\__/)
(='.'=)
(")_(")

Öhm, wenn ich noch zum Interface was sagen darf.

Man könnte zur Implementirung einer Schnittstelle abstrakte Basisklassen verwenden. Offenbar hat Tak das so gemacht. Der Unterschied zu Interfaces ist, wenn ich meine einschlägige Literatur dazu recht verstanden habe und auch Sidorion recht verstanden habe, dass die vom Interface abgeleiteten Objekte, welche die Schnittstellen mit Code füllen, untereinander kompatibel sind.

Es gibt aber auch die Möglichkeit, nicht das ganze Objekt aus einem bestimmten abstrakten Objekt abzuleiten, sondern ein Objekt/Interface "hinzuzumixen", entweder fix oder variabel:


Traude

@evil-devil,

Ich wills mal versuchen:

Als erstes definierst Du ein Interface namens Duft. Geht in Delphi.
Zweitens erzeugt Du eine abstrakte Klasse namens Pflanze. Geht in Delphi.
Drittens erzeugst Du eine Ableitung aus der Klasse Pflanze, namens Rose, die auch das Interface "Duft" hat. Geht auch.

Getränk = neue abstrakte Klasse. OK
Tee = Ableitung aus Getränk, implementiert Duft. OK

Jetzt implementierst Du eine Klasse "Dufttester".
Unter dem Kommentar "Per Instanzierung" steht Code, den ich jetzt so interpretiere:
Der Variablen "Duft" (ein Interface) weist Du die (neu erzeugten) Objekte Rose und Tee zu. Und nimmst sie auch gleich in Betrieb. Ich meine, das müsste gehen.

Ob der Code, der unter dem Kommentar "per Cast" steht, auch funktioniert, weiß ich nicht.
Traude

Ich interpretier das mal so:
((rose)Duft).Dufte ist ein Typcast der Variable Duft auf die Klasse Rose. Wenn ja, ginge das prinzipiell, aber in diesem Fall wirds nen Invalid Typcast geben, da in der Variable Duft eine Instanz des Typs Tee gespeichert ist, und diese beiden sind nicht zuweisungskompatibel.

@abstrakte Basisklassen: In Prinzip geht das, aber mann muss dann wissen, dass die klasse, die ich grad in der Hand habe, einen member vom Typ dieser abstrakten basisklasse hat. Dieses
Wissen brauche ich bei Interfaces nicht, da ich z.B.: ein ganz anderes Interface B in der Hand habe und dieses dann Fragen kann, ob die Klasse, die das Interface B hat auch das Interface A hat. Wenn ja, kann ich casten und davon ausgehen, dass die Methoden da sind.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

WIeso sollte das nicht gehen? Genau dies ist gerade der große Nutzen von Interfaces. Wäre schon komisch, wenn dies in Delphi nicht ginge aber alles andere dafür...

_________________
(\__/)
(='.'=)
(")_(")

Das wird auch in Java nicht gehen. Gibt ja keinen Grund warum Tee und Rose zuweisungskompatibel sein sollen. Rose könnte eine Methode implementiert die Tee nicht hat und die auch nicht im gemeinsamen Interface ist.

Bei der Verwendung von Interfaces ist es, wie Du schon sagtest, egal, welcher Klassentyp dahintersteckt. Aber wenn Du (in diesem Fall) nach Rose castest, ist der 'Quellvariablentyp' völlig schnuppe, es zählt nur der 'Quellinstanztyp'. Sprich in Deiner Variable Duft ist eine Instanz vom Typ Tee, aber Tee kann man nicht auf Rose Typcasten.
Man kann beide auf Duft casten und Duft wieder auf beide (jeweils wieder zurück), sogar ohne explizite Typconvertierung zuweisen, aber mann kann eben nicht Tee auf Rose zuweisen.

Das ist in diesem Fall sogar völlig unnötig, weil die Variable Duft hat doch schon die Methode Dufte. Da isses völlig egal, ob nun Tee duftet oder Rose.

das geht sogar noch weiter: Angenommen Tee hätte noch das Interface Geschmack. Dann könntest Du ((Geschmack)Duft).Schmecke rufen, aber auch hier würde die Typprüfung zuschlagen, wenn in der Variable Duft eine Rose drinsteckt, weil Rosen sind geschmacklos.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

@Exception: Ich geb mich geschlagen. Mein Bsp. war da unpassend. Dein Geschmack Bsp war da besser ^^. Aber es ist wohl klar worauf ich hinaus will. Interfaces machen einem vieles einfacher.

_________________
(\__/)
(='.'=)
(")_(")

Nagut. Aber ich hätte jetzt auch eine dringende anstehende Frage, weitaus nicht so kompliziert. Ich steh' vor dem Problem mit dem Aufrufen des User-Events. Das waren ursprünglich bei mir Methodenzeiger (wie in Delphi). Jemand hat eingeworfen: sollten aber Prozedurzeiger sein. Wünschenswert wäre beides. Sie sind aber nicht kompatibel. Wären Interfaces eine Lösung?

Nachtrag: Der Benutzer hängt einfach seine Ereignisbehandlung ins TGUIItem rein. Im GUIItem ist es ein (private) Methodenzeiger, der auf die Benutzermethode gesetzt wird. Die Zuweisung erfolgt per (published) Property.

Traude

Nein. Das Interface müsste ja wieder eine Klasse haben, bei der man es ruft.
Wenn, dann würde ich für jeden Event beide Varianten bereitstellen, sprich einen OnClick als Methode und einen als Prozedur. Beim Aufruf werden dann nacheinander beide gerufen.
Allerdings kann ich mir gut vorstellen, dass der jemand, der Prozedurzeiger schrieb, Methodenzeiger meinte. Sind ja beides Prozeduren, allerdings die eine 'of object' und die andere nicht.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Denke auch, das Prozedurenzeiger nicht benötigt werden. Da man ja objektorientiert programmiert werden die Ereignisroutinen vermutlich wie bei Delphi in einer Klasse sein.

Dieser Jemand war Tak.
Ich gaube nicht, dass er das verwechselt. Ich glaube, er hat explizit Prozedurzeiger gemeint, und er hat dafür bestimmt einen Grund. Ein Grund, der mir einfällt: die Vorgaben für die Objektorientierung gelten nur für dieses Projekt, aber nicht für die aufrufende Anwendung. Das heisst, beides implementieren. OK.

Tak, kannst Du das bestätigen?
Traude

Nochmal zum Verständnis von Interfaces:
Bei Objektorientierung interessiere ich mich nicht dafür, wie eine Klasse innen aufgebaut ist: Ich sehe von außen nur einen schwarzen Kasten. Allerdings muss es eine bestimmte Art Kasten sein (Rabe, Kohle, Onyx, Schornsteinfeger).
Bei Interfaces gehe ich noch einen Schritt weiter: Ich will nichtmal wissen, was es für ein Kasten ist, hauptsache er hat bestimmte Henkel dran. Und ein Interface ist sozusagen ein 'Henkelsatz' und wenn ein schwarzer kasten einen bestimmten Henkel hat, kann ich ihn da festhalten und schütteln.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Das Beispiel von Evil war ja gar nicht so schlecht gewählt. Man könnte sich ja überlegen, ob ein Interface wohl für die Rolle des Datenproviders in Frage kommt.