Interface und Objektreferenz offenbar noch nicht verstanden

[Hepdepaddel]

Und an alle: Besten Dank!

[TiGü]

Zitat von Hepdepaddel:

Delphi-Quellcode:

procedure Tfrm_Main.UpdateStatusBar;
var
  Summary: IPlanDataEnumerator;
begin
  Summary:=TMySummary.Create;
  TMySummary(Summary).Init;
  ProjectData.CallEnumeratorForAllElements(Summary);
  StatusBar.Panels[1].Text:='Unassigned Order Packages: '+IntToStr(TMySummary(Summary).CountUnassignedOrderPackages);
  StatusBar.Panels[2].Text:='Unassigned Orders: '+IntToStr(TMySummary(Summary).CountUnassignedOrders);
end;

Warum machst du das jetzt so?
Das harte casten auf die Klasse ist suboptimal.
Wenn du möchtest, dass ein klarer(er) Bezug zu IPlanDataEnumerator besteht kannst du es auch so schreiben:

Delphi-Quellcode:

procedure Tfrm_Main.UpdateStatusBar;
var
  Summary: ISummary;
begin
  Summary:=TMySummary.Create;
  Summary.Init;
  ProjectData.CallEnumeratorForAllElements(Summary as IPlanDataEnumerator ); // <<<<< Hier wird ISummary als IPlanDataEnumerator übergeben
  StatusBar.Panels[1].Text:='Unassigned Order Packages: '+IntToStr(Round(Summary.GetSummaryResult));
end;

[Hepdepaddel]

Zitat von TiGü:

Warum machst du das jetzt so?
Das harte casten auf die Klasse ist suboptimal.

Entschuldige die späte Antwort - jetzt habe ich den Kopf wieder etwas frei.

Warum mache ich das... gute Frage. Das Problem ist, dass TMySummary eben ein umfangreiches Objekt ist, das mehrere unterschiedliche Interfaces implementieren sollte. Ich bin schon unglücklich, es als IPlanDataEnumerator zu deklarieren. Eigentlich müsste es heißen

Delphi-Quellcode:

var
  Summary: TMySummary;
begin
  Summary:=TMySummary.Create;
  Summary.Init;
  ProjectData.CallEnumeratorForAllElements(Summary as IPlanDataEnumerator);
  StatusBar.Panels[1].Text:='Unassigned Order Packages: '+IntToStr(Summary.CountUnassignedOrderPackages);
  StatusBar.Panels[2].Text:='Unassigned Orders: '+IntToStr(Summary.CountUnassignedOrders);
end;

Ich bin auf das Problem gestoßen, als ich einfach nur "Summary" an die Prozedur übergeben habe - in der Annahme, dass dieses Casting automatisch erfolgt. Dann aber gibt Delphi das Objekt zu früh frei. Mit dem Cast passiert das nicht - aber ich verstehe nicht wirklich warum. Und das fühlt sich ziemlich blöd und unstabil an.

Der Ansatz, Interfaces zu nutzen, die voneinander erben, hilft hier zwar gerade noch, aber löst das Grundproblem nicht. Ich habe noch kein Beispiel gefunden, das den Umgang mit Objekten zeigt, die mehrere unabhängige Interfaces implementieren.

Nehmen wir mal ein anderes Beispiel:

TAutomobil könnte IFarbe, ISteuerung und IMotor implementieren, die nichts miteinander zu tun haben (IFarbe könnte auch von TBauklotz implementiert werden, ISteuerung von TFahrrad, IMotor aber nicht).

Nehmen wir an, wir wollen das Objekt TAutomobil nun umspritzen:

Delphi-Quellcode:

procedure Umspritzen(Gegenstand: IFarbe);
[...]
Umspritzen(TAutomobil)

Dann ergibt es ja keinen Sinn, das Auto mit "var Auto: IFarbe" zu deklarieren. Wir wollen ja das ganze Auto nutzen. Mein erster Ansatz, einfach das Objekt zu übergeben, sah so aus:

Delphi-Quellcode:

var
  Auto: TAutomobil:
[...]
  Auto:=TAutomobil.Create;
  Umspritzen(Auto);

Das führt offenbar dazu, dass ein neues Interface angelegt wird und dann wieder freigegeben wird. Auto scheint nach dem Aufruf von Umspritzen zumindest freigegeben zu sein. Außerdem meine ich beobachtet zu haben, dass die Änderungen am übergegeben Gegenstand nur für das Interface gelten. Man kann innerhalb von Umspritzen dann mit TObject(Gegenstand) arbeiten, dann werden wirklich die Objektattribute geändert. Alles nicht hübsch und wirkt wacklig. Wie es aber offiziell laufen sollte, konnte ich noch nicht sicher herausfinden. Funktioniert eben alles, wirkt aber brüchig.


Um noch ein Beispiel zu nehmen: Ich habe ein Benachrichtigungsobjekt, bei dem sich andere Objekte als Interessent für bestimmte Nachrichten eintragen können, sofern sie IMessageHandler implementieren. Das können Formulare, TInterfacedObject-Nachfahren oder auch sonstige Controls sein. Wenn irgendwo in der Anwendung z.B. ein Budgetwert geändert wird, sorgt das Benachrichtigungsobjekt dafür, dass die Handler-Methode aller eingetragenen Objekte aufgerufen wird. Ich verzichte auf Windows-Messages, weil ich die Ausführung abwarten und die Reihenfolge sehr gezielt steuern will. Wie auch immer: Auch hier habe ich den Fall, dass ich ein Objekt, dass ein bestimmtes Interface implementiert, an eine Funktion übergebe, die genau dieses Interface als Parameter erwartet.

Die perfekte Funktionsdeklaration wäre also:

procedure DoSomethingWithAnObject(Object: "Object which Implements ISomeInterface");
Mal so in Pidgin-Delphi... weil das nicht geht, ist der Parameter vom Typ Interface und es stellt sich die Frage, wie man dann das Objekt korrekt übergibt. "Objekt as ISomeInterface" scheint zu funktionieren, "Objekt" nicht, das führt zur Freigabe des Objekts.

[stahli]

Wenn Du mit Interfaces arbeitest solltest Du ab dem Moment nicht mehr mit der Klasse arbeiten.

Wenn Du z.B. eine Autoklasse hast:

TCar = class(TInterfacedObject, IEngine, IColor, IDriver) dann kannst Du später eine Objekt als Interface verwenden:

Delphi-Quellcode:

var Intf: IIinterface;

Intf := TCar.Create;

Dieses kannst Du dann prüfen, ob es auch andere Interfaces implementiert:

Delphi-Quellcode:

var lColor: IColor;
    lEngine: IEngine;
if Supports(Intf, IColor, lColor) then
  lColor.Color := clRed;
if Supports(Intf, IEngine, lEngine) then
  lEngine.Start;

Ab dem Moment kannst bzw. solltest Du nicht mehr mit der Klasse arbeiten. Jedenfalls nicht von außen auf diese zugreifen.


In Deinem Beispiel verstehe ich nicht wirklich, warum Du Summary als Interface ausführen willst. Das könnte doch auch einfach eine Klasse oder ein Record bleiben, der die Zählwerte sammelt.

In Interface bringt Vorteile,
- wenn Du Dich nicht mehr um die Freigabe des Objektes kümmern willst
oder
- wenn Du unterschiedliche (nicht voneinander abgeleitete) Klassen hast, die die gleichen Funktionalitäten implementieren sollen (also an bestimmten Stellen austauschbar sein müssen).


Du kannst ja mal schauen, ob Dir mein Tutorial etwas bringt: http://www.delphipraxis.net/183702-i...-factorys.html
Die Videos vermutlich nicht, aber evtl. die Diskussion dort.

[Lemmy]

Zitat von Hepdepaddel:

Nehmen wir mal ein anderes Beispiel:

TAutomobil könnte IFarbe, ISteuerung und IMotor implementieren, die nichts miteinander zu tun haben (IFarbe könnte auch von TBauklotz implementiert werden, ISteuerung von TFahrrad, IMotor aber nicht).

nein sicher nicht. TAutomobil implementiert NICHT IMotor, denn ein Auto IST kein Motor, sondern ein Auto HAT einen Motor, also wäre richtig:

Delphi-Quellcode:

type
  TAutomobil = class(xyz)
  private
    FMotor: IMotor
....

Und das macht einen deutlichen Unterschied. Dito mit Steuerung und Farbe (wobei Farbe wieder eine Eigenschaft von Karosserie wäre, weil die Inneneinrichtung ja auch ne Farbe (mehrere) hat).

Prüf mal dein TSummary - ich vermute Du hast hier ein vergleichbares Problem: EIn Superobjekt, das zu viele Zuständigkeiten hat und ggf. anders aufgeteilt werden sollte...

[TiGü]

Zitat von Hepdepaddel:

Delphi-Quellcode:

var
  Summary: TMySummary;
begin
  Summary:=TMySummary.Create;
  Summary.Init;
  ProjectData.CallEnumeratorForAllElements(Summary as IPlanDataEnumerator);
  StatusBar.Panels[1].Text:='Unassigned Order Packages: '+IntToStr(Summary.CountUnassignedOrderPackages);
  StatusBar.Panels[2].Text:='Unassigned Orders: '+IntToStr(Summary.CountUnassignedOrders);
