Espacios de Nombres

07/11/2004 - 15:14 por Ana | Informe spam
Los espacios de nombre son los directorios en los que estan
guardados los archivos .cs ?

Gracias y saludos.

Preguntas similare

Leer las respuestas

#1 Octavio Hernandez
07/11/2004 - 16:01 | Informe spam
Ana,

Los espacios de nombres no tienen NINGUNA relación con directorios.
Son un recurso lógico para permitir la identificación de nuestras clases sin
que pueda haber confusión con las de otros desarrolladores.
Por ejemplo, si vas a crear una clase Cliente para tu aplicación de
Facturacion, puedes hacerlo así:

namespace Ana.Facturacion
{
public class Cliente
{
}
}

Tu clase tendrá un nombre "corto", Cliente, y un nombre "largo" o
"cualificado", Ana.Facturacion.Cliente, por el que podrá ser distinguido de
otras clases Cliente que puedan haber por ahí en caso de ambigüedad.

Esa clase puedes compilarla dentro de un ensamblado cualquiera, sin
restricciones con respecto al directorio en que coloques éte, etc.

Slds,

Octavio

"Ana" escribió en el mensaje
news:089c01c4c4d4$22748930$
Los espacios de nombre son los directorios en los que estan
guardados los archivos .cs ?

Gracias y saludos.
Respuesta Responder a este mensaje
#2 Alfredo Novoa
07/11/2004 - 23:44 | Informe spam
On Sun, 7 Nov 2004 16:01:13 +0100, "Octavio Hernandez"
wrote:

Los espacios de nombres no tienen NINGUNA relación con directorios.



Bueno, tienen una pequeña relación que puede que sea la causa de la
confusión.

Cuando desde el Visual Studio creas un directorio, el nombre del
directorio se añade al namespace por defecto que pone el VS cuando
creas una clase en ese directorio.

Facturacion, puedes hacerlo así:

namespace Ana.Facturacion
{
public class Cliente
{
}
}



Puedes pero no debes, es un ejemplo de mal diseño.



Saludos
Respuesta Responder a este mensaje
#3 Octavio Hernandez
08/11/2004 - 01:05 | Informe spam

Puedes pero no debes, es un ejemplo de mal diseño.




Alfredo,

Era sólo un ejemplo trivial... ¿Por qué dices que es un mal diseño? ¿Cómo
organizas tú las clases normalmente? Me interesa, siempre hay un ángulo de
visión que uno no ha tenido en cuenta...

Slds,

Octavio
Respuesta Responder a este mensaje
#4 Alfredo Novoa
08/11/2004 - 14:23 | Informe spam
On Mon, 8 Nov 2004 01:05:42 +0100, "Octavio Hernandez"
wrote:

Era sólo un ejemplo trivial...



Ya lo se, pero es un mal ejemplo. Y no veas la cantidad de gente que
lleva malos ejemplos de ese tipo a la práctica. Cuesta el mismo
trabajo poner un buen ejemplo trivial.

¿Por qué dices que es un mal diseño?



Pues por que no es un diseño apropiado para "mapear" una tabla de
clientes, que suele ser el propósito de este tipo clases.

Mapear una tabla con un OBJETO del estilo de un DataTable está mucho
mejor. Las tablas son objetos.

organizas tú las clases normalmente?



Pues en una aplicación de facturación cada clase suele corresponder a
un formulario.

Si hubieses puesto:

namespace Facturacion
{
public class Clientes : System.Windows.Forms.Form
{

Entonces me parecería bien (aunque yo creo que se puede hacer todavía
mejor, pero eso es otra historia :).


Un objeto Clientes puede contener un montón de objetos DataTable.


Saludos
Respuesta Responder a este mensaje
#5 Octavio Hernandez
09/11/2004 - 10:31 | Informe spam
Alfredo,

Gracias por la explicación, ahora entiendo lo que querías decir...

¿No estás a favor de la representación de las entidades que resultan del
diseño mediante clases, no? La verdad es que yo no lo tengo muy claro,
ciertas cosas que he visto en el mundo Java me han llegado a parecer
verdaderas aberraciones... Pero de una manera muy intuitiva, sería natural
pensar que si la aplicación manipula clientes, debe haber una clase Cliente,
¿no?

Slds,

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