Clases Maestro Detalle

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