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.

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:


unit XXX;

interface

function Foo: string;

implementation

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

[AgustinOrtu]

El problema del ProcessMessages es que no es multi-hilo real. Sigue todo secuencial en el mismo hilo

Ejemplo burdo:


while Boolean do
begin
DoWork; // tarda por ejemplo, 5 segundos
Inc(PercentDone);
RefreshUI(PercentDone);
Application.ProcessMessages;
end;


Eso quiere decir que el ProcessMessages se ejecuta cada 5 segundos; osea la UI se actualiza cada 5 segundos. Es decir, la aplicacion queda "tildada" y responde a los eventos del mouse, teclado, etc, cada 5 segundos.

Lo de prohibido quiza si, es un poco de malvado de mi parte, pero no me gusta recomendar algo que se que es ineficaz

[escafandra]

No siempre ocurre ese caso y siempre se puede colocar más de una llamada a ProcessMessages. En algún caso puede ser útil.

Evidentemente, es secuencial, por lo que es preferible usar hilos para aquellas tareas que van a demorar el procesamiento mensajes Windows y que provocarán la falta de respuesta de la aplicación. Estamos de acuerdo, pero puesto que existe no se puede dejar de mencionar, si bien subrayando sus carencias. ;)

Saludos.

[escafandra]

En cuanto al uso exclusivo de clases discrepo. Una librería de funciones generales es tan útil como una librería de clases. Todo depende de la función.

Una función general es mucho más portable entre distintas app que la perteneciente a una librería de clases. Mi forma de programar es saltar de alto a bajo nivel sin complejos, en aquellas tareas que lo requieran. POO no es dogma de fe. En ocasiones es excelente elección. En otras un engorro.

VCL está orientado a objetos, es lógico que sus eventos requieran una clase, pero nada te impide crear eventos con una función calback tradicional. La API de Windows es un ejemplo.

La programación, bajo mi punto de vista, debe ser plástica y adaptarse a cada necesidad. La rigidez muchas veces complica lo sencillo. :)

No estoy ni a favor ni encontra de POO simplemente uso ambas, según la necesidad. Y aunque discrepen muchos, me gusta más la POO de C++ que delphi. :)

Saludos

[Toni]

Los dos teneis vuestra parte de razon. Como en todo hay que buscar un equilibrio. Yo tambien soy pro POO pero en ocasiones te puede complicar la vida, tanto como en otras es la mejor solucion. We water my friend! :D

[escafandra]

Los dos teneis vuestra parte de razon. Como en todo hay que buscar un equilibrio. Yo tambien soy pro POO pero en ocasiones te puede complicar la vida, tanto como en otras es la mejor solucion. We water my friend! :D

Pues eso mismo trato de explicar... :D

Saludos.

[Al González]

Concuerdo con la mayor parte de lo dicho por escafandra, a quien me da gusto tener ocasión de saludarlo, por cierto. :)

Sin quitar demasiado valor a las motivaciones de AgustinOrtu. ;) ^\||/

Debo confesar que yo mismo me encuentro en esa encrucijada, que se pone delante de todo programador bibliotecario surgido antes de la POO: Habiendo ya creado un considerable número de clases me pregunto (https://twitter.com/algonzalez74/status/655131334961008640) si valdría la pena convertir mis cientos de funciones sueltas en métodos de una o varias clases de utilidad.

Perdón si con esto me sumo al desvío del tema, de un asunto doméstico de C++Builder hacia un tema algo más general —pero demasiado importante como para no ser debatido—.

Saludos.

[escafandra]

Encantado de volver a leerte, Al González :). Es cierto que muchas veces surgen dudas de ese tipo. Soy de los que piensan que si las ventajas son dudosas ¿por que hacerlo?. En realidad todo depende...

No creo que el tema esté desvirtuado, pues es la duda que se plantea NEG1414 y que tantas veces nos planteamos todos. Como bien dices, es lo suficientemente importante como no dejarla pasar por alto. Todas las opiniones cuentan y seguro que a NEG1414 le aportan mucho.

Saludos

[NEG1414]

Gracias a todos por participar en el hilo que he abierto...

Desde el punto de vista de un programador autodidacta y relativamente novato en la POO creo entender la postura ortodoxa de AgustinOrto respecto a los "procedimientos libres" que considera males necesarios (o no) que distorsionan la estructura "armonica" de la progrmacion orientada a objetos, refuerza esta opinion cuando escribe "El ProcessMessages esta prohibido".

Personalmente senti la misma "aprension" cuando surgio la programacion visual a la que consideraba ideada para "niños , acostumbrado como estaba a escribir linea tras linea sobre una pantalla totalmente negra teniendo como unica referencia un punto parpadeante.... el tiempo como en todo en la vida te hace ver lo equivocado que estabas..

Creo que lo fundamental en una aplicacion es que funcione... el como es importante pero hay que ser flexible (lo dice alguien que en una epoca estaba obsesionaba con llegar al mismo fin con el minimo de numero de lineas de codigo) , muchas veces seguir caminos menos "higienicos" producen un resultado optimo, que nos ahorra tiempo y trabajo (al fin y alcabo el "pecado" queda entre tu y tu conciencia).

Respecto a la cuestion inicial voy a optar por la opcion del "Procedimiento Libre" me parece sencilla y efectiva, respecto al segundo punto, el de mensajes, en el problema que me atañe le doy la razon a AgustinOrto, no me vale y lo explico..

Tengo un Form padre en el que tengo una barra de progreso y una serie de botones tengo un form hijo, tambien con una serie de botones, en los dos capturo mensaje raton y si lo deseo hago que los botones del raton esten anulados de la forma (gracias Leo)

void __fastcall AppMessage(MSG &Msg,bool &Handled);

_fastcall TFHijo::TFHijo(......,TProgressBar *PB,.......): TForm(Owner)
{

//Leer Mensajes
Application->OnMessage = AppMessage;

}

void __fastcall TFFiltros::AppMessage(MSG &Msg, bool &Handled)
{
if((WM_LBUTTONDBLCLK == Msg.message || WM_LBUTTONDOWN == Msg.message) && !BotRatonAct)
{
Handled = true;
}
}
desde el padre accedo al hijo de dos formas: modal (visualizandolo) o llamando directamente a un constructor, pasndole como uno de sus parametros la barra de progreso.
Accediendo de la segunda forma en el form hijo (sin visualizarse) se realizan una serie de procesos y a medida que estos se realizan la barra de progreso en el form padre avanza (hasta aqui todo correcto), el problema surge cuando hago click con el raton, la teoria era que al estar procesando datos en el forn Hijo, cualquier accion con el raton sobre componentes del form Padre fuera nula, ya que el formHijo recebiria el mensaje y lo anularia(BotRatonAct = false), el caso es que para mi sorpresa al hacer click con el raton sobre cualquiera de los botones del FOrm Padre estos se accionan...:( No Vale...

Gracias a todos o tra vez y recuerden...

La ignorancia es un mal que se cura preguntando.