FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Propiedades de clases
Hola a todos,
Tengo una duda sobre si se puede o no hacer cierta cosa en Delphi, os pongo en situación. Estoy diseñando un sistema de clases que implementan todas las reglas de negocio de mi sistema. El caso es que necesito obtener una lista de objetos para rellenar unos combos en la pantalla de edición de una clase. La idea es tener unas propiedades del tipo "ListaTareas" que sean TStringLists. Cada item de la lista tiene la cadena que se ha de mostrar en el combo y apunta a un objeto, en este caso, del tipo TTarea. Al aceptar los cambios la propiedad "Tarea" del objeto editado tendrá los valores (con Assign) del objeto seleccionado en el combo. Bien, todo esto ya funciona a las mil maravillas. El problema es ¿Donde va la propiedad "ListaTareas"? De momento es una propiedad de la clase TLinea que es la que se edita en la pantalla que os he explicado. La función GetListaTareas es suficientemente lista para que una instancia de TLinea sólo haga los cálculos una vez y después devuelva directamente la TStringList generada. El problema es que esa lista es relativamente grande y la clase TLinea tiene varias propiedades de este estilo (TTarea, TObjetivo....) y para cada instancia de TLinea (pueden haber muuuuuuuuuuuuchas a la vez en memoria) tenemos las TStringList instanciadas y todas ellas con los mismos valores. Lo que me gustaría es poder crear estas propiedades sólo una vez por clase, y no por instancia. En java existe el concepto de campos estáticos para este tipo de menesteres. En Delphi, sólo he encontrado los Class Methods, pero son métodos no propiedades, de manera que cada vez que se accediera al método se recalcularia la lista ya que no la podría guardar en ningún sitio. La idea es poder hacerlo sin tener que apoyarme en clases o módulos externos. ¿Conocéis alguna manera de poder hacer esto? Espero que me haya explicado bien, sinó me lo decís i os vuelco el millón de diagramas que corren por mi mesa
__________________
E pur si muove |
#2
|
||||
|
||||
¡Buen día a todos!
Con respecto a Cita:
Esto puede ser hecho com propiedades o simplemente con un par de métodos que permitan leer y escribir ese valor compartido. Lo importante es evitar duplicidad innecesaria. Espero esto sea de utilidad. Seguimos en contacto. Al González . |
#3
|
||||
|
||||
Buenas,
Primero, Al, perdona por tardar tanto en contestar, pero es que ando con demasiado lío. La solución que propones está bien, pero lo que quería era precisamente no tener que recurrir a variables globales. Os cuento cómo lo he solucionado, aunque si alguien me propone un diseño mejor lo cambio sin dudar. Al final he optado por la solución más simple, en lugar de implementar propiedades, lo he hecho con métodos que retornan TStrinList nuevas. Como estos métodos sólo tiene sentido que sean llamados por el módulo de interfaz gráfica (léase el TForm o el TWebModule de un cgi), dejo en su responsabilidad que tansolo llame al método una vez. No es la solución perfecta, pero si el programador hace un "uso correcto" no le veo demasiado problema.
__________________
E pur si muove |
#4
|
||||
|
||||
Cita:
Si la variable que utilizas para implementar la "propiedad de clase" la declaras en la sección [b]implementation[b] de la unidad entonces dicha variable no será vista ni podrá ser accedidad desde fuera. Dicho de otra forma, quedará bien encapsulada. // Saludos |
#5
|
||||
|
||||
Cita:
__________________
E pur si muove |
#6
|
|||
|
|||
Hola:
Dices, Marto, que lo has solucionado, pero hay algo que no entiendo del todo. Si utilizas esas variables globales, dentro de Implementation, como recomienda Roman, ¿significa que todos los TLinea utilizan la misma lista? Ya que en tu mensaje hablas en algún momento de que se hacen cálculos la primera vez que se solicita la lista, ¿significa eso que puede haber TLineas que devuelvan TTareas diferentes? En este caso eso te obligaría a mantener una especie de array o lista cada uno de cuyos elementos fuera a su vez uns lista con las Tareas, no sé si me explico, espero no estar liandolo. En cuanto a lo de evitar que cada instancia de TLinea mantenga un TStringList, puedo decirte que en ciertos componentes en que requiero una funcionalidad similar, y en que es importante saber la información de clase sin necesidad de haber ninguna instancia, lo que hago es crear un método de clase que recibe como parámetro un TList (o un TStrings, como prefieras), que se encarga de llenar. De esa forma, las instancias de TLineas no se encargan de mantener / destruir dichas listas sino que eso corresponde a quien las llamó, por ejemplo un TComboBox o un TListBox que quiere mostrarlas al usuario. Más o menos sería así: Código:
class procedure TLinea.TareasAsignadas(AList: TStrings); begin if Assigned(AList) then begin AList.Add ('Repartir'); AList.Add ('Comer'); ... end; end; Un saludo
__________________
Guía de Estilo |
|
|
|