Interface und Objektreferenz offenbar noch nicht verstanden

[Hepdepaddel]

Erst einmal vielen Dank für die bisherigen Ratschläge! Hier noch die Deklaration von TMySummary

Delphi-Quellcode:

  TMySummary = class(TInterfacedObject, IPlanDataEnumerator)
    public
      CountUnassignedOrderPackages, CountUnassignedOrders: Integer;
      procedure Init;
      procedure HandlePlanDataElement(PD: TPlanData);
  end;

Und hier die Implementierung:

Delphi-Quellcode:

procedure TMySummary.Init;
begin
  Self.CountUnassignedOrderPackages:=0;
  Self.CountUnassignedOrders:=0;
end;


procedure TMySummary.HandlePlanDataElement(PD: TPlanData);
begin
  if PD.IsOrderPackage then begin
    if TOrderPackage(PD).LPOCostType='' then Inc(Self.CountUnassignedOrderPackages);
  end;
  if PD.IsOrder then begin
    if TOrder(PD).SAPCostType='' then Inc(Self.CountUnassignedOrders);
  end;
end;

Den Ansatz mit zwei Interfaces werde ich nachher gleich mal probieren, wobei ich erstaunt bin, dass man ein ISummary definieren kann und das dann als IPlanEnumerator übergeben kann.

[Hepdepaddel]

Hi,

der Ansatz mit zwei Interfaces funktioniert leider nicht. Da beschwert sich der Compiler verständlicherweise über inkompatible Typen (ISummary und IPlanDataEnumerator).

Delphi-Quellcode:

TMySummary = class(TInterfacedObject, IPlanDataEnumerator, ISummary)
(...)


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

[TiGü]

Zitat von Hepdepaddel:

der Ansatz mit zwei Interfaces funktioniert leider nicht. Da beschwert sich der Compiler verständlicherweise über inkompatible Typen (ISummary und IPlanDataEnumerator).

Hast du ISummary von IPlanDataEnumerator abgeleitet?

[alda]

Zitat von Hepdepaddel:

der Ansatz mit zwei Interfaces funktioniert leider nicht. Da beschwert sich der Compiler verständlicherweise über inkompatible Typen (ISummary und IPlanDataEnumerator).

Eine Klasse kann beliebig viele Interfaces implementieren, das geht schon. Wenn die Interfaces nicht voneinander ableiten und ein impliziter Cast nicht möglich ist, dann musst Du das explizit casten (AS). Allerdings sollte man auch mal schaun ob deine Implementierung insgesamt so Sinn macht.

[Hepdepaddel]

Zitat von TiGü:

Ist ja voneinander abgeleitet!

Argh... gucken müsste man können. Freitag, wird Zeit fürs Wochenende.

Das funktioniert jetzt auch so:

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;

Aber die Variante mit einem spezielleren Enumerator-Interface ist natürlich sauberer. Werde ich nochmal so umsetzen. Die Umsetzung oben gefällt mir nicht wirklich, ist ein wenig so wie eine unverputzte Hauswand.

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