Usando Namespaces profissionalmente

É isso ai pessoal, NAMESPACEs, eis o nosso tema de hoje. O que a princípio aparenta ser mais um dos novos conceitos do .net, veremos que o mesmo tem muito a ser explorado, e assim faremos, tentando extrair todo o potencial dessa funcionalidade do Framework, além de aproveitarmos a oportunidade para analisar a diretiva using[Imports, seu correspondente no VB.NET].

Didaticamente, namespaces são agrupamentos lógicos de elementos, sejam eles classes ou mesmo outros namespaces, e que dentre outras, tem como funcionalidade evitar conflito de nomes nesse universo da computação distribuída na web. A seguir temos um exemplo da utilização dos namespaces com o objetivo de evitar conflito de nomes [conflito do nome de classes]. Interessante observar que temos mais de um namespace num mesmo assembly.

Particularmente prefiro postulá-los, bem como implementá-los e utilizá-los, como um agrupamento lógico de funcionalidades que compõem uma aplicação. Lógico, porque os namespaces independem do assembly que o implementa, podendo inclusive ser composto por vários deles [como veremos em nosso exemplo adiante]. Quanto às Funcionalidades, prefiro essa definição pelo seguinte: Dentre as boas práticas de programação, sempre vi o “Reaproveitamento de Código” como uma das mais importantes, por meio dela obtemos alguns benefícios tais como, produtividade, segurança e facilidade de manutenção. Era assim com as linguagens estruturadas, onde tínhamos as funções, rotinas e procedures, geralmente agrupadas em bibliotecas. Na codificação ASP, as tínhamos agrupadas em arquivos, e essas que eram utilizadas via diretiva Include, hoje, no período .net da programação, temos os namespaces que vão bem além de tudo isso, sendo, o agrupamento de funções mais uma das benfeitorias obtidas.

O fato é que nossos programas são organizados e compostos de namespaces, sendo, do ponto de vista do programa que os utiliza, classificados em: internos [quando o programa implementa seus próprios namespaces internamente – ver Código 1] ou externos, quando esse faz uso de funcionalidades implementadas em assemblies diferentes.

O Framework .Net, nos disponibiliza um conjunto considerável de funcionalidades agrupadas em vários namespaces [implementados em diversas dlls] e utilizados em nossos programas conforme necessidade do projeto e as características específicas de cada namespace [daí a funcionalidade], por exemplo, o code-behind de um webservice, precisa das funcionalidades implementadas no namespace System.Web.Service [assembly, System.Web.Service.dll], para tal precisamos utilizar a diretiva using [vista com mais detalhes adiante] além de referenciar a dll que implementa o namespace [opção de compilação /r, do utilitário CSC].

Os namespaces, como muita coisa no mundo .net é hierárquico, assim em nosso exemplo dos webServices, fazemos referencia ao namespace System.Web.Service, que hierarquicamente está contido no namesace System.Web [também contido no System], que contém várias funcionalidades para implementação das aplicações Web [as ASP.Net Applications], no entanto, o grau de especialização dos WebServices é tamanho que suas funcionalidades foram implementadas num assembly diferente. [o namespace System.Web, esta implementado no assembly System.dll; e o assembly System.Web.dll, contém algumas especialidades para aplicações Web como System.Web.UI, System.Web.Configuration, System.Web.Mail, etc.

Em nossas aplicações, podemos [e devemos] seguir o mesmo princípio, agrupando funcionalidades em namespaces, assim, no desenvolvimento de uma solução web, ganharíamos em produtividade [uma vez que teríamos equipes desenvolvendo um namespace com Web Controls personalizados, outras desenvolvendo o namespace para acesso à dados, controle de transações, e uma terceira equipe implementando webServices para integração com outros sistemas]. Simplicidade na manutenção, “dividir para conquistar”, nada mais desgastante em grandes projetos que sua manutenção, principalmente num emaranhado de códigos, e ai a especialização das rotinas em namespaces auxilia consideravelmente nesses casos. Além disso, o desenvolvimento de classes agrupadas em namespaces abre caminho para comercialização de idéias inovadoras e funcionais, como referencia temos empresas especialistas na implementação de controles [Windows ou Web] como por exemplo a ComponenteOne – http://www.componentone.com, Infragistics - http://www.infragistics.com dentre outras. Por fim, um aspecto interessante é a possibilidade de personalizarmos, nosso código nomeando os namespaces como o nome da nossa empresa ou mesmo do projeto.

A diretiva Using

Falar em namespace, praticamente nos obriga comentar sobre essa diretiva, afinal, é através dela que os namespaces são utilizados, bom, não necessariamente, afinal se considerarmos a hierarquia: Namespace -> Classe -> Método, podemos até dispensar o uso da diretiva, mas imaginem códigos escritos dessa forma:

Nesse simples exemplo, fazemos uso de várias classes/métodos [Console, StringBuilder, XmlDocument, ReadLine], tendo que utilizar seu “caminho” completo, para programas mais complexos isso seria realmente impraticável, o using permite que façamos referencia aos namespaces e assim podemos utilizar as classes diretamente.

Nota 1: Durante o processo de geração do IL , o compilador, quando encontra uma classe/método e não lhe identifica localmente, recorre aos namespaces indicados nas diretivas using e assim o IL é gerado sem problemas.

Nota 2: Nunca faça referencia, via using a uma classe, como por exemplo using System.Console, e no código invocar um dos métodos da classe diretamente [WriteLine(“texto”); ]. Ah, Isso foi umas das questões na prova de certificação.

A diretiva using tem uma funcionalidade interessante no C#, como já dissemos não é possível fazer referencia direta a uma classe continda no namespace, no entando é possível utilizá-la para definir um alias, de uma classe como no código abaixo:

Uma prática interessante no desenvolvimento de uma aplicação seria criarmos um conjunto de namespaces, cada um com sua especialidade, de modo que possamos aproveitá-los por diversas aplicações, aumentando consideravelmente a produtividade, uma vez que boa parte do trabalho de implementação já estaria feita.

A seguir simularemos um projeto [web, conforme sugerimos] distribuído em vários namespaces proprietários, além dos fundamentais [System e Cia.] disponibilizados pelo Framework, sendo um deles implementados em vários assemblies. Abaixo temos sua estrutura:

É claro que a implementação das classes dos namespaces em momento algum corresponde aos nomes sugeridos [webControls, webServices, dataLayer], em breve veremos cada uma dessas funcionalidades detalhadamente [ou se preferir veja artigos de nossos colunistas]. Nosso objetivo agora é deixar claro a importância e os ganhos obtidos no modelo de implementação sugerido. A seguir segue para download todos os códigos envolvidos em nosso artigo. Atenção com o arquivo de comandos em lote [para quem não conhece/lembra, são os velhos .bat], que compila todos os assemblies bem como o aplicativo do projeto proposto. namespace.zip

É isso ai pessoal. Quem imaginaria que um conceito tão “bobo” como os namespaces faria tanta diferença na implementação de nossas soluções, boas práticas de programação são sempre bem vindas, espero que essas mostradas aqui tenham sido realmente úteis. Lembramos que estou sempre aberto à críticas e sugestões para que a cada coluna possamos apresentar um conteúdo interessante e acima de tudo funcional para nossos leitores.

Até a próxima!