Namespaces

Em um dos primeiros artigos, discutimos brevemente namespaces. Você provavelmente reconhece a palavra-chave, porque ela é encontrada na maioria dos arquivos que contêm código C#, geralmente quase no topo. Um espaço de nomes é essencialmente uma forma de agrupar um conjunto de tipos, por ex. classes, em um espaço próprio. Quando o Visual Studio gera um novo projeto para você, ele também gera um espaço para nome padrão no qual ele coloca o primeiro arquivo (pelo menos isso é verdadeiro para o tipo de projeto App do Console). Poderia ser assim:

using System;  

namespace MyProject  
{  
    class Program  
    {  
    static void Main(string[] args)  
    {  
        // More code below this....

Nesse caso, o namespace "MyProject" agora faz parte do aplicativo e, ao usar suas classes fora dele, você terá que prefixar o nome da classe com o nome do namespace. Você vê exatamente a mesma coisa quando você quer usar algo enterrado no framework .NET, como este:

System.IO.File.ReadAllText("test.txt");

Neste caso, usamos o método ReadAllText() encontrado na classe File que existe no System.IO namespace . Claro, seria tedioso escrever um nome tão longo toda vez que você quisesse usar uma classe de um namespace, então o C # permite que você "importe" um namespace inteiro para o escopo do seu arquivo com uma instrução . Mais uma vez, você pode já conhecê-los, porque normalmente você pode encontrá-los no topo de seus arquivos C #. Para o exemplo acima, se precisarmos da classe File mais de uma vez, faria sentido importar o namespace System.IO com uma instrução using como esta:

using System;
using System.IO;
// More using statements here...

Por que você precisa de namespaces?

Se você acabou de começar a programar, pode se perguntar para o que precisamos de namespaces. Por que não colocar todas as suas classes nos mesmos namespaces para que estejam sempre acessíveis? Você tem um ponto válido, mas somente se seu projeto é muito pequeno. Assim que você começar a adicionar mais e mais classes, faz muito sentido separá-las em namespaces. Ele simplesmente torna mais fácil para você encontrar seu código, especialmente se você coloca seus arquivos em pastas correspondentes - na verdade, se você adicionar uma pasta ao seu projeto e depois adicionar uma classe a ela, o Visual Studio a colocará automaticamente em um arquivo correspondente. namespace. Portanto, se você criar uma pasta em MyProject chamada MyFolder , as classes adicionadas a essa pasta serão, por padrão, colocadas em um namespace chamado MyProject.MyFolder .

Um ótimo exemplo do motivo pelo qual os namespaces são necessários é o próprio .NET framework. Basta pensar se TODAS as classes no framework estavam apenas flutuando em um namespace global - seria uma bagunça! Em vez disso, eles os organizaram muito bem, com o System como o namespace raiz para a maioria das classes e, em seguida, sub-namespaces como System.IO para material de entrada/saída, System.Net para material relacionado à rede e System.Net.Mail para material relacionado a email.

Nome Conflitos com Namespaces

Como mencionado, os namespaces também estão lá para encapsular seus tipos (geralmente classes), para que possam existir dentro de seu próprio domínio. Isso também significa que você está livre para criar classes com o mesmo nome que as encontradas em outro lugar em seu projeto ou até mesmo no .NET framework. Por exemplo, você pode decidir que precisa de uma classe de arquivo própria. Como vimos nos exemplos anteriores, essa classe já existe no namespace System.IO, mas você está livre para criar uma em seu próprio namespace, desta forma:

using System;  

namespace MyProject.IO  
{  
    class File  
    {  
    public static void HelloWorld()  
    {  
        Console.WriteLine("Hello, world!");  
    }  
    }  
}

Agora, quando você quiser usá-lo em seu projeto, por exemplo no seu método Program.cs Main (se você estiver trabalhando em um Console App, como eu sou), você pode escrever o nome completo:

MyProject.IO.File.HelloWorld();

Mas você também pode importar o namespace, como acontece com qualquer outro namespace (interno ou definido pelo usuário), graças à instrução using. Aqui está um exemplo mais completo:

using System;
using MyProject.IO;

namespace MyProject
{
    class Program
    {
    static void Main(string[] args)
    {
        File.HelloWorld();
    }
    }
}

Por enquanto, tudo bem! No entanto, e se você também quiser usar a classe File do namespace System.IO? Bem, é aí que o problema começa, porque se você importar esse espaço de nomes também, com uma instrução using, o compilador não saberá mais a qual classe de arquivo você está se referindo - a nossa própria ou aquela do namespace System.IO. Isso pode ser resolvido importando apenas um dos namespaces (idealmente aquele do qual você usa a maioria dos tipos) e, em seguida, qualificando totalmente o nome do outro, como neste exemplo:

using System;
using System.IO;

namespace MyProject
{
    class Program
    {
    static void Main(string[] args)
    {
        MyProject.IO.File.HelloWorld();
    }
    }
}

Mas é um pouco trabalhoso digitar cada vez, especialmente se sua turma estiver ainda mais profundamente aninhada em namespaces, por exemplo, MyProject.FileStuff.IO.File. Felizmente, o C # tem uma solução para isso.

Usando a diretiva Alias

Para encurtar muito o nome do namespace, você pode importar o namespace com um nome diferente, com uma diretiva Using Alias. Observe como eu faço exatamente isso no próximo exemplo:

using System;
using System.IO;
using MyIO = MyProject.IO;

namespace MyProject
{
    class Program
    {
    static void Main(string[] args)
    {
        File.ReadAllText("test.txt");
        MyIO.File.HelloWorld();
    }
    }
}

A mágica acontece na terceira linha, onde eu pego o namespace MyProject.IO e dou um nome mais curto (MyIO), que pode ser usado quando queremos acessar tipos dele. Neste ponto, não estamos salvando muitas teclas, mas, novamente, você deve imaginar nomes e níveis de namespaces ainda maiores e, acredite, eles podem ficar bastante longos e aninhados.

Resumo

Os namespaces oferecem a oportunidade de encapsular seus tipos em "espaços nomeados", o que permite obter uma estrutura melhor em seu código, além de ter várias classes com o mesmo nome, contanto que existam em namespaces separados.