FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Pues obviamente tienes es un problema de organizacion.
Si un problema es demasiado dificil de resolver, hay que replantear el problema hasta que sea facil. (Tengo en la punta de la lengua que eso es un patron de diseño pero solo me acuerdo de nombre el singleton y el factory ) El problema es que llamas a las cosas padres e hijos. Y como ves, no tenes una herarquia desendente. Lo que tienes que hacer es llamar a las cosas controladoras, ruteadoras y ejecutoras. O Administradores de flujo, pasos de trabajo. O algo asi (te digo en serio, se me olvidan los nombres academicos de estas cosas!) En fin... La cosa seria tener una clase Administradora. Lo que haria es simplemente manejar el paso de los flujos de trabajo. Algo como (me mata que no hayas puesto el ejemplo de lo que tu querias hacer en ves de seguir con el ejemplo de los thread!): TAdminProcesoEnruedado: procedure Init; Event Progreso; ListaAcciones:UnaLista; Luego La que ejecuta: TAccionSencilla procedure Execute(Datos....); Luego tenes que pensar como fabricarias las cosas al estilo de un diagrama de flujo: Que pasos hay que ejecutar? Cuales SI son suceptibles de jerarquias? Ñuño tiene una buena idea, usar Interfaces. Pero necesitas organizar las clases. En fin, de purra intuicion, necesitas unas 3 clases para hacer el trabajo, y seria algo similar a TActionList y TAction. Segundo, debes buscar eliminar el referenciado fuerte. En vez de pasar las referencias de los objetos pasa parametros. Mientas mas desacoplados esten las cosas mejor. O si posteas exactamente que es lo que tienes seguro podemos armar una solucione mejor que toda la incoherencia arriba citada !
__________________
El malabarista. |
#2
|
||||
|
||||
Ah! Y otra cosa.
Es mejor explicar que es lo que se quiere y dejar a un lado como se ha hecho (o se quiere hacer) eso enrueda las soluciones. Aunque normalmente aplica al trato con clientes (ej: Cliente dice: Quiero que me hagan un raytracer que funcione con servicios web, cuando lo que quiere es que las *imagenes* de un raytracer se vean en una pagina!) tambien aplica a uno como desarrollador. Si la solucion no llega de forma natural, es mejor concentrarse en la pregunta. Reformular la pregunta hasta que sea obvia la respuesta.
__________________
El malabarista. |
#3
|
|||
|
|||
Muchas gracias de nuevo a todos.
Para quitaros dudas de qué es lo que yo necesitaba exactamente os diré que al final seoane acertó de pleno. He probado lo de la interface y funciona perfectamente. Pero me obliga a declararme estos 3 procedimientos siguientes porque son heredados de la interface base IUnknown.
Como tenía que ponerle un cuerpo a estos procedimientos les he puesto el siguiente cuerpo en mi clase "padre" (prefiero seguir llamándola así para entenderme ):
Lo que no sé es si tendría que poner algo más dentro del cuerpo de esos métodos o si así me funcionará sin problemas. La verdad es que hasta ahora no había utilizado interfaces . Aunque supongo que no habrá problemas pues es de esperar que el INHERITED que les he puesto llame a los métodos de la clase TObject. Muchas gracias de nuevo a todos. |
#4
|
||||
|
||||
Deriva las clases de TInterfacedObject y todo bien.
La implementacion que has hecho no funciona con interfaces porque anulaste el sistema de liberacion de memoria!
__________________
El malabarista. |
#5
|
|||
|
|||
Cita:
Gracias por el consejo. No conocía la clase TInterfacedObject, y si te soy sincero tampoco sé muy bien para qué son el QueryInterface, _AddRef, y _Release. Además, eso que comentas de anular el sistema de liberación de memoria la verdad es que me asusta un poco. No obstante, he mirado en la ayuda de Delphi y creo que no me será necesario usar el TInterfacedObject. De todos modos, por si acaso me equivoco en algo, te mostraré con más detalle lo que tengo y si ves algo que creas que esta mal no dudes en corregirme, ¿vale?
Muy resumidamente, es eso lo que yo tengo hecho. En la ayuda de Delphi he visto que TInterfacedObject está declarada de la siguiente manera:
Mi clase TClasePadre desciende de TClaseBase (la cual por definición desciende de TObject), y del interface TMiInterface (que desciende de IUnknown). Por tanto entiendo que TClasePadre termina heredando todo lo que necesita de TInterfacedObject, excepto el RefCount. ¿Qué opinas? ¿Necesitaré el RefCount para algo? Cuando compilo, Delphi no me pide que incluya el RefCount dentro de TClasePadre. Y cuando ejecuto, no me aparece ningún mensaje de error ni al crear ni al destruir las clases. ¿Necesitaré incluir RefCount de todos modos? ¿Necesitaré poner algo dentro de los métodos QueryInterface, _AddRef, y _Release aparte del inherited? Por si te vale de ayuda, estamos hablando de Delphi 3. Muy arcaico, ya lo sé. Pero por desgracia yo no decido mis herramientas de trabajo. Muchas gracias de nuevo. |
#6
|
||||
|
||||
Puedes usar TInterfaceObject de forma segura, de hecho para ello existe.
_AddRef, _Release y RefCount permiten un "recolector de basura" que funciona mediante el conteo de referencias. La idea es que cada vez se toca un objeto que lo implementa se "aumenta" la cantidad de referencias y luego cuando se suelta el objeto se "decrementa". Cuando el # de referencias llegue a 0, automaticamente se libera el objeto (esto significa que en la practica no es necesario llamar a .Free). Lo que pasa es que como sabes Delphi (excepto la version .NET) no es un lenguague con GC incorporado y si no se tiene en cuenta las reglas que hay que seguir termina haciendo uno unas vainas muy mal hechas (ej: No se deben mezclar llamadas a interfaces con las de objetos). TInterfacedObjet es una clase que por decirlo asi, permite a las clases "normales" (que no manejan recolector de basura por referencia) beneficiarse de las ventajas de las interfaces. Otra nota, es convencion (aunque no obligatoria) llamar las interfaces asi: IUno IDos Y las clases TUno TDos
__________________
El malabarista. |
#7
|
|||
|
|||
¿No hay que hacer uso del "Free"?
Gracias por la información.
Pero no entiendo eso de que no sería necesario llamar a Free para liberar la memoria usada por el objeto. Si tengo la clase siguiente
Cuando quiera crearme una instancia de TMiClase tendré que ejecutar algo así
Y se supone que cuando ya no necesite más MiObjeto y quiera liberar su memoria tendré que hacer uso de esto otro o ¿Qué has querido decir exactamente al decir que no necesitaría hacer uso del Free? |
#8
|
||||
|
||||
Cuando una clase esta bajo el "amparo" de las interfaces tienen su manejo automatico de memoria.
Sin embargo, el manejo se vuelve algo enrevesado si no se conocen las reglas de como funciona, asi que mejor sigue dandole free
__________________
El malabarista. |
#9
|
||||
|
||||
Cita:
// Saludos |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Ventana MDI, "Siempre visible" y "Pantalla completa" | ixMike | API de Windows | 7 | 11-04-2007 18:36:55 |
¿cuál es mejor: "close" o "application.terminate"? | unreal4u | Varios | 5 | 05-03-2007 11:01:19 |
"ChequeaEsto" elegido el futuro "Killer CLubDelphi" | mamcx | Noticias | 51 | 31-10-2006 20:56:32 |
Firebir y usar "IF" en la clausula "SELECT" | papulo | SQL | 6 | 25-07-2006 21:38:04 |
porque no me reconoce los caracteres "*" ni "%" cuando filtro | mrmago | Conexión con bases de datos | 10 | 27-01-2006 04:21:16 |
|