Cambio de P.estructurada a POO

[Maria85]

Muchas gracias por contestar tan rápido.

Ya he programado más veces en OO, pero en Java y hace tiempo.

El diagrama UML le tengo más o menos terminado.
El caso es que en la aplicación anterior está casi toda la funcionalidad dentro de los Form. Y por eso estoy reestructurandolo para hacerlo mejor. Por eso he creado el diagrama de clases y ya tengo pensado como lo quiero.

Por lo que he creado todas las Units necesarias en mi aplicación pero no tienen nada dentro de momento. Como te digo todo está en los Form. Pero la aplicación sigue funcionando.
¿Me entiendes? Esque alomejor no me explico bien del todo por que es la primera vez que programo en Delphi y soy todavía estudiante...
Un saludo

[[Delphius]]

Pues si sabes de OO no creo que te resulte complicado pasar lo que tienes a algo más OO.

La cuestión está en organizar las clases en sus respectivas units de modo en que se respete o se mantenga tanto un Bajo Acoplamiento como una Alta Cohesión.

Si tienes todos en forms, la cosa pasa por tanto en separarlo apropiadamente.

Nada te impide tener en tus units "sueltas" (es decir, units sin estar asociadas a un form) con tus clases y sus respectivas implementaciones.

Repito nuevamente, si lees el capítulo que Ian Marteens dedica sobre POO vas a entender mejor como se organizan las units y las clases.

Y si ya tienes tus diagramas, ¡ya tienes la mitad hecha!

Pero dejame decirte que sin tener algo más tangible de como estas haciendo tus cosas... ¿de que modo te podremos ayudar?

No es por ser pesado... pero no veo entonces donde está el problema. Sabes de OO e UML, lo que resta es en todo caso definir tus clases en sus respectivas units.

Lamentablemente sin ver lo que tienes, y como lo estás haciendo no podemos ayudarte. "Simplemente" no hay una receta que te diga... este método viene aquí, este acá, y este otro allá...

Quizá la pregunta a realizarte es esta: ¿Concretamente, en que tienes dudas?

Perdona pero, yo al menos, no se de que forma te puedo ayudar si no concretas algo.

Saludos,

[[AzidRain]]

Meto mi cuchara (o cucharón...jejeje) No olvidemos que ni OOP ni programación estructurada y hasta UML no son la panacea. Es cierto que cada uno tiene sus pros y contras, pero al final no dejan de ser meros paradigmas. Muchas veces tenemos algo funcional y muy optimizado y al querer migrarlo hacia otro paradigma terminamos con algo que ni es funcional y mucho menos optimizados.

Antes de hacer alguna migración de este tipo conviene hacerse algunas preguntas:

¿El código que tengo ya no me proporciona las herramientas que necesito para mejorar mi programa?
¿El nuevo paradigma lo entiendo mejor que el anterior?
¿El resultado final (lo que hace el programa) será mejor tan solo por cambiar de paradigma?

Por decil algunos....Aclaro que me refiero a desarrollos profesionales (de los que se cobran) ya que si es algo didáctico entonces si no hay impedimento para aventarse e ir conociendo un uevo paradigma desde uno que ya conocido.

El caso de los forms que contienen lógica de negocios resulta interesante porque en ocasiones son una solución muy sencilla y rápida para tener nuestro código modularizado, digamos que tenemos un formulario TFactura que contiene un método Muestra que acepta como parámetro un número de factura. El formulario, o màs bien la clase, se encarga de todo lo necesario: ir por el registro al datamodule, cargarlo y mostrarlo. De manera que en cualquier parte de nuestra aplicación que necesitemos mostrar una factura, simplemente usamos ese formulario sin mucha complicación. Aunque esto violaría muchos principios en otros paradigmas, es sin embargo, un paradigma válido ya que se cumple la función. Es perfectamente mantenible porque cambiado el formulario cambiamos todo el comportamiento en cualquier parte de la aplicación y además es transportable a otras aplicaciones similares.

Otro punto a considerar es que el IDE de Delphi no está precisamente orientado a hacer uso extensivo de OOP (aunque trae muchisimas ayudas para ello en sus últimas versiones). El IDE desde su nacimiento se enfocó a desarrollar aplicaciónes rápidamente (RAD) por lo que muchas cosas se pasan por alto, por ejemplo el Binding y los controles de acceso a datos, con ellos se hacen formularios de captura rápidamente pero se "violan" otros paradigmas.

En fin, que considero que en el desarrollo de aplicaciones a nivel profesional es mejor tomar un poco de cada paradigma y utilizarlo correctamente para que nuestro código sea mantenible y sencillo para nuestros propósitos.