Tipo abstrato de dados: o contrato antes do código

Uma estrutura é um contrato

Imagine que alguém te entrega uma caixa com um único slot no topo. Você só pode fazer duas coisas: colocar um papel pela abertura ou puxar de volta o último papel que colocou. Não importa se a caixa por dentro é de madeira, de plástico ou uma gaveta disfarçada. O que define essa caixa, para quem usa, são as duas operações que ela permite e a regra de que o último a entrar é o primeiro a sair. Isso é uma pilha, e a descrição que acabamos de dar é o seu tipo abstrato de dados: uma lista de operações e de regras de comportamento, sem uma palavra sobre como a caixa é fabricada.

O tipo abstrato de dados, ou TAD, é essa forma de descrever uma estrutura pelo contrato, não pela fábrica. Quando você diz uma fila, está dizendo há uma operação para entrar no fim, uma para sair da frente, e quem chega primeiro sai primeiro. Está descrevendo o comportamento observável, o que a estrutura promete a quem a usa. Como esse comportamento é conseguido por dentro é outra história, e uma que quem usa a estrutura nem precisa conhecer. Separar essas duas camadas é uma das ideias mais poderosas da programação, porque deixa você raciocinar sobre a estrutura no nível certo, sem afogar em detalhes.

A mesma interface, implementações diferentes

A grande vantagem de pensar por contrato é que a mesma interface pode ser construída de vários jeitos por dentro, e quem usa nem percebe a diferença. Uma pilha pode ser implementada guardando os itens numa lista comum, empilhando no fim dela, ou pode ser feita com uma corrente de nós ligados, onde cada elemento aponta para o anterior. As duas cumprem o mesmo contrato: empilhar, desempilhar e ver o topo, com a regra do último a entrar, primeiro a sair. Para o código que usa a pilha, tanto faz qual mecanismo está por baixo. Isso significa que você pode trocar a implementação por uma mais rápida sem mexer em nenhuma linha de quem usa a estrutura, desde que o contrato continue igual.

// O MESMO contrato de pilha, usado sem saber o interior:
pilha <- nova_pilha()      // pode ser lista ou nós ligados por dentro
empilhar(pilha, "a")
empilhar(pilha, "b")
escreva(ver_topo(pilha))    // "b" (o último que entrou)
x <- desempilhar(pilha)     // tira "b"
escreva(ver_topo(pilha))    // "a"
// quem escreveu estas linhas NAO precisa saber como a pilha guarda os dados

O código usa a pilha só pela interface (empilhar, desempilhar, ver topo). A implementação interna fica escondida e pode mudar.

Por que separar o que do como

Essa separação não é preciosismo acadêmico, é o que torna programas grandes administráveis. Quando você usa uma estrutura só pelo contrato, cada parte do programa vira uma peça independente. Você pode entender, testar e trocar o interior de uma peça sem quebrar as outras, porque as outras só dependem da interface, nunca dos detalhes. É a mesma lógica de um carro: o motorista dirige pelo volante e pelos pedais (a interface) sem precisar saber como o motor funciona (a implementação), e a oficina pode consertar o motor sem mudar o jeito de dirigir. No curso inteiro, sempre que uma estrutura aparecer, vale separar essas duas perguntas: o que ela promete, e como ela cumpre a promessa.