Propiedades de clases

[marto]

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 ;)

[Al González]

¡Buen día a todos!

Con respecto a
marto comentó:
...poder crear estas propiedades sólo una vez por clase, y no por instancia...poder hacerlo sin tener que apoyarme en clases o módulos externos...
debo decir que los campos estáticos, es decir, aquellos que existen sólo una vez por clase y no por instancia de esa clase, no existen formalmente en Delphi (por lo menos hasta la versión 7). Sin embargo, es posible implementar propiedades cuyos métodos de lectura y escritura accedan a una variable global, en lugar de un campo de la clase. De esta manera, todas las instancias de la misma clase compartirán el mismo espacio de memoria para el valor de una de sus propiedades.

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 :).

[marto]

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.

[roman]

La solución que propones está bien, pero lo que quería era precisamente no tener que recurrir a variables globales.

Pero en este caso está muy bien justificado. Evitar el uso de variables globales se recomienda más que nada para evitar posibles efectos colaterales originados por una modificación inadvertida de la variable.

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

[marto]

la declaras en la sección [b]implementation[b] de la unidad entonces dicha variable no será vista ni podrá ser accedidad desde fuera.


Ops!!! eso no lo sabía!!!!! pues es justamente lo que andaba buscado. Si lo piensas, es como si fuese una propiedad de classe , pero pivda ;)

[andres1569]

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í:

class procedure TLinea.TareasAsignadas(AList: TStrings);
begin
if Assigned(AList) then
begin
AList.Add ('Repartir');
AList.Add ('Comer');
...
end;
end;El que esas cadenas se almacenen dentro de la definición de clase o en una lista de variables globales es algo circunstancial.

Un saludo

[marto]

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?


No, todas son iguales, por eso es correcto tener una sola variable y una sola TSTringList


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ó


Esa es una solución muy parecida a la que comento que de momento tengo implementada (la que no usa variables) .
Diferencias:
Mi método es una función que retorna la lista, eso es circunstancial ya que la responsabilidad de la destrucción es de la classe externa igualmente y me "ahorro" tener que instanciar cada vez, o sea que en el fondo esa diferencia es trivial.
Mi método no es de clase, eso sí es una diferencia, el problema es que para generar la lista necesito acceder a la BD y para eso necesito una variable privada de la clase que apunta al DataModule, y si declaro el método de classe no tengo acceso a esa variable.

[andres1569]

Ok. Ok. Ok.

(iba a poner un Ok. solamente pero estos foros nuevos no dejan escribir menos de 10 letras :D )