Clases Maestro Detalle

[NickName]

Hola Delphius...

Primero que nada muchas gracias por toda tu aportación de verdad te agradesco mucho...

Disculpa, pero no puedo darme el lujo de estar probando tu código

Solo queria que me comentaran si no estaba mal la forma de haserlo asi como lo hisite muchas gracias tambien por eso ya que para uno que inicia siempre hay temor de si se esta haciendo lo correcto o no...

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

Creo que no me explique bien pero mi problema es mas simple que eso ya que no se como podria ser la estructura de las clases Movimiento y Detalle_Movimiento ya que estas son Maestro Detalle la clase de Proveedores solo la puse para que me comentaran si era correcto lo que estaba haciendo pero no tiene ninguna relación con la clase de Movimiento...

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.

Esactamente eso queria que me comentaran por eso puse el codigo de la clase de proveedor... si tengo una clase se llama Conexion y Todas las demas heredan de esa para poder insertar modificar o eliminar datos pero ese es el problema que no sabia si es correcta la implementación te pongo el codigo:

Uso los Fibplus para conectarme a Firebird: Por todo lo que comentas y otro hilo que cheque hasta me da pena publicar mi codigo...

Código Delphi [-]
unit C_Conexion;

interface

Uses Db, SysUtils, pFIBDatabase, pFIBQuery, pFIBDataSet, C_Parametros;

 Type
    TConexion = Class (TObject)
       private
            FDb_Firebird: TpFIBDatabase;
            FConectado: Boolean;
            FParametros: TParametros;
            FConsulta: TpFIBDataSet;
            FTransaccion: TpFIBTransaction;
            FOperacion: TpFIBQuery;
            FUsuario_Conectado: String;
            FDatos_Guardados: Boolean;
            FTarea: String;
            FOtros_Datos: TpFIBDataSet;
            FError_Valida: String;
            procedure SetError_Valida(const Value: String);
            procedure SetOtros_Datos(const Value: TpFIBDataSet);
            procedure SetDatos_Guardados(const Value: Boolean);
            procedure SetTarea(const Value: String);
            procedure SetUsuario_Conectado(const Value: String);
            procedure SetOperacion(const Value: TpFIBQuery);
            procedure SetTransaccion(const Value: TpFIBTransaction);
            procedure SetParametros(const Value: TParametros);
            procedure SetConsulta(const Value: TpFIBDataSet);
            procedure SetConectado(const Value: Boolean);
            procedure SetDb_Firebird(const Value: TpFIBDatabase);
       public
            constructor Create;
            Procedure Conectar_Db_Firebird;
            Function  Identificar(Clave:String):String;
            Function  Traer_Datos(Select:String):TDataSource;
            Function  Validar_Datos:Boolean;  Virtual;
       Published
            Property  Db_Firebird:TpFIBDatabase read FDb_Firebird write SetDb_Firebird;
            Property  Parametros:TParametros read FParametros write SetParametros;
            Property  Conectado:Boolean read FConectado write SetConectado;
            Property  Consulta:TpFIBDataSet read FConsulta write SetConsulta;
            Property  Otros_Datos:TpFIBDataSet read FOtros_Datos write SetOtros_Datos;
            Property  Transaccion:TpFIBTransaction read FTransaccion write SetTransaccion;
            Property  Operacion: TpFIBQuery read FOperacion write SetOperacion;
            Property  Usuario_Conectado:String read FUsuario_Conectado write SetUsuario_Conectado;
            Property  Datos_Guardados:Boolean read FDatos_Guardados write SetDatos_Guardados;
            Property  Tarea:String read FTarea write SetTarea;
            Property  Error_Valida:String read FError_Valida write SetError_Valida;
     end;

implementation

uses FIBDatabase, FIBDataSet;

{ TConeccion }

constructor TConexion.Create;
begin
    Transaccion:= TpFIBTransaction.Create(Nil);
    //---- Crear Objeto Db
    Db_Firebird:= TpFIBDatabase.Create(Nil);
    //---- Inicializa Parametros Db --
    Parametros:= TParametros.Create;
    Db_Firebird.Connected:=False;
    Conectar_Db_Firebird;
    Operacion:= TpFIBQuery.Create(Nil);
    Operacion.Database:=Db_Firebird;
    Consulta:= TpFIBDataSet.Create(Nil);
    Consulta.Database:=Db_Firebird;
    Otros_Datos:= TpFIBDataSet.Create(Nil);
    Otros_Datos.Database:=Db_Firebird;

end;


