Cambio de P.estructurada a POO

[Maria85]

Hola,

Tengo una aplicación en Delphi realizada con programación estructurada.
Ahora me gustaría hacer otra aplicación igual pero orientada a objetos. Lo primero que he hecho es realizar otro diagrama de clases para aclararme de cual será la estructura, pero no se ni por donde empezar a cambiar el código de sitio...Supongo que el código es el mismo pero con otra estructura,no??

Agradecería si alguien me pudiera dar algún consejo o pauta...

Gracias ante todo y un saludo

[Delphius]

Hola Maria85,
Antes que nada... ¿que tan familiar te son los conceptos OO?
¿Tienes conocimientos en OO?

Ya de por sí, por más "estructurado" que esté tu aplicativo... internamente, por debajo de todo, se lleva POO. Delphi trabaja así, aunque el IDE nos engaña y hace lo posible para hacernos las cosas fácil y por tanto se nos termina olvidando que al final de todo... cualquier control que usas es una instancia de alguna clase.

Pasar de una concepción estructurada, sobre todo si se ha seguido casi al pie de la letra el Análisis Estructurado Moderno, hacia POO puede ser tan fácil como difícil.

Si no estás familiarizada con POO sugiero que leas el capítulo 6 (si no falla la memoria) de la Cara Oculta de Delphi 4. El libro (formato pdf) lo puedes encontrar en sección FTP (http://www.terawiki.clubdelphi.com/) del club. Además ya se ha dicho y discutido en muchas ocasiones sobre como seguir un esquema más dirigido hacia POO, no creo que te resulte difícil encontrar algo; si buscas (http://www.clubdelphi.com/foros/search.php) un poco encontrarás.

Ese libro te puede aportar una base sólida.
Luego, si sería bastante recomendable seguir UML.

No te sabría decir al 100% como dar el paso... a mi modo de ver depende de que tan estructurado se haya sido. No hay una receta única.

Por ello es que considero que es mejor que nos comentases un poco más sobre que y como lo estás analizando al tema...

Estoy elaborando y ordenando algunas ideas en mi cabeza, pero antes de soltarlas me gustarías que nos des un panorama. Creo que te podremos dar mejores directivas y alternativas si conocieramos mejor tu caso.

Saludos,

[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

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