Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Temas relacionados > Debates
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Ver Resultados de Encuesta: ¿Personalizar componentes es reinventar la rueda? ¿Compensa? ¿Util? ¿Bueno ó malo?
Sí, es liarse para nada, no compensa el trabajo 3 25,00%
Depende 5 41,67%
Es bueno, resulta útil 4 33,33%
Votantes: 12. Tú no puedes votar en esta encuesta

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 30-05-2003
bitERROR bitERROR is offline
No confirmado
 
Registrado: may 2003
Posts: 33
Poder: 0
bitERROR Va por buen camino
Reinventar la rueda. Componentes.

Buenas, a ver si os parece interesante este debate. Propongo este tema inicialmente sobre componentes, como primera parte, luego podríamos hacer otros debates sobre lo que sería Reinventar la rueda refieriéndonos a métodos de programación, funciones, gestión de errores, bases de datos, API, graficos, etc..., aunque si quereis incluir estos temas aquí no tomaré represalias

Esta frase «...eso es reinventar la rueda...» la he leido bastantes veces por estos foros y refiriéndose a hacer funciones, componentes, etc... cuyo objetivo ya podía alcanzarse con funciones, componentes, etc... estándard ó hechos por terceros.

He abierto este debate a raíz de un hilo del foro de OOP, abierto por sergisan y titulado Componente On/Off que pedía un componente como el TRxSwitch pero que no necesitara de las uniades RX. Al ver este hilo, creo que está abierto en otro foro también (capón para sergisan), y dada mi afición a crear componentes, hice copia del componente y lo simplifiqué para que manteniendo las propiedades que pedía sergio, quedara aislado de las unidades RX.

Esto me trajo a la cabeza la citada frasecita, reinventar la rueda, quiero aclarar que en ningún caso me ha ofendido leerla, pero me gustaría que hablaramos sobre ella.

En mi opinión, hablando de componentes, en muchas ocasiones no empleamos todas las posibilidades de cada uno de los que disponemos en nuestra paleta, bien por ignorancia ó porque no nos hacen falta normalmente. En este último caso, me pregunto por que no crear, nosotros mismos, componentes que se adapten a las necesidades de nuestra/s aplicación/es, que contengan únicamente las propiedades y funcionalidades que necesitemos, ¿por no tener mil componentes en la paleta?, si se hace inteligentemente, creo que esto no tiene porque suceder.

Encuentro que almenos, por lo que hace a componentes (me repito), resulta útil ajustar componentes pues reduce el consumo de recursos por parte de nuestra aplicación, el tamaño del exe, además de ser didáctico (el diseño y creación de componentes para muchos es un misterio).

La creación de componentes propios es siempre interesante, nos permite crear nuestras propias herramientas de trabajo, si tenemos el suficiente conocimiento, pese a que en algunos casos, nuestras necesidades puedan ser saciadas con material de terceros.

Por el otro lado, estamos pasando de los componentes estándard y/o populares (lease RX por ej.), y esto puede traernos problemas de compatibilidad, además de restarnos tiempo para implementar la aplicación en si, haciendo algo que ya nos dan hecho.

Seguro que mañana se me ocurren más ventajas y desventajas sobre la creación de componentes propios, pero ahora estoy un poco seco, aquí dejo la parrafada y las preguntillas...

¿Personalizar componentes es reinventar la rueda? ¿malo ó bueno? ¿bajo que circunstancias (laborales, etc..) es ventaja ó desventaja? ¿compensa el tiempo utilizado? ¿compensa alguna cosa? ¿a que huelen las nubes?...

mm... nas noxes
Responder Con Cita
  #2  
Antiguo 30-05-2003
Kafu Kafu is offline
Miembro
 
Registrado: may 2003
Ubicación: Bilbao
Posts: 117
Poder: 21
Kafu Va por buen camino
Valorar la relación esfuerzo/utilidad es bastante complicado en muchas ocasiones.
Yo procuro que cuando creo un componente este sea humilde desde su nacimiento. Por ejemplo: Un botón que en el onclick además de hacer lo que hayas puesto diga "Hola". Eso es un componente útil. El decir "Hola" lo vas a tener allá donde lo necesites y no va a añadir posibilidad de error a la aplicación, pues es predecible y controlable.
Pero he visto verdaderas barbaridades, aplicaciones girando en torno a un componente que intentaba hacerlo todo y siempre lo hacía mal. Cuando un componente sale del encapsulamiento y asume demasiadas "responsabilidades" acaba convirtiendose en un estorbo. Esto sería, por ejemplo, un botón que dijera "Hola", "Adios" o "Muy buenas" en función de demasiadas variables, con lo cual apenas te deja libertad para tocar esas variables porque no sabes qué hará el componente en venganza.
Otra cosa. La VCL de Delphi no la hicieron en un fin de semana.
Dejarse llevar por la vanidad y reinventar componentes que ya existen suele tener consecuencias nefastas. En general creo que procurarse componentes que añadan funcionalidades específicas de la aplicación y no cambiar las propias del ancestro suele ser la mejor idea. Un saludo,












F.T.G.
Responder Con Cita
  #3  
Antiguo 30-05-2003
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
En mi opinión uno no debería reinventar la rueda pero, al menos en mi caso particular suceden varias cosas:

Primero, es difícil confiar en componentes de terceros. En la red abundan componentes hechos por programadores inexpertos y son pocos los que tienen un prestigio reconocido.

Por otra parte hay componentes que hacen demasiadas cosas y muchas veces con sólo un pequeño esfuerzo podemos crear uno con la funcionalidad requerida sin la sobrecarga de métodos y propiedades que jamás usaremos.

También sucede que la manía de usar componentes, la componentitis, nos lleva a poner sin ton ni son componentes cuyo trabajo sería más apto para código puro, como es el caso de las componentes que se usan para evitar que una aplicación se ejecute más de una vez al mismo tiempo.

// Saludos
Responder Con Cita
  #4  
Antiguo 30-05-2003
__cadetill __cadetill is offline
Miembro
 
Registrado: may 2003
Posts: 3.387
Poder: 24
__cadetill Va por buen camino
Yo creo que, en la mayoria de aplicaciones (almenos las que yo suelo hacer que son de gestión), con los componentes que trae la VCL tienes practicamente todo lo que necesitas.

De echo, como componentes de terceros, utilizo las Rx, un componente de acceso a puerto serie y un grid.

Como muchos, al empeazar a programar en Delphi, empece a utilizar cantidad de componentes de terceros, pero, a la larga, me fue un engorro y me trajeron dolores de cabeza por varios motivos

* Tenian bugs y no traian codigo fuente para corregirlos
* Al no traer codigo fuente, no podia migrar de version de Delphi

y algun que otro detallito que no recuerdo ahora

Hace unos 7 años que empece con Delphi y siempre he hecho programas de gestion y pocos componentes externos (pensandolo friamente) necesitava de terceros.

En mi vida como programador, solo he creado un componente y fue recientemente y porque estaba hasta los c~... de tener que incluir la misma pantalla en mis aplicaciones, meterla en el uses de los forms donde la queria utilizar,.....

Estoy de acuerdo en lo que comentais de que si, con poco codigo un componente puede llegar ha hacer lo que queremos, por que buscar otro que haga eso? y, si es una cosa que vamos a utilizar mucho, pues modificar el comportamiento de dicho componente.
Responder Con Cita
  #5  
Antiguo 30-05-2003
Avatar de __marcsc
__marcsc __marcsc is offline
Miembro
 
Registrado: may 2003
Ubicación: Girona
Posts: 577
Poder: 21
__marcsc Va por buen camino
Hola,

yo estoy de acuerdo con lo que se ha dicho: los componentes suelen ser engorrosos y llenos de bugs (incluso en componentes profesionales, como por ejemplo InfoPower) y algunos son muy difíciles de utilizar, debido a que hacen demasiadas cosas.

Sin embargo yo no soy nada partidario de personalizar componentes, puesto que el tiempo invertido no me compensa las mejoras obtenidas. Eso no quiere decir que si tengo un componente al que le falta algo que necesito no trato de modificarlo, pero si tengo un componente que me sirve bien pero tiene demasadas funcionalidades que yo nunca uso, no me molesto en modificarlo... Ya sabemos que no hay que confundir eficacia y eficiencia, pero a veces en el mundo de la empresa privada es (por desgracia) difícil buscar la eficiencia

Saludos
Responder Con Cita
  #6  
Antiguo 30-05-2003
Iván Iván is offline
Miembro
 
Registrado: may 2003
Ubicación: Palma de Mallorca
Posts: 118
Poder: 21
Iván Va por buen camino
Mi opinión es que si puedo uso únicamente componentes de la VCL estandares, aunque ello implique un mayor trabajo en la mayoria de veces, que con otros componentes igual tardaría un poco más tarde.

Sobretodo se debe, ya no si los componentes son mejores o peores, sino a la incertidumbre a la hora de hacer un cambio de versión de Delphi. A pesar de tener el código fuente de un componente, al cambiar de una versión a otra, nos puede implicar muchas horas de trabajo, meternos en un código que nosotros no hemos desarrollado, y muchos dolores de cabeza.

Mientras que si nos limitamos a usar los componentes de Delphi, sabemos que la compatibilidad será como mínimo de un 95% de nuestro código, y si algo no funciona, lo que deberemos hacer es modificar nuestro programa y ya esta... nada más.

Así que para mi mejor usar los componentes de Delphi, y poco más.

Un saludo.
__________________
Di amigo, y entra...
Guía de estilos de los foros

Visita www.mundobd.com
Responder Con Cita
  #7  
Antiguo 30-05-2003
Avatar de delphi.com.ar
delphi.com.ar delphi.com.ar is offline
Federico Firenze
 
Registrado: may 2003
Ubicación: Buenos Aires, Argentina *
Posts: 5.932
Poder: 26
delphi.com.ar Va por buen camino
Creo que a la hora de decidir crear un nuevo componente, o mejorar una función preexistente, hay que poner en una balanza muy precisa la relación costo-beneficio, y establecer la funcionalidad a futuro.

El nodo del cual empezó este debate, lo que quise aclarar, es que no se está creando un nuevo componente, solo se está extrayendo todo el código de este componente del paquete de las Rx, y en algunos casos me parece un trabajo absurdo, pero aclaro que es solo una opinión personal, y vale tener en cuenta que tengo casi 100 componentes creados para mis aplicaciones.. ¿Parece mucho?, bueno algunos de estos solo agregan alguna funcionalidad extra a los de la VCL.


Saludos!
__________________
delphi.com.ar

Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla.
Responder Con Cita
  #8  
Antiguo 31-05-2003
bitERROR bitERROR is offline
No confirmado
 
Registrado: may 2003
Posts: 33
Poder: 0
bitERROR Va por buen camino
Coincido en que Esfuerzo ó coste y utilidad son sin duda puntos importantes a valorar en el momento de crear un propio componente.

Aunque hablando de terceros, en mi paleta puedo diferenciar tres tipos.

- Por un lado las LMD e InfoPower... joer solo ver la cantidad de propiedades que tiene cada componente ya da miedo utilizarlos, estos los útilizo muy excepcionalmente y por cuestiones de mera apariencia.

- En la otra banda, los RX, estos son güenos, impecables todos en ellos en lo que hace al código, pero pregunto ....

TRxLabel, TRxDBGrid, TRxQuery, TRxPopUpMenu, TRxMainMenu ó TRxRichEdit y otros ¿no son un reinvento de la rueda? apenas agregan alguna propiedad, poco más se puede hacer con un TRxDBGrid que no se pueda hacer con un TDBGrid. Y si es así, ahora estoy pensando, y no concluyo porque los utilizo

No obstante, TCurrencyEdit, TFormStorage y TRxMemoryData, entre otros me parecen casi imprescindibles (yo tb hago programas de gestión) ¿son mejorables? ... vengo a decir que estos componentes son originales de las RX, y si ellos los han creado, tal vez basándose en ideas de otros terceros, nadie les quita la creatividad, ¿no es este un punto clave?

¿Puede ser que nos falte la creatividad que ellos tienen para diseñar componentes originales? y creo que no me salgo del tema, al fin y al cabo, un TCurrencyEdit, no es más que un heredado del TCustomEdit y por tanto podría considerarse un susodicho reinvento.

Ellos fueron capaces de ver la necesidad de un TEdit que sólo admitiera valores numéricos y así reinventaron el TEdit, modificándolo para satisfacer esta necesidad. Tal vez necesitemos una ducha de ideas frescas ó ganas para ponernos y muchos de los problemas, que creo que no vemos por ser habituales (igual incluso nos cuesta admitirlos), quedarían solucionados. Seguro que alguien, antes de los rusos, ya había pensado en el TEdit que sólo cogiera números y no se paró a hacer un TCurrencyEdit, que es, almenos en mi empresa, uno de los componentes más utilizados...

Finalmente hay una cosa que me jode, y es lo comentado por Iván, me fastidia tener que pensar que no puedo crear componentes porque será un suplicio al migrar a la siguiente versión de delphi, me corta la creatividad, como Borland siga así me pondré en huelga jejeje

un xaludoou y nas noches

P.D.: Menos mal que no hablo tanto como escribo.
Responder Con Cita
  #9  
Antiguo 31-05-2003
__cadetill __cadetill is offline
Miembro
 
