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

[Kenobi]

La verdad entiendo por encima esto de la POO pero de alli a saber implementarla nada que ver ... es por eso que me permito colocarles aca unos procedimientos y funciones sencillos (de esos que uno usa) para ver si alguno de ustedes propone la trasformacion de estos a el paradigma de POO y asi ver de forma practica la trasformacion de un codigo a otro y entender cual es el beneficio de una forma de programar frente a la otra(tradicional, procedimental etc)

OJo las rutinas son muy sencillas...esa es la idea para que se entienda facil...

Código Delphi [-]
procedure TForm2.Modificar(Id: string);
begin
   if Buscar  then
   Begin
   Tabla.edit;
     TablaCampo1.value:=Valor1;
     TablaCampo2.value:=Valor2;
     TablaCampo3.value:=Valor3;
     // ......
     // .....
     // ...

     Tabla.post;
   End
   else MiMensaje('No encontrado');

end;

Function TForm2.Buscar(Id: string):Boolean;
begin
   if Tabla.locate('Id',Id,[]) then result:=True
                                else result:=False;

end;

procedure TForm2.MiMensaje(Texto: string);
begin
   application.MessageBox(Texto,'Aviso del Sistema',MB_OK);

end;

Espero que alguien se tome la molestia asi aprendo de una vez por todas porque con los libros la información queda algo esoterica.....

Gracias .....
P.D: si pueden explicar lo que hicieron pasito a pasito para nosotros los bruticos ....y hacer algo asi como una justificacion de lo que proponen (se que es mucho pedir pero que le vamos a hacer hoy llegue mendigo y sinverguenza)...

[Kenobi]

....?
....?
....?

[[felipe88]]

Pues amigo kenobi quedo igual ???

No se a que viene el "Paradigma de la POO" con el codigo que nos muestras... representarlo como?... conceptos de Clases, Herencia, Polimorfismo... etc. ??

Si quieres algo que te ponga a prueba en estos conceptos, te recomiendo Java

[RolphyReyes]

Saludos.

Pues te puedo recomendar que leas el libro de Ian Marteens, La Cara Oculta de Delphi 4. Si mal no recuerdo creo que esta en el wiki del club y de paso aprovecha unos ejemplos que tienen en el mismo.

[[Delphius]]

Hola Kenobi,

Disculpame si me excedo o me extiendo demasiado al tratar de explicar el asunto.

El tema es que es un tanto complicado entenderlo con los forms. Crease o no, lo que tiene ese código es POO. El tema está en que no es tan fácil verlo.

Analicemos parte por parte para ver si se logra entenderlo ¿OK?

1. Primera cuestión: Cuando uno añade un nuevo form (File -> New -> Form), está definiendo una clase, que desciende por lo general de la clase TForm. Es por ello que en la unit aparece algo como esto:

Código Delphi [-]
type
  TForm1 = class(TForm);
  ...

En este caso definimos una clase llamada TForm1. Que inicialmente aparece vacía.

2. Al ser una declaración, más no un objeto, necesitamos una variable de dicho tipo (Form1) para trabajar con la clase. Esto no los hace Delphi solito, y puede verse más abajo:

Código Delphi [-]
var
  Form1: TForm1;

Entonces, ya tenemos nuestra clase y una variable para trabajar con ella.

3. ¿Cómo y cuando se crea? Por regla general Delphi cuando uno añade una Form (no quiero usar el término crear puesto que se contradice con el verdadero significado en POO) se encarga de ello. Ve a la unidad dpr. Uno observa esto:

Código Delphi [-]
program Project1;

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Si observas, en uses tenemos declarada el nombre de la unidad correspondiente al form. Y más abajo, una vez que se inicia la aplicación, se invoca al método CreateForm con los parámetros TForm1 y Form1. Si recuerdas, Form1 es la variable definida en la Unit1.

He dicho antes "Por regla general", y esto es así debido a que no necesariamente todas las forms van a crearse automáticamente al iniciarse la aplicación. En ocasiones necesitaremos dar nosotros el control de cuando y donde crearse, por tanto necesitamos eliminar del dpr dicha declaración y dar la orden explicitamente de cuando crear una form. Para ello hay dos opciones:
1. Nos vamos a Proyect -> Options -> Forms y trasladamos los Form1 necesarios a la parte Available Forms.
2. O bien, simplemente borramos en el dpr los CreateForm que sean necesarios.

Una cuestión interesante a tratar es el manejo de forms en forma modal, y si es un entorno MDI o MSI. Cuando uno crea una instancia de un Form debe tener presente si ciclo de vida. Estas son cuestiones que escapan un poco al tema, hay hilos que debaten estas cuestiones técnicas (un tema que en ocasiones se deja de lado).

Por mi parte voy a seguir el tema más cerca de POO.

Bueno tenemos un clase vacia, una variable, y en caso más simple... dejamos a Application que se encargue de crear y liberar los forms. Necesitamos ahora darle vida a esta clase. Vamos al punto 4.

4. Dandole vida a nuestra clase.
Cuando uno añade controles a la clase, le está definiendo campos. Por defecto Delphi asume la visibilidad publica. Por tanto cuando veas esto:

Código Delphi [-]
type
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    Memo1: TMemo;
 ....

Quiere decir que Button1, Edit1 y Memo1 son campos públicos. Cada campo es de un tipo. Button1 es de tipo TButton, y asi sucesivamente.

Como tipos, son definiciones de más clases. Por tanto, cuando uno añade un control está colocando un "objeto" y le está indicando que su dueño es el form al que fue añadido.

Dije "objeto". Pero en realidad no lo es... ¿marea un poquito no es cierto? Veamos.... Si Form1 es una variable, Button1 también lo es. De hecho, un campo es una variable.
El problema es que Delphi lo hace tan automático, y tan fácil la vida que nos hace creer que tenemos objetos. La realidad es que cuando se cree el Form, recién tendremos los objetos Button1, Edit1, Memo1.

¿Recuerdas que antes dije que el Form es el dueño? Este es el comportamiento por defecto que asume el compilador. Como dueño, Form1 tiene la responsabilidad de crear y liberar o destruir (son cosas un tanto diferentes, por ahora podemos asumirlas como sinónimos) los controles hijos que posee.

Aun no tenemos definido el comportamiento. Tenemos controles declarados. Veamos que hace cada uno.

Como controles, cada uno cumple su función o rol. Un Button1 cumplirá los propósitos de un botón, un Edit1 el de un cuadro de texto, etc. En el inspector de objetos, cuando seleccionamos algún componente, aparece una lista de propiedades y eventos.

La regla general dice: las propiedades nos permiten tener acceso (de lectura y/o escritura) a los campos privados de dicho objeto. Dependiendo del valor de dichas propiedades el control se mostrará (y actuará) de una u otra forma.
Los eventos son una serie de mensajes programables que se envían y reciben al SO. Acabo de decir una verdad a medias.

Pongamos un ejemplo. Cuando uno hace clic en un botón, el form recibe dicho mensaje y se lo envia a un objeto intermediario entre él y el SO. ¿Recuerdas aquel Application? Es este desconocido quien actua de intermediario.

Entonces: pulsamos en el botón, este envia el mensaje al form, el form a Application y Application al SO. Luego el SO responde, se lo hace saber a Application, éste al Form y luego al botón.

En realidad un evento es un puntero a un método. Asusta un poco esa palabra. Los eventos son acciones que se van a hacer cuando sucedan dichos mensajes que se envian. No estás obligado a usarlos. Simplemente el compilador interpreta que si no se asignó algo al evento, lo ignore y siga su paso.

Cuando algo en control (mejor dicho objeto) cambia, este envia mensajes... cuando se detecta el mensaje se pregunta si hay algún interesado en hacer algo. Veamos un caso práctico: Pulsa doble click en el Edit1.

Vemos en la unit esto:

Código Delphi [-]
type
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    Memo1: TMemo;
    procedure Edit1Change(Sender: TObject);
...

procedure TForm1.Edit1Change(Sender: TObject);
begin

end;
...

¿Que sucedió? Simplemente se ha añadido un método al form. En este caso, se llama Edit1Change. Y en la sección implementation vemos que se ha dado la estructura básica al método. Es allí donde definiremos que y como interpretar un mensaje. Le estamos dando una respuesta.

Constantemente los controles dan y reciben mensajes. Si estamos interesados en interceptar alguno, simplemente tenemos que declarar una respuesta: un método. Internamente, un puntero apuntará al método que hemos declarado y ejecutará dichas rutinas.