function TConexion.Identificar(Clave: String): String;
begin
    With Consulta Do
    Begin
         Close;
         SQLs.SelectSQL.Clear;
         SQLs.SelectSQL.Add('Select Nombre_Usuario, Tipo_Usuario, Activo From Usuarios' +
                 ' Where Clave = :Clave');
         ParamByName('Clave').AsString:=Clave;
         //---- Iniciar transa
         Prepare;
         Try
              Open;
         Except on E:Exception do
         Begin
              Raise;
              Exit;
         End; // execept
         End; // Try
    End;  // With
    if Consulta.IsEmpty then
       Result:=''
    else
       begin
           if Consulta.FieldByName('Activo').AsString = 'SI' then
             begin
                  Usuario_Conectado:=Consulta.FieldByName('Nombre_Usuario').AsString;
                  Result:=Consulta.FieldByName('Tipo_Usuario').AsString;
             end
           else
             Result:='INACTIVO';
       end;
end;

Procedure TConexion.Conectar_Db_Firebird;
begin
    //--- Obtener parametros
    //--- Fijar parametros Transaccion --
    Transaccion.TRParams.Add('write nowait rec_version read_committed');

    Transaccion.DefaultDatabase:=Db_Firebird;

    //--- Parametros de la base de datos
    Db_Firebird.SQLDialect:=3;
    Db_Firebird.DatabaseName:=Parametros.Nombre_Db;
    Db_Firebird.ConnectParams.UserName:=Parametros.Usuario;
    Db_Firebird.ConnectParams.Password:=Parametros.Clave;
    Db_Firebird.ConnectParams.CharSet:=Parametros.Caracteres;
    //---- Asigno la Transaccion
    Db_Firebird.DefaultTransaction:=Transaccion;
    Db_Firebird.DefaultUpdateTransaction:=Transaccion;

    try
        Db_Firebird.Connected:=True;
    except on E: Exception do
    begin
        Conectado:=False;
        Raise;
        Exit;
    end;
    end;
    Conectado:= True;
end;

procedure TConexion.SetConectado(const Value: Boolean);
begin
  FConectado := Value;
end;

procedure TConexion.SetConsulta(const Value: TpFIBDataSet);
begin
    FConsulta:=Value;
end;

procedure TConexion.SetDatos_Guardados(const Value: Boolean);
begin
  FDatos_Guardados := Value;
end;

procedure TConexion.SetDb_Firebird(const Value: TpFIBDatabase);
begin
  FDb_Firebird := Value;
end;

procedure TConexion.SetError_Valida(const Value: String);
begin
  FError_Valida := Value;
end;

procedure TConexion.SetOperacion(const Value: TpFIBQuery);
begin
  FOperacion := Value;
end;

procedure TConexion.SetOtros_Datos(const Value: TpFIBDataSet);
begin
  FOtros_Datos := Value;
end;

procedure TConexion.SetParametros(const Value: TParametros);
begin
  FParametros := Value;
end;

procedure TConexion.SetTarea(const Value: String);
begin
  FTarea := Value;
end;

procedure TConexion.SetTransaccion(const Value: TpFIBTransaction);
begin
  FTransaccion := Value;
end;

procedure TConexion.SetUsuario_Conectado(const Value: String);
begin
  FUsuario_Conectado := Value;
end;

function TConexion.Traer_Datos(Select: String): TDataSource;
begin
    Otros_Datos.Close;
    Otros_Datos.SQLs.SelectSQL.Clear;
    Otros_Datos.SQLs.SelectSQL.Add(Select);
    try
        Otros_Datos.Open;
    except on E: Exception do
    begin
        Raise;
        Exit;
    end;
    end;
    Result:= TDataSource.Create(Nil);
    Result.DataSet:=Otros_Datos;
end;

function TConexion.Validar_Datos: Boolean;
begin
    Result:=True;
end;

end.

en un hilo que cheque comentan que los atributos privados de una clase se deben de usar en la misma clase y los publicos desde fuera y mi clase no aplica eso...

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

Pues ese es el punto que no se como estructurar mis clases nunca habia trabajado con objetos... los libros que me recomendaste te prometo leerlos pero como tu dices no hay mucho tiempo y mi proyecto lo tengo que entregar en febrero...

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.

Creo que si ya habia visto eso del TObjectList lo malo es que uno como novato nunca sabe si es una sola clase y donde pondria la propiedad de ese tipo

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.

Gracias esto da animos y quiere decir que no voy tan mal....

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.

Por Responsabilidades voy a entender que es la relación que hay de una clase con otra...

Por otro lado creo que mi modelo es simple:
segun yo tengo mi clase Conexion con esta me conecto a la DB... y todas mis demas clases heredan de esta para Insertar Modificar y Eliminar Datos.. lo demas es comun Movimeintos con su Detalle_Movimiento, Ticket y su Detalle_Ticket pero la verdad no tengo nada diseñado como dises solo la idea de acuerdo a la Db que tengo y mi problema es q no se como estructurar esas clases Maestro Detalle... bueno y siendo realistas creo que me falta mucho que aprender....
Por todo Gracias...

[NickName]

Gracias Axesys checare esa opción.... y les comento....

[[Delphius]]

Hola NickName,
De curiosidad he vuelto para ver si respondías.

Me alegro que tengas en cuenta mis comentarios y que estés abierto a alternativas. No tengo Delphi a mano... pero al ver la forma en que tu haz hecho tu diseño, no lo veo correcto.

A mi modo de ver... no tiene sentido lógico que las clases Proveedor, Movimiento, etc hereden de Conexion.

Veamos si me explico: la asignación de responsabilidades es un juego sencillo. Al igual que en la realidad a uno le toca a hacer lo que sabe haber. Y claro está, si lo saber hacer es porque tiene la información para saber hacer su tarea. En POO esto se traduce: un objeto hace algo con la información que este tiene.
Un objeto que no sabe delimitar sus funciones y/o delegar parte de su trabajo a otro objeto tiene problemas de diseño. Y es aqui parte del problema. Una clase Movimiento debería delegar parte de su trabajo hacia la clase LineaMovimiento. Es como querer asignarle todo el trabajo de oficina a una persona.

Parte del problema se soluciona teniendo un ObjectList como te comentaba:

Código Delphi [-]
TMovimiento = class
  private
    FLineasMovimiento = TObjectList;
    { FLineasMovimiento es un contenedor. Contendrá todos los objetos
      de tipo TLineaDeMovimiento.
      Con esto se consigue que un Movimiento conozca sus respectivos
      detalles }
  public
     //...
  end;

Ahora continuando con el planteo. ¿Quien se encargaría de crear cada detalle del movimiento? O dicho de otro modo: ¿Que clase tiene la información necesaria para crear cada LineaMovimiento? Comprendiendo el modelo ("Un Movimiento está compuesto por al menos una Linea de detalle") podemos afirmar que la clase Movimiento es una excelente candidata.
Por lo que dicha clase debe contar con un método que realize esta operación. Por ejemplo:

Código Delphi [-]
procecure TMovimiento.CrearLineaMovimiento(...);
// Posiblemente sea aqui donde se pasan algunos valores iniciales
var Linea: TLineaDeMovimiento;
begin
  Linea := TLineaDeMovimiento.Create;
  //...
end;

¿Terminamos? No... Bueno... ya se ha conseguido hacer parte de la referencia... Hemos creado una linea, pero claro... aqui no termina la historia. ¿Cómo mantenemos la referencia? ¡FLineaMovimiento al rescate!

Una vez que se crea la linea de movimiento (y muy posiblemente se asignan algunos valores a sus propiedades), es necesaria asociarla al ObjectList... Podríamos hacer algo como:

Código Delphi [-]
procedure TMovimiento.AsociarLineaDeMovimiento(Linea: TLineaDeMovimiento);
begin
  FLineasMovimiento.Add(Linea);
  // No recuerdo bien que parámetros se necesitan...
end;

Y asi podemos continuar viendo que debe hacer cada clase y/o conocer cada clase.

Ahora pensemos... ¿Sería correcto que todas la clases entiendan de SQL y sepan conectarse a la base de datos? ¿Que tienen que ver un Movimiento, un Proveedor, una LineaDeMovimiento con el acceso a base de datos? Poco y nada. Ahora tu me dirás: ¿Pero que no es que cada clase debe hacer lo que sabe y cuenta con la información para ello? ¿Pero si cada una cuenta con la información necesaria porqué no hacer que ellas sean quienes accedan a la base de datos?

La respuesta es que la verdad está a medias. Es correcto el hecho de que tanto Proveedor, como Movimientos, etc... tienen la información necesaria. Pero ¿es necesario que todas sepan y entiendan de SQL? La respuesta es NO.
Lo correcto sería tener otra clase que sepa de SQL, entienda sobre base de datos.

Viendo que me aportaste mayor información acerca de tu dominio. Yo ya optaría por algo más modular. Me hablas de Ticket y su respectivo detalle.
Ya tienes 5 clases que aprenden SQL... contra una que entiende.

Tu viniste haciendo una asignación de responsabilidades a la inversa. Hiciste el trabajo sucio en la parte alta de la rama del diagrama y debería ir en la parte baja.

Lo más correcto sería que Proveedor, y demás se comuniquen con esta clase extraña que entiende de base de datos y nada más que de base de datos y le pasan los datos lo que se desea grabar, modificar, etc.

Por ejemplo tal vez algo como esto:

Código Delphi [-]
procedure TMovimiento.Registrar(Movimiento: TMovimiento);
begin
  AccesoDB.Grabar(Self);
end;

AccesoDB, podría leer desde las propiedades del Movimiento y en base a lo que lee arma un SQL y lo manda a ejecutar.

Lo más correcto es que no haya una única clase que se encargue del trabajo sucio. Es de esperar que sean varios objetos quienes colaboran en dicha tarea.

Yo ya te he comentado que si te impongo un modelo y mi punto de vista sería perjudicial para ti. Haz el tuyo y de alli estructura las clases correctamente.
En vista a que no tienes un diseño preliminar recomiendo que antes de seguir metiendo código te documentes mejor sobre UML.
No conduzcas por la carretera de POO sino tienes un mapa que te indique si vas bien o mal.

Podríamos continuar con las explicaciones, pero es un tema que no se aprende en pocos días. si bien aqui puede que haya espacio para ir redactando cada tema o duda que te vayan surgiendo... no va alcanzar para evacuarte todas tus dudas.
Lee UML y Patrones y asimilarás la idea y la filosofía que encierra el mundo POO.

Saludos,

[NickName]

Hola Delphius Muchas gracias....

He leeido todo lo que se atraviesa en mis ojos de POO pero no es lo mismo leer que aplicar todo ya en un lenguaje en particular lo que hise y te mostre fue algo paresido a lo que vi en un curso que tome de C# por momentos sentia que estaba bien y luego sentia que no... bueno a mi me gusta delphi por eso lo elegi como lenguaje o mas bien tengo algo de tiempo haciendo cosas y siempre que desarrollo algo tenia que hacer todo de nuevo por eso elegi hacerlo ahora Orientado a objetos se que cuesta mucho se codifica mas pero todo tiene su recompensa y siento que al final me sentire bien por el trabajo realizado...
Si entiendo todo lo que me dijiste hoy prometo leer todo lo que pueda del primer libro que me recomendaste (Uml y Patrones) ya sabia que me costaria mucho pero no me arrepiento de haber elegido esta forma de desarrollo...

Lo más correcto sería que Proveedor, y demás se comuniquen con esta clase extraña que entiende de base de datos y nada más que de base de datos y le pasan los datos lo que se desea grabar, modificar, etc.

Por ejemplo tal vez algo como esto:


Código Delphi [-]procedure TMovimiento.Registrar(Movimiento: TMovimiento);
begin
AccesoDB.Grabar(Self);
end;
AccesoDB, podría leer desde las propiedades del Movimiento y en base a lo que lee arma un SQL y lo manda a ejecutar.

Esto era lo que trataba de hacer pero nunca me llego la idea de como hacerlo... No se tu pero siento que en estos casos todo lo que a uno le dicen o vee es bueno ya que como te comente no es lo mismo leer que hacer...
No tenia ni idea y me preguntaba como sabra la clase AccesoDb que Grabar si se supone que tengo Clientes, Proveedores Ticket etc etc y cada clase tiene distintos campos... y por eso aplique lo que vi en ese curso que te digo que no me convencia...

Yo ya te he comentado que si te impongo un modelo y mi punto de vista sería perjudicial para ti. Haz el tuyo y de alli estructura las clases correctamente.

Siento que me ayudaria el modelo que dices que me impondrias yo no siento que seria asi... siento que entre mas ideas tenga mejor lo hare... el libro lo leere por que nunca he hecho un diseño...
De verdad te agradezco mucho toda tu ayuda se que cuesta mucho saber lo que sabes por eso muchas gracias por aportar Toda esa Luz... bueno mejor dicho Conocimientos...

[[Delphius]]

Empezado por NickName

Hola Delphius Muchas gracias....

He leeido todo lo que se atraviesa en mis ojos de POO pero no es lo mismo leer que aplicar todo ya en un lenguaje en particular lo que hise y te mostre fue algo paresido a lo que vi en un curso que tome de C# por momentos sentia que estaba bien y luego sentia que no...

De nada, me da gusto en poder ayudar en algo...
Es cierto, no es lo mismo leer que aplicarlo. Sobre todo si lo que lees está redactado y usa de ejemplo otro lenguaje.

