Como implementar un Procedimiento Compartido

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

[[AgustinOrtu]]

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

Ejemplo burdo:

Código Delphi [-]
  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!

[[escafandra]]

Empezado por 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!

Pues eso mismo trato de explicar...

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