Problema filosófico sobre elementos globales...

29/04/2006 - 13:06 por solved by design | Informe spam
Imaginemos un escenario en el que estemos construyendo una aplicación
grande pero descentralizada en el sentido de que está compuesta por varios
elementos que poco tienen que ver entre sí pero que es necesario que el
núcleo central los maneje de forma independiente.

Me surge una duda bastante gorda en cuanto a esto. En el mundo C++, cuando
un objeto necesitaba estar disponible a nivel de aplicación completa se
hacía global o local a un módulo con un método global que devolvía un
puntero (digamos referencia en el mundo .NET) a dicho objeto. Entonces
cada objeto local llamaba a ese método o referenciaba a esa variable
global.

En C# no están permitdas las variables ni los métodos globales...

La solución que se me ocurre es instanciar estas variables dentro de Main,
construir mi form global y pasarle a éste mediante métodos/constructor las
referencias a esos objetos "pseudo-globales". O lo mismo dentro de la
ficha principal respecto a todo lo demás.

Esta solución me parece un tanto "sucia" porque esos objetos son
independientes unos de otros, y no hay relación de "es uno" ni de
"contención", y si encima son muchos la cosa se "ensucia" más todavía:

o1;
o2;
o3;
...
oN;

Form f=new Form(o1,o2,...,oN);


Si implementamos el modelo MVC con un contenedor controlador, enmarronamos
algo más la cosa porque encima hay que pasar referencias hasta del color
del suelo, y en lugar de una serie de objetos independientes entre sí que
se pasan mensajes estamos construyendo una aplicación que sería una serie
de referencias que se pasan entre sí (al más puro estilo "un montón de
métodos que menean los datos entre sí" del paradigma tradicional).

Quizás esté confundio, pero me gustaría que me acararais un poco el tema.
¿Cuál es la forma de hacer del .NET? Etc, porque me parece que "esto no
está en los libros".


Los espejos se emplean para verse la cara; el arte para verse el alma.

Preguntas similare

Leer las respuestas

#1 Alberto Poblacion
29/04/2006 - 13:34 | Informe spam
"solved by design" wrote in message
news:
En C# no están permitdas las variables ni los métodos globales...



¿Y por qué no usas variables o métodos estáticos?

public class Globales
{
public static string Var1;
private static string var2;
public static string M1() { return var2; }
}

Desde cualquier punto de la aplicación puedes acceder a Globales.Var1, o
ejecutar Globales.M1().
Respuesta Responder a este mensaje
#2 solved by design
29/04/2006 - 13:41 | Informe spam
On Sat, 29 Apr 2006 13:34:41 +0200, Alberto Poblacion
wrote:

"solved by design" wrote in message
news:
En C# no están permitdas las variables ni los métodos globales...



¿Y por qué no usas variables o métodos estáticos?

public class Globales
{
public static string Var1;
private static string var2;
public static string M1() { return var2; }
}

Desde cualquier punto de la aplicación puedes acceder a
Globales.Var1, o
ejecutar Globales.M1().





No, si hay días... Lo curioso es que todos los objetos globales que me
hacen falta pueden muy bien ser estáticos.

Gracias 1000 :-)


Los espejos se emplean para verse la cara; el arte para verse el alma.
Respuesta Responder a este mensaje
#3 Daniel A. Calvin
01/05/2006 - 04:35 | Informe spam
Hola

Podes utilizar metodos estaticos, pero sigue siendo una solución fea.

Yo utlizría el patrón singleton.
Te pego aqui una URL que tiene una implementación bastante simple y
confiable.

http://www.dofactory.com/Patterns/P...leton.aspx

Bueno, espero te sirva. Es para usar con mesura.

Daniel Calvin
MCP


"solved by design" escribió en el mensaje
news:
Imaginemos un escenario en el que estemos construyendo una aplicación
grande pero descentralizada en el sentido de que está compuesta por varios
elementos que poco tienen que ver entre sí pero que es necesario que el
núcleo central los maneje de forma independiente.

Me surge una duda bastante gorda en cuanto a esto. En el mundo C++, cuando
un objeto necesitaba estar disponible a nivel de aplicación completa se
hacía global o local a un módulo con un método global que devolvía un
puntero (digamos referencia en el mundo .NET) a dicho objeto. Entonces
cada objeto local llamaba a ese método o referenciaba a esa variable
global.

En C# no están permitdas las variables ni los métodos globales...

La solución que se me ocurre es instanciar estas variables dentro de Main,
construir mi form global y pasarle a éste mediante métodos/constructor las
referencias a esos objetos "pseudo-globales". O lo mismo dentro de la
ficha principal respecto a todo lo demás.

Esta solución me parece un tanto "sucia" porque esos objetos son
independientes unos de otros, y no hay relación de "es uno" ni de
"contención", y si encima son muchos la cosa se "ensucia" más todavía:

o1;
o2;
o3;
...
oN;

Form f=new Form(o1,o2,...,oN);


Si implementamos el modelo MVC con un contenedor controlador, enmarronamos
algo más la cosa porque encima hay que pasar referencias hasta del color
del suelo, y en lugar de una serie de objetos independientes entre sí que
se pasan mensajes estamos construyendo una aplicación que sería una serie
de referencias que se pasan entre sí (al más puro estilo "un montón de
métodos que menean los datos entre sí" del paradigma tradicional).

Quizás esté confundio, pero me gustaría que me acararais un poco el tema.
¿Cuál es la forma de hacer del .NET? Etc, porque me parece que "esto no
está en los libros".


Los espejos se emplean para verse la cara; el arte para verse el alma.
Respuesta Responder a este mensaje
#4 Alfredo Novoa
01/05/2006 - 05:47 | Informe spam
On Sun, 30 Apr 2006 23:35:28 -0300, "Daniel A. Calvin"
wrote:

Hola

Podes utilizar metodos estaticos, pero sigue siendo una solución fea.

Yo utlizría el patrón singleton.



Pues yo no veo en que es más bonito.


Saludos
Alfredo
Respuesta Responder a este mensaje
#5 solved by design
01/05/2006 - 11:31 | Informe spam
"Alfredo Novoa" wrote in message
news:
On Sun, 30 Apr 2006 23:35:28 -0300, "Daniel A. Calvin"
wrote:

Hola

Podes utilizar metodos estaticos, pero sigue siendo una solución fea.

Yo utlizría el patrón singleton.



Pues yo no veo en que es más bonito.


Saludos
Alfredo



Hombre, bonito no es, pero queda todo encapsulado dentro de la propia clase,
que es la idea. Así, la primera vez que se llame se crea la instancia, y las
siguientes se usa... Vamos, creo que lo he entendido bien.

Atender y entender para aprender.
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida