ASánchezDíaz

Autoaprendiendo .NET y otras cosas


Manual C# – Capítulo 1.1. Espacios de nombres

Una característica de .NET son los espacios de nombres o namespaces.

Los espacios de nombres (en adelante namespaces) son una forma de ordenar las diferentes clases que creemos en nuestra aplicación. Para que te hagas una idea, vamos a establecer una analogía con la vida real. Supongamos que el código fuente que escribimos para nuestra aplicación sea un archivador.

En cada carpeta del archivador guardaremos las clases que creemos en función de la clase, de forma que una clase de un namespace es visible para el resto de clases de ese namespace.

Yo, personalmente, guardo todos los archivos de un mismo namespace en una misma carpeta en el código fuente, aunque no es imprescindible, a mi me ayuda a tener el código más organizado.

Para definir un namespace se usa la sintaxis:

namespace
{
//Clases que corresponden al namespace
}

Por ejemplo, supongamos que estamos desarrollando un programa que llamaremos “MiPrograma”. El namespace principal lo llamaremos MiPrograma y lo declaramos:

namespace MiPrograma
{
//Clases que corresponden al namespace MiPrograma
}

Consideramos que nuestra aplicación debería tener una carpeta para almacenar un tipo de clases determinado, por ejemplo, clases que se encarguen de realizar una función parecida, tal como consultas a una base de datos. Crearemos un nuevo namespace para almacenar estas clases y este nuevo namespace debería estar incluido en el namespace principal.

Llamaremos a este namespace DAL (Data Access Layer, capa de acceso a datos) aunque puedes llamarlo como quieras. Ya que este namespace debe estar incluido en el principal, la forma de declararlo es:

namespace MiPrograma.DAL
{
//Clases que corresponden al namespace MiPrograma.DAL
}

Fíjate que en nuestra analogía, hemos creado un nuevo archivador, llamado DAL, que hemos almacenado dentro de otro archivador principal, llamado MiPrograma.

Supongamos que ya hemos creado varias clases, tanto en el namespace principal como en el namespace DAL. La estructura “visual” sería:

namespace MiPrograma
{
	clase 1
	clase 2
	namespace DAL
	{
		clase DAL1
		clase DAL2
	}
}

Con esta estructura, la clase 1 sabe de la existencia de la clase 2, pero no puede ver qué clases hay dentro del namespace DAL, es decir, no sabe de la existencia de las clases DAL1 y DAL2.

Para esto, se usan las claúsulas using.

Antes de explicar la claúsula using, es necesario tener una noción de cómo se crea una clase, por ejemplo, la clase1.

La sintaxis es simple:

class clase1
{
// propiedades
// métodos
}

Por defecto, C# creará la clase1 como privada, es decir, el contenido de la clase1 sólo puede ser accesible desde su elemento contenedor. Esto es lo que se conoce como nivel de accesibilidad. Podemos especificar el nivel de accesibilidad de una clase, objeto, método o propiedad con los modificadores de acceso:

private: es el nivel de accesibilidad más restrictivo, la clase sólo es accesible desde el tipo contenedor
protected internal: el acceso está restringido al proyecto actual o a los tipos contenedores de la clase contenedora
internal: acceso limitado al proyecto actual
protected: acceso limitado a la clase contenedora o a los tipos derivados de esta clase.
public: no hay restricción de acceso

No te preocupes si no entiendes esto muy bien, simplemente quédate con que existen unas limitaciones en la accesibilidad a las clases en un proyecto de C#. Si quieres ampliar información sobre este tema:

Niveles de accesibilidad (C#)

Volvamos de nuevo a la claúsula using.

En el esquema anterior, veíamos la organización de las clases en namespaces MiPrograma y DAL, estando DAL incluido en el namespace principal, llamado MiPrograma. Si queremos acceder desde la clase1, ubicada dentro del namespace MiPrograma a la clase DAL1 ubicada dentro del namespace DAL, tenemos que usar en la clase1 la claúsula using, de forma que la clase1 quedaría:

using MiPrograma.DAL

namespace MiPrograma
{
	class clase1
	{
	// propiedades
	// métodos
	}
}

Lo que hemos hecho es crear una clase llamada clase1, como ves ubicada dentro del namespace MiPrograma (pero fuera del namespace DAL), y le hemos “informado” de que existe un namespace llamado DAL, que contiene otras clases.

Vamos a poner un ejemplo más intuitivo. Vamos a crear un equipo de futbol.

El namespace principal lo llamaremos Fútbol y dentro de este namespace habrá una clase llamada Equipo.

Un namespace secundario dentro de Fútbol se llamará Elementos (por ejemplo) y contendrá una clase llamada Jugador. La estructura sería:

namespace Futbol
{
	Equipo (clase)
	namespace Elementos
	{
	Jugador (clase)
	}
}

Un equipo de fútbol usualmente está formado por 11 jugadores (bueno, más si contamos con la plantilla entera), por lo que inevitablemente la clase equipo debe tener 11 objetos Jugador… pero no podemos acceder a la clase Jugador desde fuera de su namespace. Si creamos la clase Equipo está debe tener la estructura:

namespace Futbol
{
	class Equipo
	{
		Jugador jugador1;
		Jugador jugador2;
		...
		// otras propiedades
		// métodos
	}
}

En este ejemplo, la clase Equipo tiene 11 propiedades (sólo he mostrado los dos primeros) del tipo Jugador.

Esto nos dará un error, porque la clase equipo no conoce de la existencia de la clase Jugador, a menos que hagamos esto:

using Futbol.Elementos

namespace Futbol
{
	class Equipo
	{
		Jugador jugador1;
		Jugador jugador2;
		...
		// otras propiedades
		// métodos
	}
}

Con la claúsula using Futbol.Elementos le hemos dicho a la clase Equipo que puede usar la información (accesible) de la clase Jugador o cualquier otra clase incluida en el namespace Elementos. Le hemos dado la llave del archivador.

No te preocupes si no tienes muy claro aún la declaración de propiedades, métodos, objetos… no es el momento.

Lo importante de este capítulo es saber que existen los namespaces y que sirven para organizar el código de una forma eficiente y que estos namespaces tienen un nivel de accesibilidad determinado. Obviamente es necesario manejar todo esto para tener soltura, pero todo llegará.

Cuando empecemos a programar todo se hará más sencillo de entender.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *