Cita:
Empezado por Kenobi
Que mas puedo decir Gracias....
Ahora bien delphi aplica la POO directo en su funcionamiento, la pregunta que me falta responder es ....tiene algun sentido crear algo asi como clases para implementar labores regulares tales como abrir,cerrar,buscar,modificar
o sea no se si soy claro pero vale la pena enrollarse con esto y cual es el beneficio añadido a hacer lo que procedimentalmente se acostumbra . que es
en mi caso ...
creo varios procedures y funciones con parametros (algunos de tipo objeto)
los cuales llamo desde los eventos de los controles ....
aun asi Gracias .....
|
Hola Kenobi, es bueno que te hayas preguntado eso. Y la respuesta más certera... es un depende.
Cuando uno se mete en la POO empieza a preguntarse sobre si la relación Costo/Beneficio , Esfuerzo/Tiempo es viable.
Primeramente deberías preguntarte, en que medida, los métodos abrir, cerrar, buscar, modificar, que mencionas te permiten reutilizar y minimizar código y acelerar tu trabajo.
En ocasiones un enfoque estrictamente purista es más costoso para proyectos chicos, y que poseen poco mantenimiento. Pero para un proyecto enforme o relativamente grande, un enfoque más centrado hacia la POO es más útil.
Yo, a grandes rasgos distingo dos tipos de clases:
Clases de propósito general
Clases del dominio
Las primeras son aquellas clases que implementan métodos que pueden servir de propósito general a cualquier aplicativo. el framework que posee Delphi, su VCL es un buen ejemplo. Pero no termina en la VCL, uno puede definirse sus propias clases para estos propósitos. Un framework de persistencia es otro ejemplo.
Y las segundas son las clases diseñadas para dar respuesta al dominio o ambiente. En pocas para representar la solución del problema. Por ejemplo, un diseño estructurado en POO para dar respuestas a un sistema de control de tráfico aereo (si... un ejemplo grande) o el diseño de un control de inventario.
Ahora bien, existe un "peligro" de que clases del dominio se conviertan en clases de propósito general. Dije "peligro" porque no necesariamente es un problema. El problema se presenta cuando uno se prepara para el cambio.
Por poner un ejemplo. Digamos que tengo en mis manos un pequeño "framework" que permite trabajar y aplicar conceptos sobre técnicas de simulación. Este framework tiene el potencial de ser parte de un sistema único como puede ser aplicable a muchos enfoques.
¿De de que se trata? ¿De algo de propósito general? ¿O algo exclusivamente para un modelo en específico?
Lo hago más simple... una clase TCliente ¿Es una clase que sirve como propósito general?¿O por el contrario, está concebida para ser usada en un sistema de Gestión?
Un diseño estructurado en una jerarquia amplia y sólida tiene una misma ventaja y desventaja.
Al ser un diseño rígido nos trae la ventaja de que se posee clases estables. Pero además, puede llegar a limitarnos y cabe la posibilidad de dificultar ampliar la jerarquia o aplicar ciertos cambios.
A su vez, un diseño blando tiene la dificultad de sus clases están debilemente diseñadas y no son muy estables, tendiendo a "explotar" cuando cambiamos algo en otro lado. Pero a su vez, puede que nos haga más fácil nuevas adaptacaciones.
El punto es que no hay un diseño único que nos garantice que todo va a funcionar. La experiencia que adquiere uno con el tiempo nos lleva a buscar un equilibrio entre lo rígido y lo flexible.
Como lo dice la frase de Tao, señalada a el libro UML y Patrones:
Cita:
|
Empezado por Tao Te Ching
Lo duro y rígide se rompe. Lo flexible prevalece
|
Esto no quiere decir que debas optar por un diseño débil entre las clases. Sino que representa la idea de buscar ese equilibrio.
No puedo decirte si tiene sentido hacer lo que haces, tendría que verlo, y aun asi... no me atrevería a juzgarlo demasiado. Puesto que una buena dosis de realidad que me ha demostrado en este tiempo que llevo aprendiendo sobre POO que no existe un diseño bueno o malo.
¡Bienvenido a la subjetividad!
Si tus clases te permiten armonizar cómodamente a ti el trabajo, ese diseño para ti es bueno. Puede que a mi, tu diseño me indique otra cosa.
Si tu tienes 20 clases y te funciona, perfecto. Si yo tengo 30 y me funciona también... perfecto.
¿Es mi diseño más complejo que el tuyo? Es posible, o guarda... puede que el mio en realidad sea más simple. Todo dependerá de como estén trabajando tus clases.
No es lo mismo 20 clases trabajando para dar respuesta un problema que 30.
¿Se entiende a lo que quiero llegar?
Tus 20 clases es posible que estén mucho mas acopladas que mis 30. Por otro lado yo corro el riesgo de tener clases inútiles que poco aportan al dominio, y todo por conseguir un bajo acoplamiento.
Ahora, ¿es lo mismo que yo 15 y tu 20?
Otra vez hay que analizar. Quien sabe... es posible que algunas clases que tu definiste es mejor generalizarlas en una o dos. Y esto puede también afectar tanto al acoplamiento como la cohesión.
No se puede separar el acoplamiento de la cohesión. Si bien no son dos caras de la misma moneda, uno afecto a otro.
Si fuedes generalizar o factorizar clases, hazlo.
Recomiendo que le des una leída al libro UML y Patrones. Una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado. Su autor es Craig Larman. En cualquier librería o biblioteca dedicada a informática lo puedes encontrar. En un libro de cabecera muy solicitado.
Este libro puede ayudarte a ver la POO desde otra perspectiva.
No quiero despedirme de este post sin antes preguntarte algunas cosas, puesto que me invade la duda... ¿hace cuanto estás metiendote en este de POO? ¿Tienes toda tu lógica de negocio o dominio implementada en los forms y/o datamodules?
Estas preguntas te las digo para saber que tanto estás asimilando de estos conceptos. No todos es formas y controles. Por ello sugiero practicar el diseño de objetos fuera de lo que es la VCL, definiendo tus propias clases. Me parece que esa es una buena de analizar si uno está entiendo bien las cosas.
Saludos,