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

[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

[[Delphius]]

Hola roman,
Tienes razón, metí mal la pata

El emisor es quien envía la orden, el emisor quien recibe.

Lo que debería haber dicho en ese caso, es que en cuestiones de eventos el emisor es quien da la orden, y el receptor es el método que implementamos para dar respuesta a la orden.

Por ejemplo, cuando se ejecuta el evento OnChange en el Edit, el emisor (Sender) es TEdit, y el receptor es el método implementado en el Form; Edit1Change en este caso.

Se me han liado los cables en la cabeza, disculpen.

Muchas gracias por la observación amigo roman

Saludos,

[roman]

Delphius,

De todas formas no puedo menos que estar de acuerdo con Felipe, y aunque comentas que ya sería más rebuscado, yo apreciaría mucho que en un momento de inspiración te aventaras con una breve introducción a OOP, puesto que pienso que entender conceptos como herencia, encapsulamiento y polimorfismo, antes aún que los formularios, es algo que (nos) vendría bien a muchos. Ni qué decir que sería estupendo si incluyes conceptos como composición, asociación, etc., que pocos libros para novatos tratan.

Cuando programamos con Delphi, usamos OOP implícitamente, tal como lo has hecho ver, pero en realidad muchos ignoramos lo que es realmente estructurar una aplicación usando OOP, y una explicación de estas que acostumbras, sería muy ilustrativa para muchos.

Desde luego, no corre prisa

// Saludos