Clases Maestro Detalle

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