Existen los modulos en en C#

17/01/2007 - 04:48 por RobWare.Ruiz | Informe spam
Soy nuevo en C# vengo de la tradicion de Visual Basic 6.0 y quisiera que me
aterrizaran unos concepto, existen los modulos en C# como los que existen en
Visual Basic?, como se pueden declarar variables globales al proyecto?, yo
normalmente cuando trabajo en proyectos de base de datos, creo una conexion
con un objeto global que referencio durante todo el proyecto y simplemente
abro la conexion cuendo la requiero y la cierro cuando no la necesito mas, se
puede implementar lo mismo en C#, y en caso de que no como se podría hacer?

Preguntas similare

Leer las respuestas

#6 Carlos M. Calvelo
18/01/2007 - 02:35 | Informe spam
Alfredo Novoa schreef:

El caso de las variables estáticas es una barbaridad mucho más grande.
Estamos obligados a asociar cada variable global al nombre de un tipo,
lo cual no tiene ninguna lógica.



Bueno, es que en el caso de una clase con variables globales no se
trata de un 'tipo' sino de un 'módulo' y por eso se llama 'clase'.
Lógico!

No está nada claro lo que es una clase. A veces se usa como sinónimo
de tipo, otras veces como sinónimo de tipo por referencia. Otras veces
se usa con el significado de la definición de un tipo, y luego dos
lineas más abajo se usa como sinónimo de tipo. Muchas otras veces se
dan definiciones completamente informales, etc, etc.



pues eso ... y otras veces 'módulo' que es un 'tipo' de 'clase' con
un conjunto vacio como dominio y operaciones definidas sobre
los elementos de este conjunto que tienen como rango un
conjunto de 'cosas', que se llaman 'objetos'.

[ Perdón, pero no pude resistir la tentación. :-) ]

Saludos,
Carlos
Respuesta Responder a este mensaje
#7 RobWare.Ruiz
18/01/2007 - 04:01 | Informe spam
"Octavio Hernandez" wrote:

Rob,

>> Conceptualmente una clase no es el sitio natural donde uno pondria
>> variables,
>> funciones y procedimientos globales.

Bueno, el mundo no es idealmente orientado a objetos, para qué negarlo
(aunque
yo, como muchos, pienso que en general es más orientado a objetos que
procedimental,
funcional, relacional, o cualquier otra cosa inventada hasta la fecha).

Los creadores de .NET (como antes los de Java) decidieron utilizar la clase
como
elemento de modularización fundamental, y al menos en C# y VB.NET (también!)
*TODO* debe estar dentro de una clase.

Supón que los que inventaron C# hubieran decidido crear una palabra clave
"module",
equivalente a la secuencia "static class" (podrían haberlo hecho sin mayor
problema, creo).

module VariablesGlobales
{
public static int Numero;
}

Bueno, pues ya tienes un módulo!

Te diré que cuando en VB.NET defines un Module, estás creando ni más ni
menos
que una clase (sólo tienes que examinar el ensamblado con ILDASM o Reflector
para convencerte). Un módulo de VB es un tipo especial de clase que solo
contiene
métodos y variables "globales".

La otra diferencia que queda es que en VB (bajo ciertas circunstancias)
podrías referirte
a la variable simplemente usando su nombre: Numero. La exigencia de C# de
poner el
nombre de la clase ("módulo") delante del nombre de la variable:

VariablesGlobales.Numero

te protegerá de uno de los mayores peligros de las variables globales, las
colisiones de
nombres. Y te permitirá de manera segura tener diferentes variables llamadas
Numero
en diferentes "módulos" sin posibilidad de confusión para el compilador.

Salu2 - Octavio








Muchas gracias, es muy ilustrativa la explicacion del ensamblado de VB.
Respuesta Responder a este mensaje
#8 Alfredo Novoa
18/01/2007 - 12:27 | Informe spam
On 17 Jan 2007 17:02:10 -0800, "Carlos M. Calvelo"
wrote:


Alfredo Novoa schreef:

El caso de las variables estáticas es una barbaridad mucho más grande.
Estamos obligados a asociar cada variable global al nombre de un tipo,
lo cual no tiene ninguna lógica.



Bueno, es que en el caso de una clase con variables globales no se
trata
de un 'tipo' sino de un 'módulo' y por eso se llama 'clase'. Lógico!



Bueno, eso en el caso de que solo haya variables globales, pero se
pueden mezclar variables globales con componentes del tipo.

En el caso de una clase estática tienes toda la razón en que eso ya no
es un tipo sino que es solo un módulo.

Vamos, que es difícil liar más las cosas.


Saludos
Alfredo
Respuesta Responder a este mensaje
#9 Hernan
18/01/2007 - 12:54 | Informe spam
Estuve reflexionando la
respuesta, y desde un punto de vista meramente argumental, quisiera compartir
mi descontento. Conceptualmente una clase no es el sitio natural donde uno
pondria variables, funiones y procedimientos globales; por que lo que tengo
entendido una clase, es una abstraccion de una entidad de información y no
cuadra con un repositorio de variables, funciones y procedimientos.



Podrías utilizar el patrón singleton llamando a esa clase con un
nombre del
estilo "ProveedorDeServiciosCentralizados" o algo mas concreto.

Eso sí, trata de pensar bien el diseño de esos servicios. Una señal
que debes
trabajar un poco mas el diseño es cuando cambias el nombre de la clase
a
"RejunteDeCosasQueNoSeDondePonerlas" y aún así sigue representando su
contenido.

-H.
Respuesta Responder a este mensaje
#10 Alfredo Novoa
18/01/2007 - 13:17 | Informe spam
Hola,

On Thu, 18 Jan 2007 01:08:10 +0100, "Octavio Hernandez"
wrote:

Bueno, el mundo no es idealmente orientado a objetos, para qué negarlo
(aunque
yo, como muchos, pienso que en general es más orientado a objetos que
procedimental,
funcional, relacional, o cualquier otra cosa inventada hasta la fecha).



Esto suena como: en el mundo hay 'cosas' así que podemos ignorar 2500
años de acumulación de conocimientos matemáticos.

La filosofía de la OO me recuerda bastante a la de las películas de
artes marciales de serie B.

Por otra parte la orientación a objetos es independiente de si un
lenguaje es procedimental, funcional o relacional.

C# es procedimental OO, F# es mezcla de funcional, imperativo y OO, y
Tutorial D es relacional, declarativo, imperativo y en cierto modo
también OO.


Los creadores de .NET (como antes los de Java) decidieron utilizar la clase
como
elemento de modularización fundamental, y al menos en C# y VB.NET (también!)
*TODO* debe estar dentro de una clase.



Lo cuál prueba que los creadores de .NET sabían más bien poquito de
teoría de lenguajes de programación.

Mezclar los conceptos de tipo y módulo no es para nada una buena idea.

Supón que los que inventaron C# hubieran decidido crear una palabra clave
"module",
equivalente a la secuencia "static class" (podrían haberlo hecho sin mayor
problema, creo).

module VariablesGlobales
{
public static int Numero;
}

Bueno, pues ya tienes un módulo!



Aquí la palabra static no tiene sentido.

La exigencia de C# de
poner el
nombre de la clase ("módulo") delante del nombre de la variable:

VariablesGlobales.Numero

te protegerá de uno de los mayores peligros de las variables globales, las
colisiones de
nombres. Y te permitirá de manera segura tener diferentes variables llamadas
Numero
en diferentes "módulos" sin posibilidad de confusión para el compilador.



¿Y para que están entonces los "namespaces"

namespace VariablesGlobales
{
public int Numero;
}


Saludos
Alfredo
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida