OOP y referencias circulares

[roman]

No sé yo si esto te pueda servir. La idea es que dos unidades pueden usarse una a la otra siempre y cuando no sea ambas en la parte de interface. En el ejemplo que te pongo factorizo por una tercera unidad común que ambas llaman desde su parte interface. Esta unidad común contiene interfaces a las clases, pero no implementan nada. Cada unidad Catalogos y Ventanas usan esta unidad común para poder declarar sus propiedades en la parte interface. Pero es en la parte implementation donde cada una llama a la otra para poder construir realmente el objeto que implementa la interfaz.

Código Delphi [-]
// Intf.pas

unit Intf;

interface

type
  IVentana = interface;

  ICatalogo = interface
    function GetVentana: IVentana;
  end;

  IVentana = interface
    function GetCatalogo: ICatalogo;
  end;

implementation

end.
-------------------------------------------------------------------------------

// Catalogos.pas

unit Catalogos;

interface

uses
  Intf;

type
  TCatalogo = class(TInterfacedObject, ICatalogo);
  private
    FVentana: IVentana;

  public
    function GetVentana: IVentana;
    constructor Create;
  end;

implementation

uses
  Ventanas;

function TCatalogo.GetVentana: IVentana;
begin
  Result := FVentana;
end;

constructor TCatalogo.Create;
begin
  FVentana := TVentana.Create;
end;

end.
-------------------------------------------------------------------------------

// Ventanas.pas

unit Ventanas;

interface

uses
  Intf;

type
  TVentana = class(TInterfacedObject, IVentana);
  private
    FCatalogo: ICatalogo;

  public
    function GetCatalogo: ICatalogo;
    constructor Create;
  end;

implementation

uses
  Catalogos;

function TVentana.GetCatalogo: ICatalogo;
begin
  Result := FCatalogo;
end;

constructor TVentana.Create;
begin
  FCatalogo := TCatalogo.Create;
end;

end.

Ahora, al margen de esto, pienso que es un poco raro que una clase, TCatalogo se encargue de su propia representación visual. De alguna manera esto la hace dependiente de la parte visual, cosa que no se recomienda. Quizá te convendría factorizar por un tercer objeto que se encargue de crear la ventana y pasarle los datos de un objeto TCatalogo.

// Saludos

[[AzidRain]]

Finalmente obté por algo muy parecido a lo que comentas al final...Le di a la ventana métodos para que pueda manipular el TCatalogo, es decir, mostrarlo, añadirle o quitarle cuentas, etc. pero de manera visual. Si cambio el catálogo no afecta a la ventana pues esta solo le manda mensajes tipo "Borracuenta(numCuenta)" o "ObtenCuentas". Lo hice así mas que nada porque la ventana en cuestion, tendrá algo de interactividad que requiere estar actualizando cosas a TCatalogo. El TCatalogo lo crea en este caso la aplicación principal y se lo pasa a la ventana para que lo manipule, una vez cerrada la ventana la aplicación lo destruye.

Mira que simple se vuelve el código cuando lo ve uno así, si lo hubiese hecho como antes me hubiera quedado un rollazo de n lineas, así como voy me quedan métodos pequeñitos de unas cuentas líneas y que decir de como se puede leer el código...

grax