Como implementar un Procedimiento Compartido

[NEG1414]

Buenas..

En mi Aplicacion Tengo un procedimiento (Extenso) que que va a ser utilizado por varias clases diferentes, ¿creo una nueva clase con solo ese procedimiento?, ¿incluyo la el procedimiento en una de las clases y accedo a el incluyendo la clase contenedora en las demas?, ¿Hay otras posibilidades?

Nota: Necesito que mientras se esta ejecutando el procedimiento , la clase que hace uso de el pueda seguir recibiendo "mensajes" (actividad del raton, actividad del teclado....)

Espero Haberme explicado bien...
Gracias

[[escafandra]]

A la primera pregunta he de contestarte que depende. Si todas las clases tienen algo que las agrupa sobre una base común, puedes crear una clase base con ese procedimiento y derivar las demás.

Desde mi punto de vista, crear una clase con solo ese procedimiento no tiene sentido, mejor lo dejas suelto y escribes menos.

Empezado por NEG1414

Necesito que mientras se esta ejecutando el procedimiento , la clase que hace uso de el pueda seguir recibiendo "mensajes" (actividad del raton, actividad del teclado....)

Esta cuestión la resuelves de dos formas:
1. Colocar Application->ProcessMessages() en el código bloqueante de mensajes, una o varias veces.
2. Ejecutar en un hilo a parte dicho procedimiento.


Saludos.

[NEG1414]

Muchas gracias por contestarme...

No entiendo que quieres decir con "dejarlo suelto".. podrías aclarármelo..

Gracias Otra vez.

[[AgustinOrtu]]

Yo crearía la clase. No me gusta los procedimientos sueltos

El ProcessMessages esta prohibido. Yo crearía un hilo que ejecute el método

[[escafandra]]

Al decir, dejar el procedimiento suelto, quiero decir, no asignarlo a clase alguna. Pero todo depende de la estructura de clases que tengas.

Se ve que AgustinOrtu es un enamorado de la POO...

Aunque ProcessMessages es mucho menos elegante y eficiente que un hilo paralelo, es mucho más fácil de implementar y... prohibido, prohibido, no está. Aunque, personalmente, prefiero hilos.

Saludos.

[[AgustinOrtu]]

El problema amigo escafandra es que tarde o temprano resulta mas redituable el crear clases que procedimientos sueltos

Uno no sabe en que puede terminar el procedimiento, resulta que mañana te pasa que: si tengo X entonces hace Y, si tengo W hace Z, eso al instante se viene a la cabeza. Usa herencia y redefine el metodo!

La cosa es que una vez que uno se acostumbra a hacer objetos para hacer todo ya me resulta raro ver un "procedimiento suelto", simplemente no esta en mi diccionario por decirlo de una manera.

Que pasa si en tiempo de ejecucion tengo que llamar distintas versiones del procedimiento? Bueno con POO podes atacar mucho mejor ese problema. Si seguis con el procedimiento suelto no tenes herencia y no tenes polimorfismo; es volver a la programacion estructurada y al copy paste

Ademas, de que en el caso de utilizar hilos, se convierte en algo mucho mas sencillo si se usa una clase; en Delphi, los eventos te obligan a implementarlos en una clase (procedure xxx of object) entonces en los tipicos casos de mostrar "procesando, espere" es mucho mas sencillo tener:

a. La clase que hace el proceso y que avisa cuando termina (procedure of object)
b. El hilo que usando la clase corre el metodo procesar en segundo plano y cuando termina dispara el evento


Simplemente mis 2 granitos de arena

Un procedimiento suelto vendria a ser como las funciones IntToStr, esas funciones no estan implementadas en ninguna clase. La sintaxis seria:

Código Delphi [-]
unit XXX;

interface

function Foo: string;

implementation

function Foo: string;
begin
  Result := 'Foo';
end;