Organizando o Código: Vários Arquivos e Namespaces

Ao longo do curso, todo o nosso código viveu num único arquivo. Para programas de aprendizado, isso foi conveniente. Mas você já deve ter sentido, no capstone da Aula #43, que amontoar várias classes num só arquivo começa a ficar apertado. À medida que os programas crescem — e programas reais têm dezenas, centenas de classes —, manter tudo num único arquivo torna-se insustentável: encontrar uma classe específica vira uma caça, e o arquivo cresce a proporções ingerenciáveis. Programadores profissionais organizam seu código em múltiplos arquivos e o agrupam logicamente com namespaces. Esta aula, que fecha a fase da organização profissional, ensina essas duas práticas. São conceitos simples, mas que fazem uma diferença enorme na navegabilidade e na clareza de projetos maiores — e que preparam o terreno para as aplicações do mundo real, que sempre se dividem em muitos arquivos.

Uma classe por arquivo: a convenção fundamental

A prática mais básica e importante de organização é simples de enunciar: coloque cada classe em seu próprio arquivo, e dê ao arquivo o nome da classe. Uma classe Tarefa vive num arquivo Tarefa.cs; uma classe GerenciadorTarefas vive em GerenciadorTarefas.cs. O programa principal fica no Program.cs. Essa convenção traz um benefício imediato e valioso: pelo nome do arquivo, você sabe exatamente onde encontrar cada classe. Precisa mexer na Tarefa? Abra Tarefa.cs. Não há mais caça dentro de um arquivo gigante.

O melhor é que dividir o código em vários arquivos não muda nada no funcionamento do programa. O C# considera todos os arquivos .cs de um projeto como pertencentes ao mesmo programa — as classes de um arquivo enxergam as classes de outro naturalmente, sem que você precise fazer nada especial para conectá-las. Se pegássemos o capstone da aula anterior e separássemos cada classe em seu próprio arquivo (Tarefa.cs, GerenciadorTarefas.cs, ArmazenamentoTarefas.cs, e o Program.cs com o código principal), o programa funcionaria exatamente como antes — apenas ficaria muito mais organizado e navegável. A divisão em arquivos é puramente uma questão de organização para os humanos que leem e mantêm o código; para o C#, é tudo o mesmo programa.

Como criar e usar múltiplos arquivos

Na prática, criar um novo arquivo de código é simples: no seu editor (VS Code), você cria um novo arquivo com a extensão .cs dentro da pasta do projeto, e nele coloca a classe. Por exemplo, um arquivo Produto.cs conteria:

// Arquivo: Produto.cs
class Produto
{
    public string Nome { get; set; }
    public decimal Preco { get; set; }
}

E, no Program.cs, você usa a classe Produto normalmente, sem precisar "importar" o outro arquivo — o C# já sabe que ambos fazem parte do mesmo projeto:

// Arquivo: Program.cs
Produto p = new Produto { Nome = "Caderno", Preco = 12.5m };
Console.WriteLine(p.Nome);   // funciona: Program.cs enxerga a classe de Produto.cs

Simples assim. Você distribui suas classes por arquivos conforme faça sentido — tipicamente uma classe por arquivo, com o nome do arquivo igual ao da classe —, e o C# as costura num só programa. Ao adotar essa prática, mesmo desde projetos pequenos, você desenvolve o hábito de organização que será indispensável nos projetos maiores das próximas fases.

Namespaces: agrupando classes logicamente

Além de dividir em arquivos, os projetos maiores agrupam suas classes em namespaces. Um namespace (que poderíamos traduzir como "espaço de nomes") é um agrupamento lógico e nomeado de classes relacionadas. Você já vem usando namespaces sem perceber: quando escreve using System;, está dizendo "quero usar as classes do namespace System" — que é onde vivem Console, Exception e muitas outras. O using System.Collections.Generic traz a List e o Dictionary. Esses namespaces organizam as milhares de classes do .NET em grupos temáticos, para que não se atropelem e sejam fáceis de localizar.

Você pode — e, em projetos maiores, deve — criar seus próprios namespaces para agrupar suas classes. Declara-se um namespace no topo do arquivo, e as classes daquele arquivo passam a pertencer a ele:

// Arquivo: Produto.cs
namespace MinhaLoja.Modelos;   // este arquivo pertence ao namespace MinhaLoja.Modelos

class Produto
{
    public string Nome { get; set; }
    public decimal Preco { get; set; }
}

Aqui, a classe Produto passa a pertencer ao namespace MinhaLoja.Modelos. Os pontos no nome (MinhaLoja.Modelos) indicam uma organização hierárquica, como pastas dentro de pastas — você poderia ter MinhaLoja.Modelos para as classes de dados, MinhaLoja.Servicos para as de lógica, e assim por diante, agrupando classes por sua função. Para usar, em outro arquivo, uma classe de um namespace seu, você o importa com using, exatamente como faz com os namespaces do .NET:

// Arquivo: Program.cs
using MinhaLoja.Modelos;   // traz as classes do seu namespace

Produto p = new Produto();   // agora acessível

Os namespaces servem para organizar grandes quantidades de classes em grupos temáticos e para evitar conflitos de nomes — duas classes Produto em namespaces diferentes (MinhaLoja.Modelos.Produto e OutraLoja.Modelos.Produto) podem coexistir sem se atropelar, pois seus nomes completos são distintos. Para projetos pequenos, os namespaces são opcionais e podem até ser dispensados; sua importância cresce com o tamanho do projeto. Por ora, o essencial é reconhecer o que são — você os viu em todos os using do curso — e saber que existem para manter a casa em ordem quando o número de classes cresce.

A organização como cortesia e como necessidade

Encerro com uma reflexão sobre por que a organização importa, para além da mera arrumação. Um código bem organizado — cada classe em seu arquivo, arquivos agrupados por função, namespaces claros — é, antes de tudo, uma cortesia com quem vai ler e manter o código, incluindo você mesmo daqui a alguns meses. Encontrar rapidamente onde algo está, entender a estrutura de um projeto de relance, modificar uma parte sem se perder no todo: tudo isso depende de organização. E, à medida que os programas crescem, a organização deixa de ser cortesia e vira necessidade — um projeto grande e desorganizado torna-se rapidamente impossível de manter, um emaranhado onde ninguém encontra nada e cada mudança é arriscada. Os hábitos que você adota agora, mesmo em projetos pequenos — uma classe por arquivo, nomes descritivos, agrupamento lógico —, são os que tornarão administráveis os projetos grandes do seu futuro. Organizar código é uma habilidade tão importante quanto escrevê-lo, e vale cultivá-la desde cedo.

O código passou a caber em projetos de verdade. A convenção de uma classe por arquivo, com o nome do arquivo igual ao da classe, torna qualquer base de código navegável sem busca; os namespaces agrupam classes por afinidade e evitam colisões de nome entre bibliotecas diferentes.

Nada disso muda o que o programa faz, e é exatamente por isso que costuma ser negligenciado por quem começa. Organização é uma cortesia com quem lê e uma necessidade assim que o projeto cresce — inclusive com você mesmo, meses depois, tentando localizar onde mora determinada regra.

Fontes e leituras recomendadas

• Namespaces em C# — a referência oficial sobre namespaces e organização de código; a base desta aula.
• Organizando o código em C# — as convenções de organização, incluindo uma classe por arquivo.
• A diretiva using — como importar namespaces para usar suas classes.
• Namespaces com escopo de arquivo — a forma moderna e enxuta de declarar namespaces.
• Estrutura de projetos maiores — orientações sobre organizar projetos com muitas classes.

Exercícios

Exercício 1

Pegue duas das classes do capstone da Aula #43 (por exemplo, Tarefa e GerenciadorTarefas) e separe cada uma em seu próprio arquivo (Tarefa.cs e GerenciadorTarefas.cs), deixando o código principal no Program.cs. Execute o programa e confirme que ele funciona exatamente como antes. Explique por que a divisão em arquivos não alterou o funcionamento.

Exercício 2

Crie um projeto novo com três classes simples (por exemplo, Cliente, Produto, Pedido), cada uma em seu próprio arquivo, e use-as a partir do Program.cs. Confirme que o Program.cs enxerga as três sem que você precise fazer nada especial para "conectar" os arquivos.

Exercício 3

Explique, com suas palavras, a convenção "uma classe por arquivo, com o nome do arquivo igual ao da classe". Que benefício prático ela traz ao trabalhar num projeto com muitas classes?

Exercício 4

Coloque uma classe sua num namespace de sua escolha (por exemplo, namespace MeuProjeto.Modelos;) e use-a a partir do Program.cs, importando o namespace com using. Explique o que o using faz nesse caso, relacionando-o com os using System; que você usou o curso inteiro.

// Produto.cs
namespace MeuProjeto.Modelos;
class Produto { public string Nome { get; set; } }

// Program.cs
using MeuProjeto.Modelos;
Produto p = new Produto();

Exercício 5

Sem código: explique por que a organização do código (vários arquivos, namespaces) é descrita na aula como "uma cortesia que se torna necessidade". Como a falta de organização afeta um projeto pequeno versus um projeto grande?