end;

Uff, soviel Text und dein Problem ist dabei ganz einfach:
Verwende NICHT die Objektinstanzen, sondern nur die Interfaceinstanzen.

Vergleiche den von mir zitierten Abschnitt nochmal ganz genau mit meinen Quelltext aus dem Post davor (Tipp: Schaue die Variablen-Deklaration an).

Und ggf. auch nochmal zum nachlesen:
http://www.nickhodges.com/page/Why-Y...eferences.aspx

[Hepdepaddel]

Zitat:

Uff, soviel Text und dein Problem ist dabei ganz einfach:
Verwende NICHT die Objektinstanzen, sondern nur die Interfaceinstanzen.

Vergleiche den von mir zitierten Abschnitt nochmal ganz genau mit meinen Quelltext aus dem Post davor (Tipp: Schaue die Variablen-Deklaration an).

Und ggf. auch nochmal zum nachlesen:
http://www.nickhodges.com/page/Why-Y...eferences.aspx

[/QUOTE]


Sorry für den vielen Text - ich wollte nur den Hintergrund schildern, weswegen mir abgeleitete Interfaces nicht reichen und ich gerne auch auf Objektmethoden zugreifen würde.

Den Text von Nick kannte ich - das Buch liegt hier - aber der beschreibt leider nur die einfachen Fälle. Und dass Du die Variable als Interface deklariert hattest, hatte ich gesehen, das Casting fand ich nur unglücklich. Wenn man ein TForm mit Interfaces ausstatten will, müsste man zudem ein Interface schreiben, das alle von außen genutzten Methoden (z.B. ShowModal) beinhaltet, damit man das Formular anzeigen kann, es weitere Interface-Methoden ansprechen kann und Reference Count dennoch funktioniert. Ergibt sicher Sinn, die Logik "wenn ein Objekt irgendein Interface implementiert, dann sollten auch alle anderen Methoden des Objekts, die man nutzen will, über ein Interface verwendet werden" war mir noch nicht so klar.

Nochmals besten Dank!

[TiGü]

Zitat von Hepdepaddel:

Wenn man ein TForm mit Interfaces ausstatten will, müsste man zudem ein Interface schreiben, das alle von außen genutzten Methoden (z.B. ShowModal) beinhaltet, damit man das Formular anzeigen kann, es weitere Interface-Methoden ansprechen kann und Reference Count dennoch funktioniert.

Nein, muss man für den Fall einer TComponent/TForm eben nicht.
Hier kann auch einfach geprüft (is-Operator) und gecastet werden (as-Operator), ohne das dir irgendetwas kaputt geht, weil der Reference Counting Mechanismus für TComponent anderes implementiert ist, als bspw. für TInterfaceObject.

Wenn es also heißt:

Delphi-Quellcode:

type
  TDeineForm = class(TCustomForm, IEineFunktionalität, IEineAndereFunktionalität)
...

Dann kannst du problemlos folgendes tun:

Delphi-Quellcode:

var
  MeineInstanz : IEineFunktionalität;
  LokalesForm : TForm;
begin
...
if MeineInstanz is TForm then
begin
  LokalesForm := MeineInstanz as TForm; // oder TForm(MeineInstanz), wenn wirklich durch is-Operator oder Supports(...) geprüft wurde
  LokalesForm.ShowModal;
...
end;

Zitat von Hepdepaddel:

Ergibt sicher Sinn, die Logik "wenn ein Objekt irgendein Interface implementiert, dann sollten auch alle anderen Methoden des Objekts, die man nutzen will, über ein Interface verwendet werden" war mir noch nicht so klar.

Nochmal: Du muss nicht alle Methoden, Properties und Anhängsel einer Klasse im Interface abbilden.
Das wäre sonst sehr sehr falsch!

[Sir Rufo]

Das mit dem Casten sollte man sich aber auch genau überlegen und nicht als generellen UseCase abspeichern.

Es gibt Fälle, wo man das gefahrlos machen kann und andere, wo man damit auf die Nase fällt.

Generell sollte ein Interface alles das liefern was benötigt wird um damit zu arbeiten. Ansonsten fragt man einfach per System.SysUtils.Support nach, ob da noch ein weiteres Interface unterstützt wird.

Aber es macht keinen Sinn ein Monster-Interface zu erschaffen. Besser sind dort kleine aber feine, die man dann an unterschiedliche Klassen hängen kann.

Delphi-Quellcode:

IShowView = interface
  function GetVisible;
  property Visible: Boolean read GetVisible;
  procedure Show;
  procedure Hide;
end;

IShowModalView = interface
  function ShowModal: TModalResult;
end;