Registrado: may 2003
Posts: 3.387
Poder: 24
__cadetill Va por buen camino
Hola bitERROR.

Cita:
Posteado originalmente por bitERROR
apenas agregan alguna propiedad, poco más se puede hacer con un TRxDBGrid que no se pueda hacer con un TDBGrid.
En esto si que no estoy deacuerdo. Para mi, el TRxDbGrid lleva una funcionalidad (aunque solo fuese esta) muy importante que para hacerla con un TDbGrid tendria que escribir mucho codigo y es la capacidad de poner un "triangulito" para indicar por que columna se esta ordenando un DataSet.
Responder Con Cita
  #10  
Antiguo 31-05-2003
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Cita:
Posteado originalmente por cadetill
Hola bitERROR.
Para mi, el TRxDbGrid lleva una funcionalidad (aunque solo fuese esta) muy importante que para hacerla con un TDbGrid tendria que escribir mucho codigo y es la capacidad de poner un "triangulito" para indicar por que columna se esta ordenando un DataSet.
Aunque si sólo fuera por eso quiza yo no instalaría 300 componentes en mi paleta a menos que utilice varias de ellascon regularidad.

Pero de hecho es este tipo de simples agregados pero que utilizamos mucho lo que en mi caso me lleva ocasionalmente a escribir mis propios componentes.

Por ejemplo, para escoger un campo relacionado normalmente ponía un TDBLookupComboBox pero era necesario también poner un TEdit para que el capturista pudiera escribir el código en lugar de seleccionarlo de la lista (una vez que se saben los códigos esto es más fácil para quien captura). El código siempre era numérico y resultaba muy útil que después de los dos o tres dígitos de que constara, el foco pasara automáticamente al siguiente control. Por otro lado debía conectar el Edit con el Combo de manera que los cambios en uno se reflejarran en el otro. Si esto se hace para un par de casos no vale la pena ni bajarse un componente ni escribir uno, pero cuando se trata de colocar decenas o veintenas de estos pares de controles la cosa cambia. Así que me fabriqué mis propios derivados de Edit y Combo cada uno con una propiedad publicada que referencia al otro y de esta forma tanto el código que enlaza ambos componentes como lo de aceptar sólo números y pasar al foco siguiente lo escribo una sóla vez y me olvido de él por el resto de mis días.

Es cierto que pude buscar algún componente que me diera una funcionalidad similar pero codificarlos resultaba bastante sencillo y tengo completo control sobre ellos y puedo modificarlos a mi antojo como de hecho fue el caso: se dio la necesidad de tener Edits que se autoseleccionaran (todo el texto) al hacer click dentro de ellos. Parece fácil pero al menos yo nunca pude hacerlo directamente ya que la autoselección debe hacerse sólo si el control no tiene el foco. Sin embargo sí podía hacerlo si derivaba un componente del Edit. En lugra de bajarma otro Edit con es funcionalidad simplemente se la añadí al que ya tenía.

Sin embargo es claro que si la complejidad del componente es muy alta es recomendable buscar uno ya hecho, a no ser que uno se dedique a escribir componentes pero generalmente no se tiene el tiempo suficiente.

Por ejemplo, antes de la llegada de los ClientDataSets había (y creo que todavía los hay) componentes para simular tablas en memoria. Esto era factible hacer ya que tan sólo había que derivar de TDataSet pero la complejidad es muy grande y era mejor buscarse algo ya hecho.

// Saludos
Responder Con Cita
  #11  
Antiguo 31-05-2003
__cadetill __cadetill is offline
Miembro
 
Registrado: may 2003
Posts: 3.387
Poder: 24
__cadetill Va por buen camino
Cita:
Posteado originalmente por roman
Aunque si sólo fuera por eso quiza yo no instalaría 300 componentes en mi paleta a menos que utilice varias de ellascon regularidad.
Hola roman

Yo me referia a la funcionalidad del RxDbGrid. Utilizar, sí que utilizo mas componentes, sobretodo el TDirectoriEdit, el TDateEdit (que me gusta mucho mas que el TDateTimePicker), TRxDbComboEdit y TComboEdit (en los que utilizo el boton para mostrar una pantalla de busqueda de una clave foranea),....

Si solo utilizara el RxDbGrid y solo esa funcionalidad, te aseguro que yo tampoco me instalaria toda la RxLib, miraria el codigo y me haria mi propio derivado del TDbGrid
Responder Con Cita
  #12  
Antiguo 03-06-2003
Avatar de SnaKe
SnaKe SnaKe is offline
Miembro
 
Registrado: may 2003
Ubicación: Madrid (España)
Posts: 227
Poder: 21
SnaKe Va por buen camino
Hola,

Aportaré mi granito de arena dando mi opinión... al mensaje original de bitError... ¿personalizar componentes es reinventar la rueda?, vamos a ver, desde mi punto de vista si siempre que estés copiando código, ¿hay algún problema con la parte de código eliminada? ¿generaba algún error?... no verdad, pues, ¿porque eliminarla?, instala las Rx enteras y utiliza directamente el componente a no ser que necesites algo más.

En cuanto a lo de usar componentes de terceros... me parece que es lo mejor del mundo, eso si, componentes debidamente probados y que funcionan correctamente, no tiene porque ser el autor del componente el que lo haga... sino quien lo necesite.

Cadetill, comentas que únicamente utilizas las Rx, un grid y uno para acceder al puerto serie, bien, ¿que pasa si un día necesitas manejar archivos Zip?, ¿reescribes la Zlib?, ¿la copias? o, ¿no usarías el ZipMaster?, estos es solo un ejemplo, pero bueno, imaginate que a un cliente le apetece exportar los informes de quickreport a formato JPG, ¿que haces?, ¿compras uno de pago?, ¿reescribes?, ¿copias?... creo que te expresas mal al decir que solo usas esos, lo que deberías decir es que solo has necesitado por ahora usar esos .

En cuanto a lo de personalizar componentes con las propiedades necesarias para uno mismo. Mi opinión es que no se deben personalizar , ¿por que? otro ejemplo. El componente TLabel (estandar de Borland) seguro que es el componente más utilizado en todas las aplicaciones, bien, lo que se hace con el habitualmente es cambiar el caption y la fuente a lo mas (ni siquiera se suele cambiar el name) y eventos, pues yo creo que a lo más el click (yo creo que nunca lo he usado), bien, pues el susodicho componente cuenta con 36 propiedades y 14 eventos . ¿Alguien se ha asustado de un TLabel? ¿a alguien le estorban todas las propiedades que tiene?, supongamos que ese componente solo tuviese: Caption, Font, Align y Name y como eventos: OnClick. Si el día de mañana al cliente le apetece que cuando se pase el ratón por encima cambie de color, ¿qué hacemos?...

Mi opinión es que nada sobra, el día de mañana puede ser necesario y seguramente no haya merecido la pena reescribir el componente...

Concluyendo y desde mi punto de vista:

- Personalizar componentes existentes: NO.
- Utilizar componentes de terceros: SI cuando surge la necesidad y una vez visto que funcionan correctamente.
__________________
Todos somos aficionados. La vida es tan corta que no da para más.
Guia de Estilos
Responder Con Cita
  #13  
Antiguo 03-06-2003
Avatar de José Luis Garcí
[José Luis Garcí] José Luis Garcí is offline
Miembro Premium
 
Registrado: may 2003
Ubicación: Las Palmas de G.C.
Posts: 1.372
Poder: 22
José Luis Garcí Va camino a la fama
Veamos los componentes de terceros se pueden cojer no sólo como un ahorro de tiempo, ademas te sirven para ver como podrias hacer algo que ati por ejemplo no se te ha ocurrido, yo he creado un par de componentes, que he desechado por el de terceros que me funcionan estupendamente, eso sí procuro usarlos lo menos posible, pero si uso otros de manera fija en mis programas como el Oi (object inspector) en su fase de diseño, ya que me puedo ahorrar muchas horas de programación corigiendo pequeños defectos en plena ejecución. Mi forma de programar desde Clipper ha pasado por un constante avance y pase de currarme un programa de 76000 lineas a hacer el mismo programa con menos de 10000, crear mas de 250 funciones de todo tipo, ha llegar el caso de que la persona que me enseño la base en clipper, no era capaz de recorrer mi código, lo mismo me pasa con delphi, claro esta primero has de testear muy bien un componente antes de usarlo en una aplicación, y desechar aquellos que puedan ser un engorro, o de masiados complicados.

Tengo actualmente unos 1000 componentes diferentes sin contar con los de mi Delphi 6 Profesional, uso de manera habitual unos 50 que ha llegado a crear dependencía, pero claro yo programo por modulos que reutilizo de un programa para otro y no me han dado problemas, eso sí tienes que estar dispuesto a 1º si tienes que pagar no pongas pegas y 2º sólo usarlos cunado son necesarios.

Yo voto a favor y dejo mi opinión.
Un saludo desde Canarias.
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 15:26:40.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi