ventajas de componentes en tiempo de ejecución

[Johnny Q]

Un saludo a todos.

Teniendo en cuenta que yo no soy una autoridad en Delphi, ayer me surgio una inquietud: que ventajas puede tener un componente creado en tiempo de ejecución.

Por ejemplo, que beneficios me puede traer crear un ADOQuery en tiempo de ejecución respecto a uno que coloque en el formulario y que me efectue las mismas acciones.

Será esta una pregunta muy sosa, alguien mas habra tenido esta duda, sere demasiado inexperto en Delphi?

Le he hecho esta pregunta a algunos colegas que trabajan con delphi, pero ninguno me ha dado una respuesta muy convincente; que ahorran memoria, que solo se utilizan un momentico, que despues de liberados ahorran recursos, etc. Pero cuando les he dicho que me lo comprueben de alguna manera no han podido demostrarlo.

Gracias por las respuestas y dudas que me puedan resolver.

[Neftali [Germán.Estévez]]

Si utilizas componentes (en éste caso ADOQuery) dentro de un form y liberas el form cuando lo cierras, pues no hay diferencia. Al crear el form se crea el componente (seas tú o el formulario) y al cerrar el form se destruye (seas tú o el formulario).
Normalmente crear componentes en tiempo de ejecución está destinado a cuando en diseño no puedes saber cuantos hay o si lo vas a usar o no, de forma que en ejecución lo creas sólo si lo necesitas.
De todas formas no es algo que se pueda generalizar. Si estás pensando en un caso concreto es cuestión de discutirlo y analizarlo.

[delphi.com.ar]

TIP: La creación será mucho mas veloz aunque no lo notarás. No tiene que leer e "interpretar" los valores del DFM guardado como recurso, en cambio en tiempo de ejecución es 100% código compilado.

En la práctica, yo creo componentes en tiempo de ejecución, cuando la vida del componente será mucho menor que la del form, o mismo cuando creo algún array de componentes... son muchas las posibilidades de evaluar la conveniencia según el caso!

[Johnny Q]

Neftali, la verdad con tu respuesta tengo un panorama más claro, pues la utilidad en tiempo de ejecución podria ser cuando no es fijo el uso del componente.

[dec]

Hola,

Se me ocurren algunas ventajas de usar componentes creados en tiempo de ejecución. Primeramente digamos qué es un componente. Un componente, o lo que conocemos aquí como tal, no es sino otra clase más, otro objeto más (cuando sea instanciado), con la particularidad de que el mismo puede configurarse utilizando, por ejemplo, el Inspector de Objetos de Delphi. Es decir, un componente se diferencia de una clase cualquiera en la capacidad del primero para integrarse en un entorno de desarrollo.

Refiero lo dicho (que puede resultar una obviedad) por no olvidar que un componente es una clase, ni más ni menos, otra clase más que podemos utilizar no solamente "desde el diseñador", sino en cualquier otro momento en que sea necesaria y oportuna su utilización. Pero, bueno, lo que hasta ahora he dicho no es ninguna ventaja y he dicho ya que se me ocurren algunas.

Los componentes, aun los no visuales ocupan. Ocupan un espacio en el formulario en que se añaden (sí, me refiero también a los "no visuales") y más allá ocupan nuestra atención. Quiere decirse que en parte hay que estar pendientes del componente, para asegurar que la configuración del mismo sea la correcta. A mí me está sucediendo en un programa que traigo entre manos que a veces se me olvida conectar un componente con otro. Por ejemplo, quito un componente que estaba conectado a otros. Pego este componente de nuevo (he hecho algunos cambios en la interfaz) y se me olvida conectar el componente en cuestión.

Puede verse cómo un componente "no visual" además de ocupar un espacio (aunque mínimo) ocupa la atención, parte la perspectiva, no sé si me explico. Ahora imaginemos el mismo componente usado en el código, como una clase más, entre el resto de la codificación necesaria, esto es, precisa, para llevar a cabo la tarea que se supone hay que llevar a cabo. El componente (en este caso ya una clase más, puesto que no lo tratamos desde el Inspector de Objetos) está donde tiene que estar, se crea donde tiene que hacerlo, se destruye o no cuando sea necesario y se configura allí mismo, donde es menester su ayuda: no hay que mirar a otro lado, todo está ahí donde tiene que estar.

Pero, en fin. Lo dicho no puede valer como ventaja del uso de un componente como una clase, sin pasar por el Inspector de Objetos, por entendernos. Y cuando lo fuera sería una ventaja, y he dicho ya que veo varias ventajas. El aprovechamiento en cierto modo del "polimorfismo" es una cosa más a tener en cuenta. Se me ocurren unos componentes que he conocido hace unos días y que se dedican al cifrado y descifrado de archivos, cadenas, etc.

Estos componentes (son un par de docenas, al menos) se dividen en dos grupos: "Hashes" y "Algoritmos". Todos los de algoritmos (de cifrado) se representan por componentes no visuales y todos los "Hashes" lo mismo. Si uno quisiera hacer un cifrador/descifrador utilizando todos los algoritmos disponibles y todos los "Hashes" podría optar por situar en un formulario todos los componentes "Hashes" y todos los algoritmos disponibles. Esto puede hacerse, pero también puede hacerse de otro modo.

Puesto que todos los algoritmos descienden de un mismo componente (ya no es tal, es una simple clase, que sirve, como digo, de base a todos los componentes "algoritmos") y todos los "Hashes" descienden también de una clase base, mediante un "case .. of" y el "polimorfismo" podremos hacer lo que pretendemos sin haber puesto un solo componente sobre el formulario. Nos hemos librado de espacio, pero yo creo que no solo de espacio nos hemos librado.

No voy a decir más nada porque creo que otra vez me estoy metiendo en camisas de once varas. Habrá a quien se le ocurran más ventajas, pero, tendré que dejar al menos el pabellón de los componentes alto, me explicaré. No he leído ni en un libro ni en dos (y no he leído muchos) que el desarrollo de programas mediante el uso de componentes, que creo empezó con Visual Basic (Delphi fue una "Visual Basic Killer", tengo entenido también) ha revolucionado, de algún modo, la forma en que se crean programas, ni más ni menos.

O sea que, aunque se encuentren ventajas del uso de componentes como clases (como al fin y al cabo, insisto, es lo que son) también se encontrarán ventajas en el uso de los diseñadores, asistentes, inspectores de objetos y demás herramientas útiles como no puede dudarse. O sea, al César lo que es del César, vamos.

Y no digo más, que luego todo se sabe. ;)

[mamcx]

Tambien depende del "ambito" donde corre. La utilidad de un componente en tiempo de ejecucion de la interfaz grafica no es mucha, es mas productivo armar un formulario con el diseñador que a mano, y aun si se crea un generador de formulario (comun en sistemas ERP) de todas maneras es replicar lo ya hecho.

Pero en la logica de negocios y el acceso a datos, permite una programacion mas clara y extensible...

[Neftali [Germán.Estévez]]

...pues la utilidad en tiempo de ejecución podria ser cuando no es fijo el uso del componente.
En principio como ya se ha comentado, crearlos en tiempo de ejecución tiene ventajas, pero cuidado, hay que ver la cosas con prespectiva y con lógica.

Ej: Un formulario sencillo, con un ADOConnection, ADOQuery, TDatasource y un DBGrid que muestre datos; A eso le añadimos un par de botones y tenemos un formulario de selección.

Podríamos pensar en crear todos los componentes en tiempo de ejecución para aprovechar todas las ventajas anteriormente comentadas. ¿Pero quien de nosotros lo hace así? Nadie (espero), porque la facilidad y el tiempo de desarrollo también es una ventaja.
Colocar un componente en diseño y asignarle unas cuantas propiedades son 10 sg y una probabilidad baja de errores, hacerlo en tiempo de ejecución son unas cuantas líneas de código, más tiempo, más trabajo (no nos engañemos, los informáticos smos "flojos" por naturaleza) y la una probabilidad de error más alta; Si en lugar de 1 son 3, hay que multiplicar lo dicho por 3.

CONCLUSIÓN (mía): Cuando el consumo de memoria puede ser alto (y no hablo de 1 ADOQuery) o el número de componentes es variable ==> Tiempo de ejecución, sino crearlos en visual (que para eso usamos un entorno RAD).

[Johnny Q]

Voy comprendiendo mejor, por un lado entiendo que mientras el componente no se utilice en el "ciclo de vida" completo del formulario es factible el uso en tiempo de ejecución.

Por otro lado entiendo que el componente en tiempo de ejecución puede mejorar ligeramente el rendimiento pero no en grandes cantidades.

Tambien percibo que hay que ser cuidadoso con la creación de los componentes en tiempo de ejecución y la utilización de sus metodos y propiedades, pero sobre todo con la liberación.

Hasta el momento puedo concluir que si un componente en tiempo de ejecución nos va a complicar mucho la vida en cambio de ayudar, lo mejor es utilizarlo en la forma y ya (sera que es una visión muy simplista?).

[vtdeleon]

Saludos

Tiempo Desarrollo vs Facilidad

[Neftali [Germán.Estévez]]

...¿sera que es una visión muy simplista?
¡¡Ahí le has dado!!
¿Es simlpe? Pues sí, pero es la que tiene lógica (o al menos para mi).

Lo dicho, salvo excepciones concretas, que se deben estudiar aparte como casos concretos.