Personalmente opino que cuando uno se siente confuso sobre la manera en que está trabajando es una muestra de un diseño débil. Aunque también es posible que se esté buscando a un arbol dentro del bosque.
No lo tomes a mal, sino como un largo proceso de maduración.

Empezado por NickName

bueno a mi me gusta delphi por eso lo elegi como lenguaje o mas bien tengo algo de tiempo haciendo cosas y siempre que desarrollo algo tenia que hacer todo de nuevo por eso elegi hacerlo ahora Orientado a objetos se que cuesta mucho se codifica mas pero todo tiene su recompensa y siento que al final me sentire bien por el trabajo realizado...

Ummm. ¿Que se programa más siguiendo OO? Ummm yo diría que todo lo contrario. Podría ser la excepción cuando se trata de elaborar las clases que te servirán de propósito general. Pero en fin, si el sentimiento de que programas más empleando OO persiste estás en presencia de una falta de comprensión de la asignación de responsabilidades. No te critico, sino más bien es un consejo. Lo correcto sería que el esfuerzo de trabajo debería ir decajendo a medida que se sigue el diagrama del dominio o el diagrama de clase.

Empezado por NickName

Si entiendo todo lo que me dijiste hoy prometo leer todo lo que pueda del primer libro que me recomendaste (Uml y Patrones) ya sabia que me costaria mucho pero no me arrepiento de haber elegido esta forma de desarrollo...

Al comienzo cuesta, como a mi... De hecho amigo... a mi me cuesta dominar algunas cosas de la POO. No soy el gran maestro en el arte OO, pero en algo se puede... ayudar.
Lo correcto y lo primordial a aprender: Armar las relaciones entre los objetos y los Patrones GRASP: Asignación de responsabilidades. Son intuitivos (al menos yo a estas alturas los siento así). Pero patrones más avanzados como Factoría, Estrategia, Composite... no se les entiende a la primera (De hecho me estoy peleando con la Factoria).

A medida que continúes con la lectura de el libro comprenderás de lo que te he dicho. De hecho debería serte familiar lo que dije antes. Ya que el ejemplo lo he adaptado de el libro

Empezado por NickName

Esto era lo que trataba de hacer pero nunca me llego la idea de como hacerlo... No se tu pero siento que en estos casos todo lo que a uno le dicen o vee es bueno ya que como te comente no es lo mismo leer que hacer...
No tenia ni idea y me preguntaba como sabra la clase AccesoDb que Grabar si se supone que tengo Clientes, Proveedores Ticket etc etc y cada clase tiene distintos campos... y por eso aplique lo que vi en ese curso que te digo que no me convencia...

Es bueno estar atento a las alternativas, pero si recién estás incursionando en el mundo OO debes tener más firme los conceptos para comprender lo que te decimos.

Por eso te decía que es mucho más probable de que no sea una única clase la que hace el trabajo sucio. Es posible que haya una o dos más. Pero en fin, si bien puede parecerte que añadir más clases al modelo te resulta complicado notarás que las clases se volverán más relajadas, con lo que:
1. Cada clase se vuelve más estable.
2. Mantienen un bajo acoplamiento y alta cohesión. Con lo cual se vuelven fácilmente reutilizables.
3. Adosar nuevas clases hace que el modelo se amplie con poco esfuerzo.

Empezado por NickName

Siento que me ayudaria el modelo que dices que me impondrias yo no siento que seria asi... siento que entre mas ideas tenga mejor lo hare... el libro lo leere por que nunca he hecho un diseño...
De verdad te agradezco mucho toda tu ayuda se que cuesta mucho saber lo que sabes por eso muchas gracias por aportar Toda esa Luz... bueno mejor dicho Conocimientos...

Sigo pensando que imponerte el modelo es contraproducente. Sobre todo si no te haz incursionado en el mundo de UML.
Aprende UML primero y el modelo del dominio pronto te saldrá de la cabeza y notarás las cosas más frescas.

Ya he dicho que no soy el gran experto, me haces sonrojar. Te agradezco que tomes mis palabras en cuenta. Te doy mi consejo, algo que ya te he dicho antes: El modelo no es único. Eso es lo lindo de la POO, que un mismo dominio posee diversas interpretaciones y buscar la más adecuada es más de arte que de ciencia.

Saludos,

[NickName]

Ok Delphius...

Seguiere hechandole a la lectura... y en unos de estos dias haber si ya puedo con el diseño... y les comento....
Bueno por todo gracias de verdad...