Interface e implementação: usar sem saber o como

O painel e o motor

Volte ao começo do curso, ao tipo abstrato de dados. Você viu que uma pilha é um contrato: empilhar, desempilhar, ver o topo. Quem usa a pilha não precisa saber se, por dentro, ela é uma lista ou um vetor. Esse é o coração da abstração, e vale para qualquer módulo. A interface é a face pública: as funções que você pode chamar e a promessa do que cada uma faz. A implementação é o maquinário por trás, escondido. A analogia do carro é exata: o volante e os pedais são a interface, iguais em quase todo carro; o motor é a implementação, que varia de modelo para modelo sem que você precise reaprender a dirigir.

Esconder a implementação não é frescura de organização. É o que dá liberdade para o autor do módulo. Se ninguém de fora depende dos detalhes internos, o autor pode trocá-los à vontade: deixar o cálculo mais rápido, corrigir um erro, mudar a estrutura de dados. Nada disso quebra quem usa, porque a interface, o contrato visível, continuou a mesma. Quando a implementação vaza (quando quem usa começa a depender de um detalhe interno), essa liberdade some, e qualquer mudança lá dentro passa a arriscar o programa inteiro.

Trocar o motor sem trocar o volante

O teste de fogo de uma boa separação é este: consigo trocar a implementação sem que ninguém de fora perceba? Imagine um módulo que guarda favoritos. A interface oferece adicionar, remover e verificar se algo é favorito. Na primeira versão, por dentro ele usa uma lista simples, e verificar percorre a lista inteira. Um dia, com muitos favoritos, isso fica lento. Você troca a lista por uma tabela hash, que verifica quase na hora. As funções adicionar, remover e verificar continuam com o mesmo nome e o mesmo comportamento visível. Todo o resto do programa nem fica sabendo da troca. Isso só foi possível porque ninguém dependia de a estrutura ser uma lista.

// Interface do módulo de favoritos (o que o resto do programa usa):
//   adicionar(id)      -> guarda um favorito
//   remover(id)        -> tira um favorito
//   ehFavorito(id)     -> devolve verdadeiro ou falso

// Implementação 1: por dentro, uma lista (verificar é lento com muitos itens)
funcao ehFavorito(id)
  para cada item em lista faça
    se item = id então retorne verdadeiro
  fim
  retorne falso
fim

// Implementação 2: por dentro, uma tabela hash (verificar é quase instantâneo)
funcao ehFavorito(id)
  retorne tabela.contem(id)
fim

// A interface (os nomes e o que fazem) NÃO mudou: quem usa não precisa saber.

Duas implementações diferentes de ehFavorito, com a mesma interface. Trocar por dentro não afeta quem chama a função.

Quando a implementação vaza

O perigo silencioso é a implementação vazar. Isso acontece quando quem usa o módulo começa a depender de um detalhe que deveria estar escondido. Por exemplo, um módulo devolve os favoritos numa lista, e outra parte do programa passa a contar com a ordem exata dessa lista, ou a mexer diretamente na estrutura interna em vez de chamar as funções da interface. No dia em que o autor troca a lista por uma tabela hash, essa outra parte quebra, mesmo sem ninguém ter tocado nela de propósito. A disciplina é usar sempre a interface e nunca fuçar as tripas. Se a interface não oferece algo de que você precisa, o certo é ampliar a interface com cuidado, não furar a parede.