Si te fijas, en la implementación de este método se ve un TForm1.EditChange. Esto quiere decir que en este caso, quien dispará el método es TForm1. Se lo denomina Emisor. A continuación aparece Edit1Change. Esto quiere decir que el receptor del evento onChange es Edit1.

En un evento tiene lugar el emisor y el receptor. No necesariamente deben ser objetos distintos. Por ejemplo, al declarar un método al evento OnClose del Form se ve claramente que el emisor y el receptor son Form1.

Delphi nos hace la tarea más fácil al ocultarnos los mensajes (algo un tanto más complejo. No estoy demasiado puesto en el tema, y no viene mucho al caso)... simplemente nos limitamos a dar respuesta. Los controles que añadimos a un Form son intermediarios, y dan más funcionalidad al objeto TForm1.

Bueno sigamos.... estuve hablando de eventos y métodos. Los métodos no necesariamente son para dar respuesta a los mensajes que se envian y reciben desde el SO. Pueden ser simples procedimientos y funciones que se le declaran al emisor para cumplir con los propósitos para los cuales a sido definido.

Por ejemplo, si nuestro TForm1 está pensado para hacer operaciones de búsqueda tal vez nos interese tener un método Buscar, un método BuscarSiguiente, etc.

Si esos métodos son procedimientos o funciones, eso es ya a gusto y necesidades de implementación. Lo importante es definir la visibilidad y alcance de dichos métodos. Un ejemplo:

Código Delphi [-]
type
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    Memo1: TMemo;
    procedure Edit1Change(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    { Private declarations }
    FTexto: string;
    function SoloTexto: boolean;
  public
    { Public declarations }
    procedure Buscar(Texto: string);
    function BuscarSiguiente: boolean;
  end;

He declarado un campo FTexto y un método SoloTexto con visibilidad privada. Hay dos métodos públicos: Buscar y BuscarSiguiente.

El propósito es ocultar guardar en FTexto el texto a buscar, SoloTexto se encargará de determinar que el contenido a buscar sea exclusivamente texto y no se permitan numeros y caracteres extraños. SoloTexto será invocado internamente por Buscar (no es necesario, al menos según este análisis, que SoloTexto sea declarado público).

En tu caso definiste los métodos Buscar, MiMensaje y Modificar.

El objetivo de los métodos es para disparar nuevos métodos o enviar mensajes hacia otros objetos a que hagan algo (estos mensajes son diferentes a los que se envian al SO, no confundirlos).

Por ejemplo, cuando uno tiene algo como esto:

Código Delphi [-]
procedure TMiObjeto.HacerAlgo(Valor: integer);
begin
  ObjetoEsclavo.HacerEsto(Valor);
end;

Le está dando el mensaje de HacerEsto a ObjetoEsclavo. Luego, ObjetoEsclavo realizará dicho método.

Espero que se vaya entendiendo el asunto.

Un objeto puede tener propiedades, campos, métodos, eventos. Como y que hacer... eso es ya cuestiones de implementación.

TForm1, como una declaración de una clase, puede tener nuevos métodos, propiedades, campos, y eventos. Es más hasta se le puede aplicar herencia. Tranquilamente podemos tener esto:

Código Delphi [-]
TFormHijo = class(TForm1);
...

El tema de la herencia, ya sería un poco más rebuscado y se sale de esta ya extensa explicación (y aún no se si con esto se entiende el tema).

Sugiero que practiques el tema de POO definiendo tus objetos fuera de los forms. Define tus propias clases y practica. Como te han sugerido, lee la cara oculta. Allí está explicado en el capítulo 6 el tema de POO. Creo que con lo dicho por Ian Marteens y esto, y una búsqueda en los foros sobre este tema (en otras ocasiones se lo ha tratado) se puede entender mejor.

Disculpen el rollo que me he mandado.

Saludos,

[[felipe88]]

Amigo Delphius, te sobraste con esa respuesta ... quien lo habria pensado y explicado mejor.

[roman]

Hola Delphius,

No entiendo esto del emisor y receptor. ¿Que el emisor (sender) en TForm1.EditChange no es el mismo Edit?

Yo tenía la idea de que si un objeto A llama al método M de un objeto B:

Código Delphi [-]
// desde algún método de A

B.M;

entonces A manda el mensaje M a B, siendo A el emisor y B el receptor.

¿Cómo es en este caso?

// Saludos

[esocrates]

Me sumo al agradecimiento a Delphius por esta estupenda lección.
Un saludo a todos

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