Por qué la tendrías que instanciar de nuevo?? no le veo motivo para hacerlo.
Si lees bien dije claramente :
O en todo caso, nada impide que se cree otra instancia de ésta y leer datos erróneos
Es decir, que puede suceder, que es distinto que tu lo hayas hecho y sea el caso.
Simplemente acoté que es un potencial peligro si uno no tiene el debido cuidado. Hoy quizá no cometas ese error, pero luego para cuando pase el tiempo y revises el mar de código y te pierdas es cuando surgen cosas como las que he descrito.
Basta con recorrer los foros para leer historias de objetos perdidos, duplicados y/o mala asignación de datos.
En mi caso, la forma principal está viva en todo el tiempo que la aplicación está viva.
Para aquellas clases que deben hacer uso constante o reiterado de datos que proviene de otra, lo de esperar es que tenga alguna visibilidad de atributo, o en otro caso de parámetro, que referencie a ésta. De este modo basta con hacer como:
MiVariable1 := FGlobal.Variable1;
Siendo FGlobal un atributo del tipo TVariable:
Type
TfrmMain = class...
private
FGlobal: TVariable;
...
Y si se quiere, y hasta quizá sea lo más recomendable, se define una propiedad que le aporta más seguridad al acceso a dicho campo.
Estas clases no debiera liberar este objeto, es más, hasta se puede diseñar para que no asuma el control de crearla. De hecho todo apunta, léase sobre "Experto en Información" y "Hacerlo Yo Mismo", a que quien cumple el rol de crear instancias de TVariable es la propia. O más formal, el llamado Singleton.
De ese modo la clase interesada en saber algo sobre alguna "variable global" mantiene la referencia a la "clase global" y no hay necesidad alguna de tener que pasar por el form.
Y listo, ahora nada de intermediarios. Hay tienes, he dado 2 opciones (no necesariamente exclueyentes) o maneras de evitar más acoplamiento, y que hasta incluso... un acoplamiento que podría ser innecesario.
1) Disponer un Singleton y que los interesados les soliciten a éste único objeto global.
2) Tener una variable de atributo que referencie a un objeto del tipo TVariable.
Estas opciones están pensadas para reducir el acoplamiento. Acoplamiento que hasta podría ser innecesario, y lleva a un código más estable, seguro y del que no hay que estar tan pendiente de los tiempos de vida de una clase para garantizar el acceso a un punto que desde un principio está pensado en ser global.
En tu propuesta ahora todo el que requiera de dicho recurso global resulta que debe pasar por el form principal primero. Entonces, ahora no sólo resultas que el resto de tus otros formularios ven incrementado su acoplamiento en 2: uno por el form principal, y otro por la clase global.
Pero además, y lo que es lo peor de todo, es ilógico tu diseño... Por un lado creaste una clase para tener en ella información global, pero a su vez la has "ocultado" su fácil acceso al asociarla a un form.
Piensa GLOBAL es GLOBAL. ¡No debes de ocultarla! A la larga es más problemático, ya no sólo tienes a tu clase global, sino que ahora ¡también lo es y debe serlo la form principal! Y no siempre es bueno que un form tenga este comportamiento.
Al final, cada quien resuelve el problema como mejor le acomoda, no? quiero decir, posiblemente no esté siguiendo todas las reglas de programación, pero sinceramente, prefiero esto al uso de variables de tipo global.
Las variables globales no son un peligro por propia naturaleza. Son un peligro si uno no las usa adecuadamente.
Y te voy diciendo que ya que quieres evitarte el uso de variables de tipo globales... Dime que es lo que ves en
O en tus
¿No es acaso esto una variable con comportamiento global cuando ahora TODOS los demás formularios deban invocar a ésta para pedirle algo que en realidad es para pedirle a otro?
Me parece que te tomaste demasiado personal mi comentario FerCastro.
Bien dices que cada uno toma las armas a como las puede usar, pero me parece que te falta. Te falta aprender que hay otras maneras, y más seguras y estudiadas. Hay que hacer un esfuerzo por hacer las cosas mejor y no simplemente a lo pelos.
Hay una cita que dice: "Hay dos formas de diseñar software: la primera es hacerlo tan simple que obviamente no hay deficiencias y la segunda es hacerlo tan complicado que no hay deficiencias obvias. La primera forma es mucho más difícil." de C.A.R Hore y otra de un tipo conocido por ser un gran crítico y gran especialista, "Cualquier tonto puede escribir código que un ordenador entiende. Los buenos programadores escriben código que los humanos pueden entender.", Martin Flower. U otra forma de decirlo: "Mucho del software hoy en día se parece a una pirámide egipcia: con millones de ladrillos apilados uno encima del otro, sin integridad estructural y hecho por pura fuerza bruta y miles de esclavos." de Alan Kay.
En cierta forma, estos grandes de la programación dicen que hay que tener bien pensado las cosas. Y no hay peor control en un software que un mal equilibrio entre acoplamiento y la cohesión. Negar esto es como ir por un barco a la deriva sin un plano.
No siempre lo que te parece simple y a como uno le sale es la mejor opción. Tenlo presente.
Lo digo en buen plan FerCastro. Yo no soy un experto en el tema, pero la poca experiencia que he tenido me ha dicho que es mejor escuchar a la Ingeniería de Software y sus buenas prácticas. Y hay quienes lo han resumido muy bien:
"Las buenas personas son más importantes que cualquier proceso. Buenas personas con un buen proceso siempre actuarán mejor que buenas personas sin procesos." Grady Booch
Hay que despertar el sentido crítico en todo momento y desarrollo de un software.
Saludos,
, depende, depende, depende, del tipo de aplicación.
). Y a como he dicho, el problema no son las variables globales... sino un mal uso y control de las mismas.
