Programacion orientada a Objetos...duda total....

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

[[Delphius]]

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:

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,

[mamcx]

Otra cosa:

La POO cuando es algo que debe venir de forma natural. Siempre me ha parecido que es un atentado a la educacion cuando a la gente en su curso introductorio le dan el tema del polimorfismo o de patrones y todo eso. Es como uno estar en un curso de cocina y que empiezen por explicarle las diversas famialias de frutas, verduras, carnes, condimentos y todo eso.

Lo unico que hay que saber para ser un "duro" con la programacion es esto:

* Los sustantivos son los nombres de las clases (ej: Ventana, Cliente)
* Los adjetivos, sus propiedades (Alto, Ancho)
* Los verbos son las acciones que:
- Si son verbos directos, metodos (Close)
- Sin son verbos preguntones, funciones (CanClose())
- Sin son verbos de "momentos" son eventos (WhenClose())

Usar nombres claros y directos. Si pones:

EsActivo

y lo documentarias como:

Funcion que determina si el cliente es valido

entonces dejate de bobadas y cambialo por

EsValido

y te ahorraste la documentacion

- Haz pedazos de codigo que sean concisos y se dedican a una sola cosa.

- Haz clases que se encargen de mover las acciones de un lado a otro. Clases de control (ej: Para mover un inventario). No mezcles clases que controlan con clases que informan o que definen una entidad simple a menos que haya muy poco que controlar.

- Haz codigo testeable. Metete en el asunto de TTD (Test Driven Desing). El resultado de un codigo testeable es casi sin equivocacion una excelente POO.

- Cuando creas que algo esta mal hecho, esta mal hecho.

- No uses ejemplos de Java o C* para aprender OO. Por regla general son muy complicados. Lee pascal, o python. Son los lenguajes que por regla general tienen las soluciones mas sencillas posibles

Leete y aprendete el Zen de python, y aplicalo en Delphi:

* Bello es mejor que feo.
* Explícito es mejor que implícito.
* Simple es mejor que complejo.
* Complejo es mejor que complicado.
* Plano es mejor que anidado.
* Disperso es mejor que denso.
* La legibilidad cuenta.
* Los casos especiales no son tan especiales como para quebrar las reglas.
* Aunque la practicidad le gana a la pureza.
* Los errores nunca deberían dejarse pasar silenciosamente.
* A menos que hayan sido silenciados explícitamente.
* Frente a la ambigüedad, rechazar la tentación de adivinar.
* Debería haber una -y preferiblemente sólo una- manera obvia de hacerlo.
* Aunque esa manera puede no ser obvia al principio a menos que usted sea Holandés.
* Ahora es mejor que nunca.
* Aunque nunca es a menudo mejor que ya.
* Si la implementación es dificil de explicar, es una mala idea.
* Si la implementacion es fácil de explicar, puede que sea una buena idea.

[[Delphius]]

Mario, ¡excelente resumen!
¡Bellísimamente simple! Más directo y preciso de decir, no hay!

Saludos,

[roman]

A ver, un ejemplo-pregunta, porque así como lo dice Mario suena muy fácil, pero..

Tengo un sistema que gestiona las inscripciones de alumnos a distintos cursos. Una inscripción no puede hacerse así como así, debe cumplir ciertas reglas. Puedo tener mis clases Alumno y Curso (mis sustantivos).

¿Dónde hago la inscripción?

Código Delphi [-]
Alumno.Inscribir(Grupo);

o

Código Delphi [-]
Grupo.Inscribir(Alumno);

o bien una clase aparte:

Código Delphi [-]
Reglamento.Inscribir(Alumno, Grupo);

// Saludos

[mamcx]

Donde parezca mejor.

Cuando se trata de modelar un proceso de negocio, probablemente el mismo proceso dice como se hace.

Quien hace la inscripcion? El alumno? El profesor?. (Ok, no es pa' poner una clase llamada TJulianitaLaSecre!). En tal caso seguramente hay un proceso de inscripcion.

Pero si lo UNICO que hace ese proceso es inscribir, pues que bobada hacer otra clase. En tal caso, si no hay un workflow lo mas simple es entender que la inscripcion de un alumno es una forma glorificada de decir: Alumno.... Nuevo.
-------
Yo tambien hice un software para escuelas, que a la fecha ha sido el de mas uso (que yo sepa mas de 3000 escuelas!). Ahora, en esa epoca era mas bien novato, pero en fin....

[[Delphius]]

Empezado por roman

A ver, un ejemplo-pregunta, porque así como lo dice Mario suena muy fácil, pero..

Tengo un sistema que gestiona las inscripciones de alumnos a distintos cursos. Una inscripción no puede hacerse así como así, debe cumplir ciertas reglas. Puedo tener mis clases Alumno y Curso (mis sustantivos).

¿Dónde hago la inscripción?

Código Delphi [-]Alumno.Inscribir(Grupo);


o

Código Delphi [-]Grupo.Inscribir(Alumno);


o bien una clase aparte:

Código Delphi [-]Reglamento.Inscribir(Alumno, Grupo);


// Saludos

Empezado por mamcx

Donde parezca mejor.

Cuando se trata de modelar un proceso de negocio, probablemente el mismo proceso dice como se hace.

Quien hace la inscripcion? El alumno? El profesor?. (Ok, no es pa' poner una clase llamada TJulianitaLaSecre!). En tal caso seguramente hay un proceso de inscripcion.

Pero si lo UNICO que hace ese proceso es inscribir, pues que bobada hacer otra clase. En tal caso, si no hay un workflow lo mas simple es entender que la inscripcion de un alumno es una forma glorificada de decir: Alumno.... Nuevo.
-------
Yo tambien hice un software para escuelas, que a la fecha ha sido el de mas uso (que yo sepa mas de 3000 escuelas!). Ahora, en esa epoca era mas bien novato, pero en fin....

Hola,
Pues no se si lo interpreto adecuadamente... pero por lo que entiendo... si no existe o no se tiene conocimiento de que exista un motivo en particular para decir que el proceso de incripción aporta valor al negocio, entonces tener esa tercera clase no aporta nada. No tiene sentido.
Ahora con respecto a cual de las otras dos opciones es válida, yo deduzco ,por la breve descripción de roman, que es preferible la primera opción que a la segunda.
Me parece más apropiado semanticamente hablando decir:

Código Delphi [-]
Alumno.Inscribir(Grupo);

que decir

Código Delphi [-]
Grupo.Inscribir(Alumno);

Ahora bien, si existe una buena razón para justificar que la presencia de este proceso tiene cierto valor de negocio, y si obedece a ciertas reglas, entonces a mi modo de ver es preferible tener una clase TReglaIncripcion.
Y el modo que emplearía para saber si se cumple dicha regla sería algo asi:

Código Delphi [-]
procedure TAlumno.Inscribir(Grupo: TGrupo);
begin
...
if ReglaInscripcion.IncripcionValida(Self, Grupo)
  then Inscribir(Grupo)
  else ....
...
end;

Es decir, dejo a la clase TReglaInscripcion que determine si es válido el proceso. Ya como está implementada esta clase no viene al caso. Tal vez, tenga clases TReglasNegocio, TReglasNegocioIncripcion, etc... que le asisten en el proceso. No está todo dicho.

En fin creo que se entiende la idea. Yo tendría que saber un poco mejor del dominio para opinar.

Saludos,