Orientação a objetos: Abstração

O que é abstração

De forma geral, abstrair significa esconder os detalhes de algo, no caso, os detalhes desnecessários. Assim, você foca no que a coisa faz e deixa de lado como ela faz.

No mundo real, utilizamos abstrações o tempo todo. Na prática, tudo o que usamos sem saber como funciona por baixo dos panos pode ser considerado uma abstração.

Para exemplificar, pense na concessionária que realiza a manutenção do seu carro. Você leva o carro até lá com um problema e, depois de alguns dias, ele volta funcionando.

Em suma, pouco importam os detalhes do que aconteceu durante a manutenção. O que importa é que o carro voltou funcionando e que você continua dirigindo da mesma forma.

O mesmo vale para o volante, os pedais e o câmbio. Eles formam uma interface simples que esconde todo o mecanismo do motor, da injeção eletrônica e da transmissão.

Abstração na orientação a objetos

Dentro da OOP (Object Oriented Programming, ou Programação Orientada a Objetos), a abstração aparece de várias formas. Por exemplo, ela surge nas interfaces e nas classes que escondem seus detalhes internos.

A documentação oficial do C# define a abstração como a modelagem dos atributos e interações relevantes de uma entidade em classes. Ou seja, a classe vira uma representação abstrata de um conceito do sistema.

Além disso, a mesma documentação destaca um benefício direto. Quando uma classe abstrai bem um conceito, você consegue modificar a implementação dela sem afetar o código que a utiliza.

Por isso, a abstração na orientação a objetos caminha lado a lado com o encapsulamento. Enquanto o encapsulamento agrupa e protege o estado, a abstração decide o que merece ficar visível para o mundo externo.

Se você ainda não conhece os quatro pilares, vale começar pelo artigo de introdução à orientação a objetos. Em seguida, volte aqui para aprofundar este pilar específico.

Abstração na orientação a objetos com modificadores de acesso

A forma mais simples de aplicar a abstração na orientação a objetos é controlar a visibilidade dos membros. Para começar, vamos tomar como base uma classe que representa um pedido.

public class Order
{
    public List<Item> Items { get; } = [];
    public decimal Total { get; set; }

    public void CalculateTotal()
    {
        Total = Items.Sum(x => x.Price * x.Quantity);
    }

    public void AddItem(Item item)
    {
        Items.Add(item);
        CalculateTotal();
    }
}

public record Item(string Name, decimal Price, int Quantity);

Neste exemplo, a classe Order representa um pedido e possui uma propriedade chamada Total, que define o valor total. Além disso, ela tem dois métodos, CalculateTotal e AddItem.

Listas: para saber mais sobre listas, confira a aula "Listas" do curso Fundamentos da Orientação a Objetos.

public class Order
{
    public List<Item> Items { get; } = [];
    public decimal Total { get; private set; }

    // Detalhe interno: ninguém de fora precisa chamar este método
    private void CalculateTotal()
    {
        Total = Items.Sum(x => x.Price * x.Quantity);
    }

    public void AddItem(Item item)
    {
        Items.Add(item);
        CalculateTotal();
    }
}

Abstração na orientação a objetos por interfaces

As interfaces funcionam como contratos que definem o que as implementações, ou seja, as classes, devem conter. Esse tema aparece no Módulo 1, Aula 17, do curso Fundamentos da Orientação a Objetos.

Em suma, as interfaces dizem "o que" e não "como". Sendo assim, podemos tratar o "como" como os detalhes e o "o que" como a abstração na orientação a objetos.

public interface ICustomerRepository
{
    void Save(Customer customer);
}

Tomando como base a interface acima, temos um contrato que diz que um Customer pode ser salvo. No entanto, ela não diz como isso deve ser feito.

Esse conceito nos leva ao princípio DIP, o Dependency Inversion Principle, que faz parte do SOLID e prega o seguinte:

Sempre que puder, dependa de abstrações em vez de implementações.

As diretrizes de design de frameworks da Microsoft reforçam a mesma ideia. Segundo elas, abstrações estão no centro de padrões como plug-ins e inversão de controle, além de serem essenciais para a testabilidade.

public class CustomerRepository : ICustomerRepository
{
    private readonly AppDbContext _context;

    public CustomerRepository(AppDbContext context)
    {
        _context = context;
    }

    public void Save(Customer customer)
    {
        // Implementação real, que grava no banco de dados
        _context.Customers.Add(customer);
        _context.SaveChanges();
    }
}

public class FakeCustomerRepository : ICustomerRepository
{
    public void Save(Customer customer)
    {
        // Não faz nada: apenas simula a gravação
    }
}

Interfaces ou classes abstratas

As interfaces não são a única forma de criar contratos no C#. As classes abstratas, marcadas com abstract, também definem membros que as classes derivadas precisam implementar.

Segundo a documentação de interfaces do C#, use uma classe abstrata quando os tipos relacionados compartilham estado, construtores ou membros não públicos. Por outro lado, prefira uma interface quando o contrato atravessa hierarquias diferentes.

Além disso, existe uma restrição importante. No C#, uma classe herda de apenas uma classe base, mas pode implementar várias interfaces ao mesmo tempo.

Por isso, no caso do repositório, a interface é a escolha mais flexível. Afinal, o repositório real e o falso não compartilham nenhum estado, apenas o contrato.

Nas duas opções, porém, o objetivo é o mesmo. Tanto a interface quanto a classe abstrata são ferramentas da abstração na orientação a objetos, porque ambas separam o contrato dos detalhes.

Aplicando a abstração na orientação a objetos na prática

Agora vamos para um cenário maior, com o objeto OrderHandler, que manipula os pedidos. Esse objeto precisa se comunicar com a base de clientes para salvar dados.

Aqui, a abstração na orientação a objetos mostra todo o seu valor, porque durante os testes não teremos uma base de dados disponível.

Desta forma, os testes falhariam, ou teríamos que preparar sempre uma massa de testes, o que muitas vezes toma tempo.

A saída aqui é usar um mock, ou seja, simular que fomos ao banco de dados e algo aconteceu. Então, teremos as versões CustomerRepository e FakeCustomerRepository sendo utilizadas em momentos diferentes.

Testes de unidade: veja mais sobre mocks e muitos testes de unidade no curso Refatorando para Testes de Unidade.

public class OrderHandler
{
    private readonly ICustomerRepository _repository;

    // O handler recebe o contrato, e não uma implementação específica
    public OrderHandler(ICustomerRepository repository)
    {
        _repository = repository;
    }

    public void Handle(Customer customer)
    {
        _repository.Save(customer);
    }
}

[TestClass]
public class OrderHandlerTests
{
    [TestMethod]
    public void ShouldHandleOrderWithoutDatabase()
    {
        // Usa a implementação falsa no lugar do banco real
        var repository = new FakeCustomerRepository();
        var handler = new OrderHandler(repository);

        handler.Handle(new Customer());
    }
}

[HttpPost]
public IActionResult Post([FromServices] ICustomerRepository repository, Customer customer)
{
    // O controller também depende apenas do contrato
    repository.Save(customer);
    return Ok();
}

// Program.cs: associa o contrato à implementação real
builder.Services.AddTransient<ICustomerRepository, CustomerRepository>();

Benefícios da abstração na orientação a objetos

Depois dos exemplos, fica mais fácil enxergar os ganhos concretos. O primeiro deles é a redução do impacto das mudanças, já que os detalhes ficam escondidos atrás de uma superfície pública pequena.

O segundo benefício é a testabilidade. Como vimos, a abstração na orientação a objetos permite trocar o repositório real por um falso sem alterar uma linha do OrderHandler.

Além disso, a abstração facilita a substituição de tecnologias. Se amanhã o projeto trocar o Entity Framework pelo Dapper, basta criar uma nova implementação de ICustomerRepository e mudar o registro no container.

Outro ganho está na leitura do código. Quem abre o OrderHandler entende rapidamente o que ele faz, porque não precisa navegar pelos detalhes de acesso a dados.

Por fim, a abstração ajuda o trabalho em equipe. Enquanto uma pessoa implementa o repositório, outra pode escrever o handler e os testes usando apenas o contrato combinado.

Cuidados com a abstração na orientação a objetos

Apesar dos benefícios, a abstração na orientação a objetos também exige equilíbrio. As diretrizes de design de frameworks da Microsoft alertam que criar uma boa abstração é difícil.

Segundo elas, o principal desafio está em acertar o conjunto de membros, nem mais nem menos. Uma abstração com membros demais fica difícil de implementar, enquanto uma com membros de menos se torna inútil em muitos cenários.

Além disso, abstrações em excesso também prejudicam a usabilidade. Nomes genéricos e camadas sem propósito deixam o código difícil de entender sem conhecer o quadro completo.

Por isso, aplique a abstração na orientação a objetos com propósito e crie interfaces quando houver um motivo concreto, como permitir testes ou trocar implementações. Caso contrário, uma classe bem encapsulada costuma resolver o problema com menos complexidade.

Conclusão

A abstração na orientação a objetos parece um assunto simples e básico, mas gera boas reflexões. Afinal, decidir o que esconder e o que expor afeta diretamente o custo de manutenção do sistema.

Neste artigo, vimos a abstração em duas formas. Primeiro, com modificadores de acesso que reduzem a superfície pública de uma classe; depois, com interfaces que separam o contrato da implementação.

Na prática, essas duas formas de abstração na orientação a objetos se combinam com a injeção de dependência e os testes de unidade. Com isso, o código fica mais fácil de testar, de evoluir e de entender.

Por fim, vale revisitar esses conteúdos de tempos em tempos. Assim, você confirma que domina a abstração na orientação a objetos ou descobre o que ainda precisa aprender.

FAQ

O que é abstração na programação?

É a prática de esconder os detalhes de implementação e expor apenas o essencial. Dessa forma, quem consome o código depende do que ele faz, e não de como ele faz.

Qual a diferença entre abstração e encapsulamento?

O encapsulamento agrupa dados e comportamentos e controla o acesso a eles. A abstração decide quais desses membros devem ficar visíveis para o mundo externo.

Interface é uma abstração?

Sim. A interface define um contrato com o que deve ser feito, sem dizer como, e permite várias implementações para o mesmo contrato.

Quando usar classe abstrata em vez de interface?

Use classe abstrata quando os tipos compartilham estado, construtores ou membros não públicos. Prefira interface quando o contrato precisa atravessar hierarquias diferentes.

Por que a abstração facilita os testes de unidade?

Porque você pode substituir a implementação real por uma versão falsa. Assim, o teste roda sem banco de dados, rede ou outros recursos externos.