Hola,
Para poder llevar a cabo el patrón Adapter es necesario contar con una visión de la clase cliente. Para el caso, se necesita saber la clase cliente de esa lista de TRegistro. Y quizá, examinar la estructura de la clase TRemotable para ver en que y como es que afectaría al cliente.
Si no existe, o en todo caso si el importador no lo crea, entonces pasa por el desarrollador diseñar la clase cliente. En este panorama directamente no hace falta patrón alguno... directamente se diseña a la clase para que administre el arreglo y se encargue de ofrecer una interfaz adecuada para sus intereses.
Si me puedes indicar si además de esa clase y la lista hay otras sería lo más adecuado antes de seguir analizando y determinar si es válido y conveniente un Adapter.
Por lo pronto haré de cuenta de que no existe tal clase y ofreceré un ejemplo sencillo a vuelo:
TConsumerListaRegistro = class
private
FListaRegistros: TListaRegistro;
// métodos get y set para acceder a la lista de registro
function GetRegistro(Index: integer): TRegistro;
procedure SetRegistro(Index: integer; Value: TRegistro);
public
function Counts: integer;
procedure SetLengthList(Value: integer);
// SetLenghList asigña tamaño a la lista
function CreateRegistro: TRegistro; overload;
function CreateRegistro(Index: integer): TRegistro; overload;
// nos crea un objeto de la clase TRegistro
procedure FreeRegistro(Index: integer); overload;
procedure FreeRegistro(Registro: TRegistro); overload;
// libera un registro de la lista. OJO: liberar no alterar el tamaño de la lista
function AddRegistro(Registro: TRegistro): integer;
// Agrega el registro a la lista, altera el tamaño
function DeleteRegistro(Registro: TRegistro): integer; overload;
procedure DeleteRegistro(Index: TRegistro); overload;
// Elimina el registro de la lista, altera el tamaño
property Registros[I: integer]: TRegistro read GetRegistro write SetRegistro;
// propiedad vectorial de acceso a la lista
end;
Como pueden apreciar la clase asume el trabajo de crear, liberar, etc. la lista de objetos de clase TRegistro. Por debajo de esto esconde todo un trabajo con el array y operaciones con vectores de toda la vida... Creería que el código podría resultarles elemental y se hacen una idea. En su lugar ofrece una interfaz basada en la propiedad vectorial Registros[] gracias a los métodos GetRegistro y SetRegistro.
Una posible implementación de dichos Getter y Setter puede ser algo como:
function TConsumerListaRegistro.GetRegistro(Index: integer): TRegistro
begin
if (Index >= Low(FListaRegisto)) AND (Index <= High(FListaRegistro))
then result := FListaRegistro[Index];
end;
procedure TConsumerListaRegistro.SetRegistro(Index: integer; Value: TRegistro);
begin
if (Index >= Low(FListaRegisto)) AND (Index <= High(FListaRegistro))
then FListaRegistro[Index] := Value;
end;
Ahora ya no hay que preocuparse por el array. La clase nos permite hacer cosas como éstas:
var Reg5: TRegistro;
Reg5 := MiConsumer.Registros[5];
Incluso se puede iterar:
var j: integer;
begin
for j := 0 to MiConsumer.Counts -1 do
MiConsumer.Registros[j].Documento := 'Documento' + IntToStr(j);
...
Creo que con esto se entiende la idea
Sobre lo que me comentas de que tienes algunos de anidamiento de clases, ese enfoque es quizá más complejo y habría que analizar mejor el caso. Tendría que tener conocimiento de qué, y como es que se lleva a cabo. Podría implementarse, quizá, con una variación del patrón Composite y Adapter, como éste.... un AdapterComposite (que no es algo raro de encontrar) si la idea es tratar a ese anidamiento de clases como si se tratase de una clase simple, y mientras todos tuvieran alguna interfaz en común. De no ser así el escenario sugeriría otro enfoque... pero para ello se requiere de un mejor estudio.
Lo más directo, simple y elemental sería propagar mi idea:
miConsumer.Registros[1].SubRegistros[2].SubSubRegistros[3].Documento := 'hola';
Pero esto, como puede verse conduce a confusiones si se propaga demasiado... ¡se están violando la Ley de Démeter, hay demasiado acoplamiento y anidamiento.
Si me das más datos...
Saludos,
