Propiedades de clases

[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]

Empezado por marto

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]

Empezado por roman

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]

Empezado por andres1569

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

Empezado por andres1569

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 )