Hola NickName,
Disculpa, pero no puedo darme el lujo de estar probando tu código... la verdad es que el tiempo en estos momentos son demasiados acotados...
Por el vistazo que le dí habría que definir mejor el concepto y entendimiento de lo que es realmente el concepto de "Maestro/Detalle" en POO. Se que dices que te estás iniciando en el mundo de la POO. Te aconsejo que para seguir en este mundo de la POO agarres un buen plano: UML. Te recomiendo el libro UML y Patrones de Craig Larman y/o UML Gota a Gota de Martin Flower y Kendall Scott.
Si ya sabes algo de UML sabrás que todo deriva de un diseño del dominio. Un ejemplo sencillo, de lo que comprendo y entiendo del problema que redactas, es este (disculpa por lo burdo):
Código:
Proveedor - 1 ------- 1..* - Movimientos - 1 -------------------- 1..* - LineasMovimientos
realiza Esta-conformado-por
Más o menos la idea es que: el Proveedor realiza al menos un movimiento y cada movimiento está conformado por una serie de lineas (el detalle).
Generalmente, (no siempre) este manejo de la cardinalidad se consigue con la implementación de un objeto contenedor (como menciona Craig), posiblemente un TObjectList.
La idea de la cardinalidad (el 1-Muchos) y de este ObjectList es mantener en memoria la relación entre cada proveedor y sus movimientos.
De modo que ha simple diseño (y sobre todo rápido) yo lo veo así:
Código Delphi
[-]TProveedor = class
private
FMovimientos = TObjectList;
public
end;
O si el diseño lo amerita... hacer esto:
Código Delphi
[-]TProveedor = class
private
FMovimientos = TMovimiento
public
end;
Siendo ya, en este caso, TMovimiento descendiente de TObjectList pero que contiene los elementos necesarios y adecuados; ocultando (preferiblemente) la arquitectura de su descendiente (es decir que es posible que sería conveniente que a los fines de uso de esta clase, que oculte al exterior el hecho de que internamente es un TObjectList).
Código Delphi
[-]TMovimiento = class(TobjectList)
private
public
end;
Y este procedimiento se realiza en forma análoga entre Movimiento y su detalle.
Por otro lado, no me convence la idea de que las clases lógicas invadan o contengan funciones que podrían (nota la palabra: podrían) recaer en la capa de datos. Es decir que estas clases deleguen el trabajo de hacer la consulta y el acceso a la base de datos a otro objeto que posiblemente esté más calificado.
La idea de delegar este trabajo es que tanto TProveedor, como TMovimiento envien el mensaje de grabar, modificar, borrar, etc a este objeto y sea éste el encargado de hacer el trabajo sucio.
¿Porqué dije podría? Porque si tu diseño (mejor dicho el dominio) es simple es posible que adosar esta nueva clase (llamemosla AccesoDB) haga más complicado al modelo y lleve a costos y pérdida de tiempo.
Creo que resulta lógico pensar que si son estas tres clases (Proveedor, Movimiento, LineaMovimiento) las únicas en el dominio... incorporar esta cuarta... sería un poco lioso y molesto... pero cuando el diseño engloba a más... es claro y evidente de que se necesita un mejor diseño de las clases y su delegación de funciones.
El diseño de tus clases debería seguir el flujo de la información que te proporciona el modelo. El punto de partida de la cardinalidad que yo te he mostrado es tan sólo uno de los puntos a tener en cuenta.
Teniendo en cuenta esto yo estaría pensando en métodos como:
GetMovimientos(): que se encargaría de obtener los movimientos para un proveedor. La clase Proveedor envíea este mensaje a la clase Movimiento. Y a su vez, este nombre sugiere que el proceso sea análogo para sus detalles: GetDetalleMovimientos() o getLineaMovimientos()
InsertarMovimientos(): que al parecer, a mi modo de ver, sería el Proveedor que envía el mensaje... aprovechando el hecho de que está el TObjectList lo que podría realizar es hacer por ejemplo un Add sobre su FMovimiento...
Código Delphi
[-]procedure TProveedor.InsertarMovimiento(Movimiento: TMovimiento);
begin
...
FMovimientos.Add(Movimiento);
...
end;
En fin... esto dependerá de como estructures y diseñes tus clases. Como te decía... hay varias posibilidades de como lograr hacer los "vinculos".
Y asi seguiría con el diseño.
Se que no te he ayudado con el código pero al menos creo haber dicho que algo deberías tener en cuenta: La correcta asignación de responsabilidades.
No es que lo que hayas hecho esté mal...sino que no veo como logras hacer referencia entre la clase proveedor y la clase movimientos. No veo, al menos yo, un
vinculo de interés (o como debe decirse: asignación de responsabilidades).
Para una primera aproximación, tu diseño ha sido un gran avance.
Si realmente deseas llevar un sentido más "purista" hacia la POO, considero tomes bien estas palabras: leer un buen libro de UML y perder el miedo al análisis y diseño primero.
Y ten presente que no hay un único diseño y comprención del problema. Existen tantos diagramas de dominio, como personas hay en este mundo... por lo que no existe una única solución de como implementar correctamente la asignación de responsabilidades de las clases. De modo que para poder recibir la mejor ayuda sería oportuno que tu nos informes de tu modelo, de tu comprensión del dominio. Porque si yo te muestro mi diseño es posible que no sea tan coincidente con el tuyo y para ti sea más complicado de asimilarlo y comprenderlo.
Espero haber sido de ayuda.
Saludos,
PD: Disculpa por tanto texto.