![]() |
procedimiento de asignación genérico
Hola, tengo unas dudillas a ver si alguien me puede orientar un poco.
Cuando se realiza la siguiente asignacion en delphi: objeto1 := objeto2; realmente no se hace la asignacion sino que objeto1 apuntara a la misma posicion de memoria que objeto2. Estoy intentando hacer un procedimiento que realice la asignacion completa, es decir, el procedimiento debe crear una nueva instancia del objeto pasado por parametro (objeto2), que en principio no sabemos de que tipo es, y copiar el contenido de todas las propiedades del objeto2 en las propiedades del objeto1. procedimiento TObjeto.Asignar(obj: pointer ); En este punto se me han planteado una serie de dudas sobre la solucion que se me ha ocurrido pero que no he conseguido implementar. Primero, el tipo del parametro que le paso al metodo es de tipo pointer ya que delphi, si no me equivoco la variable objeto no tiene el objeto en si sino la direccion del mismo, por lo que si el parametro es de tipo pointer, el método aceptara cualquier tipo de objeto ya que como dije todo objeto en delphi es un puntero al objeto. No se si este razonamiento es válido y eficiente pero compilar compila. Una vez entramos en el metodo los pasos que creo se deberia seguir para realizar la asignacion son los siguientes: 1. Averigua el tipo del objeto pasado por parametro aqui se que puedo usar propiedades como ClassName o ClassType pero aunque he conseguido acceder a ClassName no he conseguido siquiera cambiar el valor de una propiedad del objeto pasado porque siempre se produce el mismo error en tiempo de ejecucion, error en el acceso a memoria. 2. crea una nueva instancia del objeto una vez averiguado su tipo 3. accedemos a todos los campos del objeto pasado por parametro y copiamos su contenido en las propiedades del objeto creado. Aqui se me plantea el problema de como recorrer todas las propiedades del objeto pasado por parametro. 4. Devolvemos el objeto creado. Las dudas que tengo son muchas pero ahi van unas cuantas: - la unica manera de averiguar el tipo del objeto que me han pasado es asignando el pointer a un objeto local de tipo TObject y accediento a la propiedad NameClasses o haciendo una conversion directa: NombreClase := PTObject(Objeto)^.ClassName; PTObject es un puntero a TObject. - ¿como creo una nueva instancia? lo he conseguido hacer si dentro del metodo realizo una conversion (al parametro)al tipo que sé que le estoy pasando al metodo pero la gracia esta en que ese metodo lo pueda usar cualquier independientemente del objeto para el que vaya a realizar la conversion. - Sabeis de documentacion(en español mejor) sobre la Programacion orientada a objetos en object pascal sin ser el manual de delphi y que tenga ejemplos mas elaborados sobre las referencias de clase ya que no tengo ni idea de en que contexto se usan o para que sirven, aunque sospecho que alguna relacion con el problema que he planteado seguro que tienen. Gracias de antemano por la ayuda. Un saludo. PD:disculpas por lo extendido que me ha quedado el mensaje. |
Hola gushynet,
Bienvenido/a a Clubdelphi. Como eres nuevo te pediría que por favor dediques unos minutos para leer la guia de estilo. Con respecto a tus dudas habría que analizar mejor que es lo que buscas. No se si estoy comprendiendo bien pero me parece que tu estás buscando implementar un método Assing() genérico, es decir que no dependa del tipo o clase destino ni de la fuente. Si es eso es imposible, al menos eso es lo que yo tengo entendido. Una pregunta ¿Tiene sentido assignar los valores de las propiedades de un TGato a un TPerro? El asunto es que necesariamente debe conocerse las posibles clases de las cuales permite realizar asignaciones y debe haber cierta similitud entre una clase y la otra. Por ejemplo, en el caso de TGato y TPerro, en parte es posible, si lo entendemos en el contexto en que ambos son descendiente de TAnimal. Pero si TGato desciende de TFelino. y TPerro desciende de TCanino, el grado de parentezco posiblemente nuble o haga díficil una asignación. Necesariamente el método Assing debe contar y saber de antemano cuales son las clases que asumirá como válida para permitir una copia. Y esto lleva a un principio: obligadamente tus clases son descendientes de TPersistent o bien obedecen a una jerarquia de clases, cuya clase base sea descendiente de TPersistent o algún hijo de ésta. Al ser los métodos Assing y AssingTo de Persistent virtuales tu debes darle implementación a tus descendientes. En pocas: 1. Debe existir cierto grado de afinidad entre las clases 2. Deben ser parientes directos o indirectos de TPersistent 3. Deben redefinir el método Assing y AssingTo 4. Debe establecerse cuales son las clases válidas que puede aceptar para copiar Con respecto a como crear una nueva instancia, sería mejor que expliques mejor la situación. Cuando uno invoca a Assing asume que ya tiene una instancia tanto del objeto Destino como de la fuente. De cualquier manera, todas las clases cuentan con el método de clase NewInstance, si es que tu idea pasa por crear nuevas instancias de una clase x. Saludos, |
Hola, si lo que quieres es crear una nueva instancia de cierto objeto, entonces ¿no deberias usar directamente el metodo create y luego copiar todas las propiedades? (del TObject, claro, del puntero no podrias sacar nada en claro)
|
Cita:
|
Ahora que recuerdo, no es muy conveniente que se invoque a NewInstance en forma directa. Es preferible y más seguro el método Create.
De todas formas, todos los constructores invocan, automáticamente, al método de clase NewInstance para solicitar el espacio de memoria. El método de clase NewInstance es virtual por tanto puede ser redefinido. Si por casualidad en la etapa del pedido de memoria debe analizarse o chequearse algo al respecto al uso de memoria, es en este método en donde debe programarse. Por lo general no debe redefinirse este método. Pero un caso excepcional puede ser cuando la clase que se está diseñando debe actuar como un singleton. Saludos, |
Hola gushynet, revisa también este hilo http://www.clubdelphi.com/foros/showthread.php?t=34532
Saluditos |
explicacion mas detallada del problema
antes que nada, gracias por la rapidez de las respuestas. De todas formas pondré el pequeño ejemplo que estoy intentando hacer y de ahi la duda que es puesto en el foro.
Creo que lo de generico lo explique mal. Generico en relacion a una jerarquia de clases, jerarquia que explico a continuacion: Tengo una clase base llamada TParrafo la cual tiene todos los métodos abstractos y virtuales. Entre las propiedades que tiene hay una llamada "contenido" que es de tipo AnsiString. Tengo ademas tres clases (TPregunta,TRespuesta y TTematica) que descienden de TParrafo. TTematica añade una propiedad AnsiString mas llamada "descripcion". Todas las clases descritas tienen un metodo llamado asignar( declarado como virtual y abstracta en TParrafo ) al cual se le pasa un objeto de tipo parrafo y el metodo asigna el valor de todas las propiedades (en este caso solo una o dos si es de tipo TTematica) del parametro de entrada al objeto actual, el que realiza la llamada al metodo. mi intencion es que si el objeto que llama a asignar es: - TParrafo,TPregunta o TRespuesta compartan el mismo codigo ya que los objetos son iguales, por lo solo se debe cambiar el valor de la propiedad 'contenido' -Y que en Ttematica cambie la implementacion del metodo para tener en cuenta la propiedad 'descripcion' . El problema lo encuentro al ser el parametro del metodo de tipo TParrafo. Solo acepta cosas de tipo TParrafo por lo que use un pointer para que asi aceptara cualquier tipo de objeto y dentro de la implementacion especifica del metodo realizar un cast al tipo del objeto que ha llamado al metodo. Por ejemplo: si tengo un objeto t1 de tipo TTematica y uso su metodo asignar tenemos: T1.Asignar(T2); al ser T2 de tipo TTematica se produce un error. Lo mismo pasa si le paso algo de tipo TPregunta o Trespuesta aunque sean iguales a TParrafo, por ser de distinto tipo se produce un error de compilacion. De ahi el usar un pointer y dentro del metodo realizo una conversion. En definitiva, lo que quiero es usar bien la poo pero no se como montarmelo para hace eso: una sola implemetacion que sirva para TParrafo,TPregunta y TRespuesta y una reimplementacion en TTematica ya que la clase tiene una propiedad mas, 'descripcion' , sin que el tipo de dato (dentro de la jerarquia creada) que paso por parametro sea un problema. Espero haberme explicado mejor, pero entre que quiero escribirlo todo y que intento resumir para que no se haga muy grande el mensaje no se si ahora se entendera mejor. Gracias de antemano por el cable . Un saludo. |
Yo creo que hay algo confuso aquí. Según describes, tienes estas clases:
En este caso, el método Asignar acepta cualquier objeto de tipo TParrafo y cualquier descendiente de TParrafo. No debe haber ningún error de compilación. // Saludos |
¡Hola!
Cita:
Cabe aclarar que esta rutina de "clonación", después de crear la nueva instancia, copia solamente las propiedades publicadas (que básicamente son las mismas que pueden ser vistas en el inspector de objetos). También considera que el código de estas funciones está probado (en casos reales) con Delphi 7, pero no he terminado de adaptarlo a otras versiones (aunque un compañero del club tuvo la gentileza de adaptarlo a Delphi 6 y 2007 en pasadas semanas, sólo haría falta revisar tales adaptaciones). Algo quizá más importante de considerar es que la función ghClone llamará al constructor que tenga definido la clase en cuestión sólo si se trata de una descendiente de TComponent (gracias a que el constructor de TComponent es virtual). Si el objeto a clonar no es un componente, ghClone ejecutará el constructor de la clase TObject después de crear la instancia. Son tres las versiones (sobrecargas) de esta función:
Como podrás ver, las tres sobrecargas terminan llamando a una función de nombre ghCopyProps, que en otros casos podrías usar para copiar las propiedades de un objeto existente a otro. El parámetro opcional ExcludedProps te sirve para indicarle a la función que no copie algunas propiedades en particular:
Cita:
Un abrazo doble. Al González. :) |
Hola,
Siento que nuestro compañero gushynet se está yendo por un camino equivocado al tratar de resolver con clonaciones lo que puede resolverse con métodos usuales. Según lo que él describe, yo lo plantearía así: en lugar de poner el método Asignar de la clase base como abstracto, lo implementaría de manera que copie las propiedades comunes, y, tal como él mismo dice, redefiniría este método en TTematica para copiar la propiedad extra.
Tal como lo pongo aquí, se pueden copiar unos a otros sin problemas. Si una Tematica se asigna a un Parrafo (o Pregunta o Respuesta), el método usado es el de la clase base, por lo que se copia únicamente la propiedad Contenido. Si se asigna a otra Tematica entonce se usa el método redefinido que usa el heredado y añade la copia de la propiedad Descripcion. Finalmente, si un Parrafo (o Pregunta o Respuesta) se copia a una Tematica, el método Asignar de TTematica copia los campos base (Contenido) pero evita copiar el campo extra que no existe en el objeto fuente. // Saludos |
Antes que nada agradecer las respuestas ya que me han sido de gran ayuda.
Despues de una semana probando las ideas propuestas he conseguido implementar un contenedor generico pero con ciertas restricciones que no he podido quitar. Hare un pequeño resumen de lo que he hecho: - He implementado una clase llamada TElemento que es el tipo de objeto que aceptan o devuelven los metodos del contenedor(bueno,los que lo necesitan). - Esta clase tiene dos metodos abstractos llamados Asignar y Comparar. - Por otra parte tengo una clase llamada TContenedor, que es la clase base de los posibles contenedores que se implementen. Esta clase no es funcional. - A partir de TContenedor he definido TListaSimple que implementa una lista simple enlazada en memoria dinamica. - En el caso concreto de TListaSimple los nodos que almacena son de tipo TNodo cuya estructura consiste en tres campos: - ID: un entero - Elemento: TElemento - Siguiente: puntero a elementos de tipo TNodo. El contenedor funciona si los objetos que se quieren introducir descienden de TElemento (primera restriccion). El proceso que sigo para añadir un elemento es el siguiente: - creo un objeto del mismo tipo que el pasado por parametro. En este punto me ha surgido una duda: Al González me sugirio la siguiente sintaxis: Código Delphi [-]o2 := TClaseBase(o1.ClassType).crear(...) pero no funciona asi que probe la referencia de la clase en lugar de la clase base: Código Delphi [-]type TClaseBaseClass = class of TClaseBase; ...... o2 := TClaseBaseClass(o1.ClassType).crear(...) y si funciona. Mi duda es porque funciona asi y no como me sugirio AI Gonzalez ya que encuentro mas coherente y mas intuitiva su solucion que como yo lo he hecho. Que diferencia hay entre usar TClaseBase y TClaseBaseClass? - Despues de asignar el elemento, lo inserto en la lista dinamica en funcion del campo ID que previamente he calculado y ya esta. La segunda restriccion es que los objetos que se quieran almacenar en el contenedor deben disponer de los metodos Asignar y Comparar de lo contrario la historia se viene abajo ya que los uso dentro del contenedor de ahi que el usuario que quiera usar el contenedor con su jerarquia de clases debe hacer que su clase base sea descendiente de TElemento que es el que tiene definido de forma abstracta estos metodos. El usuario tiene que preocuparse de implementarlos en sus clases. Lo que busco para que el contenedor sea totalmente generico y yo ser el hombre mas feliz del mundo mundial es eliminar estas dos restricciones. La primera restriccion se me ocurrio eliminarla haciendo que en lugar de ser TElemento la clase base para que el contenedor funcione fuese TObject, pero me encontre con el problema de que ni Asignar ni Comparar estan definidos en TObject con lo que tampoco pude eliminar la segunda restriccion. Supongo que no puedo redefinir la clase TObject añadiendole Asignar y Comparar como metodos abstractos, porque significaria que tendria que dar por sentado que el programador que use mi contenedor tiene redefinido en su aplicacion la clase TObject con los metodos abstractos mencionados cosa que no tendria por que saber ni hacer para poder usar el contenedor. Y en este punto me he quedado. Al fin y al cabo lo que busco es solucionarle la papeleta al programador y que tenga que saber lo minimo sobre el contenedor para usarlo, y creo que el hecho de que el usuario del contenedor tenga que redefinir los metodos Asignar y Comparar ademas de hacer que sus clases base desciendan de TElemento hace que el objetivo que busco se quede por el camino, para mi gusto son muchas las cosas que tiene que conocer el usuario para usar el contenedor. Una duda mas: Sea la siguiente funcion: Código Delphi [-]function TListaSimple.Actual():TElemento var E:TElemento; begin E := TElemento.create(); E.Asignar(PActual.Elemento); result := E; end; PActual es un puntero a un nodo de la lista. Esta funcion se complementa con los procedimientos Primero, Ultimo, Siguiente y Anterior para movernos por la lista. Mi duda es la siguiente: el objeto E es un puntero cuyo espacio (el que ocupa el puntero no a lo que apunta) se libera cuando la funcion termina, es decir, como un tipo simple. Mi pregunta es si a lo que apunta tambien es liberado o soy yo el que tiene que preocuparse de liberar el espacio ocupado por E con el metodo destroy debido a que no es un tipo simple como un entero sino un objeto. Si es asi, significa que esta funcion, a no ser que el que llame a esta funcion se preocupe, cada vez que se llama deja perdido en memoria un espacio equivalente a algo de tipo TElemento o descendiente. Beno, por ultimo (tranquilidad que no son mas dudas ;) y no sera porque no tenga mas ;)) agradecer de nuevo las respuestas y la pagina que me han recomendado y por supuesto la paciencia mostrada con las "novelas" que he enviando como mensajes. Un saludo. Salud y Delphi |
Lo siento por lo del formato del codigo, pero en la vista previa se veia bien, no se que habra pasado.
Un saludo |
Cita:
Como lo haces después es realmente una sintaxis adecuada para lograr un molde de tipo de clase. :) Saludos desde el "ciber" de mi nuevo vecindario. Al González. :) |
Cita:
No se porqué empleas una lista enlazada de nodos, contando ya con con clases te facilitan el trabajo (como ser por ejemplo TObjectList). Por otro lado, el que tu implementes tu Nodo, te obliga a ti a liberar la memoria... cada New() que haces, deberá en algún momento corresponder con un Dispose(). Por otro lado, no estoy seguro pero tengo entendido que si por casualidad en tu TNodo, el "campo" Elemento es del tipo TObject (o descenciente de éste). Un New() de un TNodo y/o un Dispose() ni crea ni elimina dicho objeto. A me parece que lo más certero es lo que comenta roman. Saludos, |
buenas de nuevo. Veamos, lo del contenedor generico lo he hecho mas que nada para entender mejor los conceptos relacionados con la poo.
Lo que explica Roman es basicamente lo que he hecho y funciona bien siempre y cuando los objetos que quiera almacenar en el contenedor sean de tipo TElemento o desendiente ya que este objeto tiene las operaciones de asignar y comparar abstractas. Estos metodos los uso dentro del contenedor, concretamente en el metodo que se encarga de añadir un elemento a la lista. La lista dinamica que implemento usa new y dispose de manera correcta. Ese no es el problema. La lista y en concreto el metodo para añadir un elemento lo que hace es duplicar el elemento pasado por paramero y la funcion asignar es la que realmente asigna los valores al nuevo elemento creado de ahi la necesidad de que los elementos que se quieran guardar en el contenedor deban tener el metodo implementado sino no sabria como asignar el valor de las propiedades de un objeto a otro ya que en principio el contenedor solo se limita a almacenarlos. Este TElemento es encapsulado en el Nodo que como mencione en el mensaje anterior tiene tres campos, uno de ellos de tipo TElemento. Este campo apunta al objeto duplicado, por lo que el nodo lo que guarda es la ubicacion del objeto en memoria, no el objeto en si. El metodo para eliminar un nodo de la lista es: 1. busco el elemento en la lista con ayuda de la funcion comparar. 2. una vez encontrado uso el destroy para el elemento al que esta apuntando el campo del Nodo de tipo TElemento. 3. por ultimo libero el nodo de memoria con dispose atualizando tambien los enlaces de la lista que se hayan visto afectados. En definitiva, el contenedor funciona con objetos de tipo TElemento y desendientes. Y lo que yo quiero es no obligar al usuario a que su jerarquia de clases cuelgue de TElemento para poder usar el contenedor pero si no lo hago asi no podria usar los metodos antes descritos. Y creo que de la forma que lo he hecho aunque funcione ni es eficiente ni elegante. Con respeto al comentario de Delphius, tienes razon, delphi proporciona clases para lo que busco, pero como se suele decir si quieres lapas hay que mojarse el culo, y pense que la mejor manera de entender la poo en delphi es haciendome yo mismo un contenedor generico y viendo todas las dificultades que se me pueden presentar. En mi caso me quedo mejor con las cosas si le doy vueltas y vueltas hasta encontrar la solucion o al menos el camino para la solucion que si me lo dan todo hecho y mastiado. Soy un masoquista de la programacion que le vamos a hacer. Con respecto al supuesto despiste cometido por AI Gonzales nada mas agradecerte tu confucion ya que gracias a ello he encontrado un uso a las referencias de clase aunque sigo pensando que tu respuesta me sigue pareciendo mas logica aunque no funcionace ;) Gracias de antemano por las respuestas. Y bueno, siguo en mi linea de pedir disculpas por lo extenso de las respuestas. Un saludo. |
Yo tengo una opinión. Realmente, eso de querer trabajar indistintamente con cualquier objeto, sin depender de qué clase sea, a final de cuentas, ya se aleja de lo que es la POO. En ésta hay clases y jerarquías de clases, y uno espera tal o cual comportamiento de acuerdo a la jerarquía. Hacer clonaciones genéricas (si bien puede tener su uso), y, en general, intentar trabajar de manera arbitraría con cualquier objeto, está ya muy lejos del polimorfismo, no hay ningún comportamiento que puedas esperar o predecir porque en realidad no tienes objetos sino meros contenedores de datos.
Pero como digo, es sólo una opinión ;) // Saludos |
Cita:
|
Cita:
Salud OS |
Cita:
Me parece que hay algo en el modelo del dominio que está analizando y diseñando gushynet que niebla o entorpece la comprensión real y el propósito de cada clase. Si pudieramos conocer con más detalles, ya no con una comprensión micro sobre este problema en particular, sino como algo macro (la clase) tal vez podríamos llegar a formular alternativas. Saludos, |
Cita:
Salud OS |
La franja horaria es GMT +2. Ahora son las 07:35:45. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi