Encapsulamento: Vendo Além da Superfície 🔍

O encapsulamento não elimina a complexidade; ele apenas a organiza em pedaços gerenciáveis.

Um dos pilares fundamentais da OOP se chama encapsulamento. Mas alguns desenvolvedores ainda não entendem o objetivo e o verdadeiro poder do encapsulamento. Espero que esse post possa ajudar a esclarecer melhor esse pilar tão importante! Se gostar do conteúdo, por favor, compartilhe e deixe seu like no post!😄

A Origem da Palavra ⛩️

O termo "encapsulamento" deriva do verbo "encapsular", que significa envolver ou conter algo em uma cápsula. A palavra tem suas raízes no Latim “capsula”, que é uma forma diminutiva de “caput”, que significa "cabeça". Assim, na essência, encapsulamento tem a ver com proteção, a ideia de conter algo para manter sua integridade.

Desmistificando o Encapsulamento 🤔

Certamente, você já ouviu: “Encapsulamento é sobre ocultar informações de uma classe”. Muitos programadores, especialmente os iniciantes, pensam que basta tornar os membros de uma classe privados e ocultá-los das classes clientes para estarem aplicando o encapsulamento. No entanto, é essencial compreender que o encapsulamento vai além da simples ocultação de informações.

Uma outra perspectiva define o encapsulamento como a junção de dados e comportamentos. Apesar de não estar errada, esta definição também não capta a essência completa do conceito. É uma abordagem para alcançar um bom encapsulamento, mas não define o pilar em sua totalidade.

Ocultação de Informação e a Junção de Dados e Comportamentos são ferramentas que fazem parte do verdadeiro encapsulamento, mas quando aplicadas isoladamente não o definem por completo.

Por que é tão importante falar sobre encapsulamento? 🧐

Tudo se resume a complexidade. Quanto mais código temos em um software, mais complexo ele acaba se tornando. E a complexidade do código é um dos maiores desafios que enfretamos no desenvolvimento de software corporativo. Quanto mais complexa a base de código se torna, mais difícil é trabalhar com ela. Os resultados? A velocidade no desenvolvimento de novas features diminui. O número de inconsistencias e bugs aumentam muito causando até mesmo problemas financeiros para as empresas. E por último, mas não menos importante, a capacidade de responder as necessidades específicas de negócio acaba sendo prejudicada!

Sem o encapsulamento não temos nenhuma maneira prática e efetiva de lidar com a complexidade do código. É verdade que nunca podemos parar ou regredir a entropia de uma base de código. Mas podemos manter sobre controle e não ser controlados por ela! Além disso, sem o encapsulamento os componentes do software ficam desorganizados, as classes não possuem coesão e isso leva a uma carga mental maior do programador para responder rápido a mudanças e a entender fluxos complexos sem alterar o comportamento que o sistema já possui.

O encapsulamento não elimina a complexidade; ele apenas a organiza em pedaços gerenciáveis.

O encapsulamento nos fornece uma alternativa saúdavel para o código, para os bolsos das empresas e para nossa própria mente, como? Mantendo a organização e coesão dos componentes. Mas como já falamos, precisamos entender realmente a essência desse pilar tão importante! Vamos agora falar sobre o coração desse princípio.

O Coração do Encapsulamento ❤️

Então como podemos definir? Veja a definição mais apropriada abaixo:

Encapsulamento é o ato de proteger a integridade dos dados.

Isso geralmente é feito impedindo que os clientes de uma classe configurem ou alterem os dados internos para um estado inválido ou inconsistente. Vamos entender melhor isso. 😄

Quando falamos em "proteger a integridade dos dados", estamos nos referindo à ideia de que os dados de um objeto devem estar seguros de modificações indesejadas ou inadvertidas. Imagine os dados como um tesouro dentro de uma caixa forte. O encapsulamento é essa caixa, permitindo que apenas as pessoas certas, com a chave correta (ou métodos corretos), acessem ou alterem esse tesouro.

Agora para explicar um pouco mais, quando nos referimos a "clientes de uma classe", estamos falando sobre outras partes do código (componentes, artefatos ou classes) ou programas que desejam usar ou interagir com essa classe. A ideia é que nem todas as partes do código devem ser capazes de modificar diretamente os dados internos da classe. Em vez disso, elas devem usar métodos específicos que a classe fornece. Por exemplo, em vez de permitir que qualquer um defina o valor de uma variável diretamente, você teria um método para definir esse valor. Esse método pode então verificar se o novo valor é válido antes de aceitá-lo. Então, encapsulamento é basicamente uma prática que garante que os dados de uma classe são acessados e modificados de uma maneira controlada e segura. Isso ajuda a prevenir erros e mantém a integridade dos dados, assegurando que eles permaneçam consistentes e em um estado válido.

E onde entram as duas ferramentas citadas anteriormente?

É interessante ilustrar para deixar claro. A ocultação de informação pode ser visualizada como as paredes e portas de uma casa. Ao entrar em uma casa, vemos apenas os cômodos e móveis disponíveis para nós. Não vemos as tubulações internas, a fiação elétrica ou a estrutura de concreto e aço que dá suporte à edificação. E, na verdade, não precisamos ver ou interagir com esses elementos para habitar a casa. Essa é a essência da ocultação. Não se trata apenas de esconder, mas de proporcionar uma experiência focada, apresentando apenas o necessário para realizar uma tarefa específica. Em termos de programação, isso evita que detalhes complexos e específicos de uma classe sejam desnecessariamente expostos, reduzindo a probabilidade de erros e tornando o software mais fácil de usar e compreender.

Por outro lado, a Junção de Dados e Comportamentos pode ser comparada ao funcionamento de um relógio mecânico. Cada engrenagem, por si só, tem uma função, mas é a sua operação conjunta, a interação entre essas peças, que permite ao relógio marcar o tempo com precisão. Na OOP, a junção assegura que os dados e as operações sobre eles estejam interligados, permitindo que a classe opere como uma unidade coesa. Isso garante que os dados sejam sempre tratados de maneira adequada, pois a lógica e a informação estão intrinsecamente conectadas. Essa abordagem fortalece o encapsulamento, assegurando que os dados sejam protegidos e acessados apenas por métodos apropriados, o que por sua vez mantém a integridade e a consistência do sistema.

Com o encapsulamento asseguramos que os dados permaneçam consistentes e não corrompidos.

Essas duas ferramentas são essenciais para alcançar o objetivo principal de proteger a integridade dos dados! E isso nos leva a outro assunto bem bacana, invariantes! Não se preocupe, não tem nada de complexo nisso, vamos entender melhor!

Encapsulamento e Invariantes: Garantindo a Estabilidade de Seu Software 🫱🏼‍🫲🏼

Para explorar a relação entre encapsulamento e invariantes, primeiro precisamos entender o que significa "invariante" no contexto da programação. Em essência, uma invariante é uma condição ou propriedade que sempre se mantém verdadeira em um sistema, não importando as operações ou transformações que o sistema sofra. É um aspecto do sistema que não varia, daí o nome. Agora, por que os invariantes são essenciais em programação, especialmente em programação orientada a objetos?

Pense em um objeto como um "contrato". Quando um objeto é criado, ele promete se comportar de certa maneira e seguir determinadas regras. Estas regras são, em muitos casos, invariantes. Eles garantem que, independentemente das interações com o objeto, certas condições sempre serão mantidas. Aqui é onde o encapsulamento entra em cena.

O encapsulamento é uma ferramenta poderosa para garantir que os invariantes de um objeto sejam mantidos. Ao limitar o acesso direto aos dados de um objeto e fornecer apenas interfaces específicas (métodos) para interagir com esses dados, estamos essencialmente protegendo o "contrato" desse objeto. Asseguramos que as operações que podem violar os invariantes não sejam realizadas inadvertidamente.

Por exemplo, pense em uma classe que representa uma data. Um dos invariantes dessa classe pode ser que o dia do mês sempre deve estar entre 1 e 31. Se permitirmos o acesso direto à variável que armazena o dia do mês, corremos o risco de algum código externo definir essa variável para, digamos, 50, quebrando o invariante. No entanto, ao encapsular essa variável e fornecer um método para definir o dia, podemos verificar se o valor fornecido está dentro do intervalo aceitável e, assim, manter nosso invariante seguro.

Em termos práticos, pensar no encapsulamento em termos de invariantes é como projetar uma fortaleza ao redor das regras essenciais do seu software. Não é apenas sobre esconder detalhes, mas sobre proteger as fundações do comportamento do sistema.

Para entender claramente o encapsulamento trabalha em conjunto com invariantes, vamos considerar um objeto simples, mas ilustrativo: o quadrado. Este objeto geométrico tem características bem definidas que podemos modelar em um software.

Invariantes:

• Todos os lados do quadrado têm o mesmo comprimento.

• Os ângulos entre os lados são sempre de 90 graus.

• A área do quadrado é sempre o comprimento do lado elevado ao quadrado.

public class Quadrado
{
    private double _lado;

    public Quadrado(double lado)
    {
        DefineLado(lado);
    }

    public void DefineLado(double valor)
    {
        if (valor <= 0)
            throw new ArgumentException("O valor do lado deve ser positivo!");

        _lado = valor;
    }

    public double Area()
    {
        return _lado * _lado;
    }
}

Agora, vejamos como o encapsulamento ajuda a manter nossos invariantes:

1. Lados de Mesmo Comprimento: Utilizamos um campo privado _lado para armazenar o comprimento do lado do quadrado. Esse campo é acessado somente através do método DefineLado, que garante que o valor inserido é válido. Assim, todos os lados do quadrado têm sempre o mesmo comprimento.

2. Ângulos de 90 Graus: Essa invariante é intrínseco à definição de um quadrado. Garantimos isso ao não permitir que lados diferentes sejam definidos separadamente.

3. Área: O método Area retorna o cálculo da área de um quadrado baseado na fórmula matemática padrão. Como utilizamos o valor encapsulado de _lado e garantimos a integridade desse valor através do método DefineLado, a área retornada estará sempre correta.

Neste exemplo, o encapsulamento serve como uma ferramenta para manter os invariantes do quadrado. Ao limitar a maneira como os dados internos do objeto são acessados e modificados, garantimos que nosso objeto Quadrado sempre se comporte como um quadrado real no mundo matemático. Isso simplifica o uso da classe e garante confiabilidade e precisão nas operações realizadas sobre ela.

Podemos melhorar ainda mais esse objeto e incluir um método para obter o valor do lado (um "getter") se ele for necessário para algum uso externo, por exemplo:

public double ObtemLado()
{
    return _lado;
}

Isto daria à classe a flexibilidade de permitir que o valor do lado fosse lido, mas ainda protegeria a integridade do dado ao não permitir que fosse alterado diretamente sem a validação.

Benefício das Invariantes e Modularidade no Dia a Dia do Programador

No vasto mundo da programação, cada detalhe importa. E é nesse mundo intrincado que as invariantes brilham como um farol, garantindo a nós, desenvolvedores e desenvolvedoras, a segurança de que nossos objetos se comportarão conforme o esperado. Mas como, exatamente, essa característica se reflete na prática? Como ela molda a forma como programamos e estruturamos nossos sistemas?

O Problema: Complexidade Crescente

À medida que os softwares crescem e se tornam mais complexos, torna-se cada vez mais difícil rastrear todos os detalhes. Nesse cenário, classes e objetos se tornam pontos críticos, pois cada um deles pode conter diversas operações e comportamentos.

Imagine, por exemplo, um sistema de e-commerce. Nele, teremos várias classes: Produto, CarrinhoDeCompras, Usuario, Pedido, entre outras. Se você estiver desenvolvendo uma funcionalidade que envolve o CarrinhoDeCompras, você realmente quer entender todos os detalhes de como o Produto ou o Usuario são implementados? Provavelmente não. Você quer confiar que eles funcionarão conforme o esperado.

O Valor das Invariantes

É aí que as invariantes entram em cena. Elas são como contratos silenciosos que cada objeto faz, garantindo que, independentemente do que aconteça, certas condições serão sempre verdadeiras.

Vamos pensar no objeto Pedido do nosso sistema de e-commerce. Uma das invariantes pode ser que um pedido sempre precisa ter pelo menos um produto. Outra invariante pode ser que um pedido, uma vez pago, não pode ter seu valor total alterado.

Exemplo Prático em C#

Imagine que tenhamos a seguinte classe:

public class Pedido
{
    private List<Produto> _produtos = new List<Produto>();
    private bool _foiPago = false;

    public Pedido(List<Produto> produtos)
    {
        if (!produtos.Any())
            throw new ArgumentException("Pedido precisa ter ao menos um produto.");

        _produtos = produtos;
    }

    public decimal CalcularTotal()
    {
        return _produtos.Sum(p => p.Preco);
    }

    public void FinalizarPedido()
    {
        _foiPago = true;
    }

    public void AdicionarProduto(Produto produto)
    {
        if (_foiPago)
            throw new InvalidOperationException("Não é possível adicionar produtos a um pedido já pago.");

        _produtos.Add(produto);
    }
}

Nesta classe, temos duas invariantes claras:

1. Um pedido sempre terá ao menos um produto.

2. Produtos não podem ser adicionados após o pedido ser finalizado.

E isso nos traz benefícios:

• Campos Privados: Os campos _produtos e _foiPago são privados. Isso garante que o acesso direto a esses campos está restrito à classe, protegendo sua integridade.

• Validações: O construtor da classe verifica se a lista de produtos não está vazia antes de aceitar o pedido. Isso garante que um pedido sempre tenha ao menos um produto.

• Métodos que Controlam o Estado: O método AdicionarProduto verifica se o pedido já foi pago antes de permitir a adição de novos produtos. Isso é um bom exemplo de encapsulamento, onde o objeto controla seu próprio estado e garante que suas regras internas sejam seguidas.

Para um desenvolvedor trabalhando em outro módulo do software, essa previsibilidade é um alívio. Ele pode usar a classe Pedido com confiança, sem se preocupar que seu código acidentalmente crie um pedido sem produtos ou adicione produtos a um pedido já finalizado.

A Conexão com a Modularidade

As invariantes garantem a modularidade. Elas permitem que tratemos cada classe ou objeto como uma unidade independente - uma caixa-preta. Isso é crucial para o desenvolvimento de software em larga escala.

Por exemplo, se um colega de equipe estiver trabalhando em uma funcionalidade que envolve o processamento de pagamentos, ele não precisa se aprofundar em todos os detalhes da classe Pedido. Ele só precisa conhecer suas invariantes e os métodos públicos disponíveis.

Impacto no Dia a Dia

O valor disso no dia a dia é imenso. Quando você pega um pedaço de código escrito por alguém há meses (ou até anos), é reconfortante saber que existem regras claras que esse código segue e que a lógica está protegida pelo encapsulamento. Você não precisa vasculhar cada linha para entender todas as nuances. As invariantes lhe dão uma visão clara do que esperar.

Além disso, quando se trata de testar seu código, as invariantes oferecem um guia claro. Você sabe exatamente quais condições devem sempre ser verdadeiras, e pode escrever testes para garantir que elas permaneçam assim.

O Perigo Subestimado das Invariantes Mal Definidas ⚠️

Mas o que acontece quando essas invariantes não são bem definidas ou especificadas? Quais são as consequências reais e profundas dessa negligência?

O Desalinhamento Perigoso

O alinhamento entre a equipe técnica e a equipe de negócios é mais do que apenas uma boa prática - é a espinha dorsal do desenvolvimento de software eficaz. Quando há um desalinhamento, não estamos apenas falando de pequenos bugs ou falhas, mas de falhas sistêmicas que podem prejudicar a integridade dos dados, a experiência do usuário e, em última análise, a viabilidade comercial do software.

Mas como isso acontece? E por que é tão comum?

As equipes de negócios, muitas vezes, focam nos objetivos e metas macro do produto, enquanto os desenvolvedores se preocupam com os detalhes granulares e técnicos. O espaço entre essas duas perspectivas é onde as invariantes mal definidas nascem.

Impacto Profundo de Invariantes Inadequadas

Uma invariante mal definida não é apenas um erro técnico - é uma falha na comunicação. E essa falha pode ter várias ramificações:

1. Limitação da Evolução do Sistema: Um sistema que não pode se adaptar facilmente a novos requisitos devido a invariantes rígidas ou mal definidas se torna um fardo.

2. Introdução de Bugs Complexos: Uma invariante imprecisa pode fazer com que erros passem despercebidos durante os testes e apareçam em ambientes de produção.

3. Aumento do Custo de Manutenção: Corrigir uma invariante mal definida após a implementação é muito mais caro do que acertá-la desde o início.

4. Degradação da Confiança: As falhas causadas por invariantes inadequadas podem corroer a confiança dos usuários e stakeholders no software.

Evolução e Adaptação de Invariantes

Em qualquer campo da ciência da computação, seja ele voltado para o desenvolvimento de software, engenharia de sistemas, ou até mesmo pesquisa, um princípio mantém sua relevância: a evolução. O mundo dos negócios é dinâmico e, com ele, as necessidades e demandas que moldam o software também mudam. Invariantes, que servem como pilares de estabilidade e previsibilidade em nossos sistemas, não estão imunes a essa dinâmica. A habilidade de adaptar e evoluir invariantes de maneira eficaz e segura é fundamental para manter a integridade e relevância de um sistema.

Imagine um cenário em que estamos desenvolvendo um software para uma livraria. Um invariante definido poderia ser que "Um livro deve sempre ter um autor associado". Esta regra parece sensata e serve ao propósito inicial do sistema. No entanto, com a expansão dos negócios, a livraria decide começar a vender revistas e periódicos. Estes itens, muitas vezes, não têm um único autor associado. A invariante, que anteriormente fazia todo o sentido, agora representa uma limitação.

O Impacto de Mudar Invariantes

Mudar um invariante não é uma tarefa trivial. Alterá-los afeta diretamente o comportamento e as expectativas do sistema. Esta não é uma atividade que deve ser feita apressadamente, pois as implicações podem ser vastas.

Tomando nosso exemplo da livraria, se decidíssemos simplesmente remover o invariante que exige um autor para cada livro, estaríamos introduzindo uma ampla gama de potenciais problemas. Poderíamos ter livros sem autores, o que confundiria os clientes e tornaria o processo de catalogação menos claro. Além disso, funções que antes presumiam a existência de um autor para cada livro agora podem falhar ou retornar resultados inesperados.

A Segurança dos Testes Unitários

Aqui entra o papel crítico dos testes unitários. Quando os invariantes são alterados, os testes unitários atuam como a primeira linha de defesa, identificando áreas do código que agora violam os novos invariantes.

Vamos considerar que temos testes que verificam a associação de um autor a cada livro. Quando tentamos introduzir revistas sem um autor específico, esses testes falharão, indicando exatamente onde o código precisa ser adaptado para se adequar ao novo invariante.

A Coesão entre Desenvolvimento e Negócios

Uma armadilha comum ao evoluir invariantes é desconsiderar a perspectiva dos negócios. Enquanto os desenvolvedores estão focados em garantir a integridade técnica, a equipe de negócios está mais preocupada com a usabilidade, relevância e valor entregue pelo software.

É crucial que haja uma comunicação clara e regular entre as equipes de desenvolvimento e negócios. Uma mudança proposta no invariante "Um livro deve sempre ter um autor associado" poderia ser discutida com a equipe de negócios. Talvez a solução não seja remover o invariante, mas adaptá-lo para "Um item à venda deve ter pelo menos uma entidade de crédito associada", onde "entidade de crédito" pode ser um autor, editora ou organização.

Mas como o encapsulamento se encaixa nisso? Vamos entender.

Um Guardião para os Invariantes

No cenário da livraria que abordamos anteriormente, a invariante de que "Um livro deve sempre ter um autor associado" é crucial para o funcionamento adequado do sistema. Se esta regra for quebrada inadvertidamente, o sistema pode enfrentar erros e inconsistências. Aqui, o encapsulamento se mostra valioso ao assegurar que o estado interno do objeto - neste caso, a associação entre um livro e seu autor - só pode ser alterado por meio de operações bem definidas, que respeitam as invariantes estabelecidas.

Exemplo para visualizar em código o que acabamos de comentar 👇🏻:

public class Autor
{
    public string Nome { get; private set; }

    public Autor(string nome)
    {
        Nome = nome ?? throw new ArgumentNullException(nameof(nome));
    }
}

public class Livro
{
    private Autor _autor;

    public string Titulo { get; private set; }

    public Autor Autor 
    { 
        get 
        {
            return _autor; 
        }
    }

    public Livro(string titulo, Autor autor)
    {
        Titulo = titulo ?? throw new ArgumentNullException(nameof(titulo));
        _autor = autor ?? throw new ArgumentNullException(nameof(autor));
    }
}

Flexibilidade na Adaptação

O encapsulamento também proporciona uma maneira flexível de adaptar o sistema às mudanças. Se, por exemplo, a livraria decidir vender livros que não necessariamente possuem um único autor, a classe poderia facilmente ser adaptada para suportar essa nova demanda, sem expor os detalhes dessa mudança para o restante do sistema. Podemos ver isso abaixo:

public class Livro
{
    private List<Autor> _autores;

    public string Titulo { get; private set; }

    // Para manter a compatibilidade com o código existente:
    public Autor Autor 
    { 
        get 
        {
            return _autores.FirstOrDefault(); 
        }
    }

    public IReadOnlyList<Autor> Autores => _autores.AsReadOnly();

    public Livro(string titulo, Autor autor)
    {
        Titulo = titulo ?? throw new ArgumentNullException(nameof(titulo));
        _autores = new List<Autor> { autor ?? throw new ArgumentNullException(nameof(autor)) };
    }

    public Livro(string titulo, List<Autor> autores)
    {
        Titulo = titulo ?? throw new ArgumentNullException(nameof(titulo));
        _autores = autores ?? throw new ArgumentNullException(nameof(autores));
    }

    public void AdicionarAutor(Autor autor)
    {
        _autores.Add(autor ?? throw new ArgumentNullException(nameof(autor)));
    }
}

A classe Livro apresentada é uma ilustração elegante de encapsulamento em ação, equilibrando a necessidade de adaptabilidade com robustez. Vamos explorar suas características principais:

1. Lista Privada de Autores: A lista _autores é privada, o que significa que o acesso direto a ela é restringido e o controle sobre suas modificações é exclusivo da classe Livro. Isso protege a integridade da lista de autores.

2. Propriedades de Acesso Restrito: A propriedade Titulo é imutável após sua criação, garantindo que, uma vez atribuído, o título de um livro não pode ser alterado externamente.

3. Compatibilidade com Código Existente: A propriedade Autor foi mantida mesmo após a migração para suportar vários autores. Ela devolve o primeiro autor da lista, mantendo o código que esperava esta propriedade funcional.

4. Lista Somente Leitura para Consumidores: A propriedade Autores retorna uma versão somente leitura da lista interna. Isso evita que consumidores externos modifiquem a lista diretamente, mas ainda podem ver seu conteúdo. Esta é uma técnica para fornecer acesso aos dados sem sacrificar a integridade.

5. Construtores Defensivos: Os construtores da classe Livro garantem que nem o título nem os autores possam ser nulos. Se qualquer um deles for, uma exceção será lançada. Isso protege o objeto Livro de entrar em um estado inválido.

6. Método de Adição de Autores: Em vez de permitir a modificação direta da lista de autores, um método AdicionarAutor é fornecido. Isso dá à classe Livro controle total sobre como e quando um autor pode ser adicionado, garantindo que regras adicionais (se existirem no futuro) possam ser facilmente implementadas.

Mas gostarai de extrair três vantagens no dia a dia para nós programadores. Vou citar rapidamente algumas:

1. Compatibilidade Retroativa: Com a manutenção da propriedade Autor, que retorna o primeiro autor da lista, a classe mantém a compatibilidade com o código existente. Isso é valioso porque significa que qualquer outra classe ou função que estava usando a classe Livro anteriormente não precisa de modificações. Em outras palavras, se outro código estava esperando acessar o autor de um livro através da propriedade Autor, ele ainda pode fazer isso sem saber que, internamente, a classe Livro agora suporta vários autores.

2. Flexibilidade para Expansão Futura: A forma como a classe foi estruturada torna-a altamente adaptável a mudanças futuras. Por exemplo, se decidirmos implementar mais regras sobre como os autores são adicionados, podemos fazer isso facilmente sem perturbar a funcionalidade existente.

3. Simplificação da Manutenção: Quando mudanças são necessárias, elas podem ser feitas na classe Livro sem afetar as partes do sistema que dependem dela. Isso isola o impacto das mudanças e simplifica a manutenção do software.

E tudo isso facilita muito a manutenibilidade!

O Pilar da Manutenibilidade

O encapsulamento não só protege os invariantes, mas também promove uma manutenibilidade mais eficaz. Como os detalhes internos estão bem guardados, as equipes de desenvolvimento podem se concentrar em otimizar, refatorar ou estender a classe sem o medo constante de quebrar as funcionalidades dependentes.

Por exemplo, se no futuro, a livraria decidir categorizar os autores por gênero literário, essa mudança poderia ser incorporada internamente sem afetar o restante do sistema. O encapsulamento garantiria que, mesmo com essa nova complexidade adicionada, a promessa original da classe - que cada livro tem pelo menos uma entidade de crédito - permaneceria inalterada.

Interface Pública

Pronto chegou o momento de falar sobre interfaces públicas de uma classe. Em programação orientada a objetos, uma interface pública refere-se ao conjunto de métodos, propriedades, eventos e outros membros que são intencionalmente expostos para serem acessados ou utilizados por outras classes ou componentes. Em outras palavras, é o "contrato" que uma classe oferece ao mundo exterior, especificando como os consumidores externos podem interagir com ela.

A interface pública é a fachada visível da sua classe; é o que os programadores veem e interagem quando usam a classe em outras partes do software. Esta interface permite aos desenvolvedores acessar e usar a funcionalidade da classe sem necessariamente ter que entender os detalhes de sua implementação interna. Isso é essencial para o conceito de encapsulamento.

Através da interface pública, os desenvolvedores podem:

1. Interagir com a classe: Criar instâncias, chamar métodos, acessar propriedades, etc.

2. Estender ou implementar a classe: Em linguagens que suportam herança ou interfaces.

3. Testar a classe: A interface pública proporciona um meio para testar a funcionalidade da classe, validando se ela está cumprindo seu contrato.

No entanto, é importante observar que nem todos os membros de uma classe fazem parte de sua interface pública. Aqueles que não são destinados ao uso externo são muitas vezes marcados como privados ou protegidos. Sobre isso vamos entender melhor com um exemplo.

Veja a baixo a classe ValidadorString:

public class ValidadorString
{
    private string _valor;

    public ValidadorString(string valor)
    {
        _valor = valor;
    }

    public bool IsValid()
    {
        return NaoEhVazioOuNulo() 
            && TemNoMinimoOitoCaracteres() 
            && ContemLetraMaiuscula() 
            && NaoContemCaracteresEspeciais();
    }

    private bool NaoEhVazioOuNulo()
    {
        return !string.IsNullOrEmpty(_valor);
    }

    private bool TemNoMinimoOitoCaracteres()
    {
        return _valor.Length >= 8;
    }

    private bool ContemLetraMaiuscula()
    {
        return _valor.Any(char.IsUpper);
    }

    private bool NaoContemCaracteresEspeciais()
    {
        return _valor.All(ch => char.IsLetterOrDigit(ch) || char.IsWhiteSpace(ch));
    }
}

As regras para validar a string estão claramente encapsuladas e não são expostas. Apenas o método IsValid() é público. Isso significa que quem usa a classe não precisa se preocupar com os detalhes dessas regras ou correr o risco de violar qualquer invariante.

Além disso, ao encapsular cada regra em seu próprio método privado, fica mais fácil testar e modificar a classe no futuro.

Podemos melhorar ainda mais a classe, utilizando a palavra chave readonly em Csharp. Mas qual o objetivo? Podemos utilizar para declarar que um campo (ou variável de instância) de uma classe ou struct só pode ser atribuído durante a sua declaração ou dentro do construtor do tipo ao qual pertence. Em outras palavras, uma vez que um valor foi atribuído a um campo readonly, esse valor não pode ser alterado.¹

O objetivo do readonly é fornecer uma garantia de que o valor de um campo permanecerá constante após a inicialização, permitindo assim a criação de objetos verdadeiramente imutáveis ou a proteção de determinados aspectos internos de um tipo contra modificações indesejadas. E quais as vantagens de se aderir?

Os benefícios de usar readonly incluem:

1. Garantia de Imutabilidade: Ajuda a garantir que uma vez que um objeto é criado em um estado particular, ele permanecerá nesse estado.

2. Intenção Clara: Indica claramente aos outros desenvolvedores que a intenção é que o valor não mude após a inicialização.

3. Proteção contra Erros: Evita erros acidentais em que um campo pode ser reatribuído de forma indesejada em outras partes do código.

Esses detalhes fazem a diferença no dia a dia, mas atenção!⚠️

🚨 Antes de utilizar qualquer palavra-chave de alguma linguagem de programação, busque estudar, isso é muito importante para entender o momento apropriado de aplicar! 🚨

Mas mesmo que a classe esteja coesa em nosso exemplo acima, gostaria de destacar alguns pontos de atenção:

1. Complexidade e Coesão: Ter muitos métodos privados pode ser um sinal de que sua classe está fazendo coisas demais. Cada classe deve ter uma responsabilidade única (Princípio da Responsabilidade Única). Se encontrar muitos métodos privados que parecem lidar com responsabilidades diferentes, pode ser hora de considerar a refatoração para separar essas responsabilidades em classes distintas.

2. Testabilidade: Enquanto métodos públicos são facilmente testáveis através de testes unitários, métodos privados não são diretamente acessíveis para teste. Se uma classe tem muitos métodos privados complexos, você pode achar difícil testar completamente a lógica contida nesses métodos sem expô-los.

3. Legibilidade: Mesmo que cada método privado faça algo específico e bem definido, ter um grande número deles pode tornar o código da classe difícil de ler e entender, especialmente para novos desenvolvedores que não estão familiarizados com a classe.

4. Manutenção: Mais métodos significam mais código para manter. Se uma classe tem muitos métodos privados, modificações e refatorações podem se tornar mais desafiadoras, pois alterações em um método podem ter efeitos colaterais em outros.

5. Encapsulamento Excessivo: Embora o encapsulamento seja um pilar fundamental, você deve ponderar se está encapsulando a lógica simplesmente pelo bem do encapsulamento ou se há um motivo claro e definido. Às vezes, pequenas operações podem ser feitas diretamente no método que as chama, em vez de serem encapsuladas em um método separado.

6. Reusabilidade e Acoplamento: Métodos privados não são reutilizáveis fora da classe. Se perceber que precisa de uma funcionalidade semelhante em outra classe, pode ser tentado a copiar e colar o método, o que não é ideal. Nesses casos, considere tornar o método protegido ou público, ou mover a lógica para uma classe de utilidade ou base.

Gostaria de reforçar mais algumas coisas antes de concluir o post. 😄

Visibilidade versus Vulnerabilidade

Quando projetamos uma classe, estamos essencialmente criando um contrato. As funcionalidades expostas - sejam elas métodos, propriedades ou eventos - formam promessas sobre o que a classe pode fazer. No entanto, com cada promessa que fazemos, surge um compromisso.

Uma interface pública excessivamente expansiva pode se tornar um pesadelo para manter. Toda vez que um método é exposto, ele se torna parte do contrato da classe. Isso significa que, no futuro, se decidirmos mudar a forma como esse método funciona internamente, podemos acabar quebrando o código que depende dele.

Por outro lado, uma interface pública muito restrita pode tornar a classe inútil ou difícil de ser usada por outras partes do código. A classe pode se tornar um "caixa preta" onde a funcionalidade desejada está lá, mas é inacessível.

Projetando para Evolução

Uma das principais razões para se preocupar profundamente com a interface pública é a evolução do código. Em algum momento, quase todas as classes passarão por refatorações ou extensões. Uma interface pública bem projetada facilita essas mudanças. Ela permite que você mude a implementação interna da classe sem afetar os consumidores dessa classe. Esta é uma qualidade conhecida como encapsulamento.

Testabilidade como Bússola

Uma boa interface pública não é apenas sobre o que os outros desenvolvedores veem e usam. É também sobre o que os testes podem alcançar. Ao projetar uma classe, é essencial pensar em como ela será testada. Métodos que são privados podem ser inacessíveis para testes diretos, o que pode dificultar a validação de comportamentos específicos. No entanto, expor um método apenas para testá-lo pode ser uma má prática.

Isso nos leva a um equilíbrio delicado: quão "aberto" ou "fechado" deve ser nossa classe? Uma estratégia comum é expor a funcionalidade através de métodos públicos, como já comentamos mais acima no exemplo ValidadorString, uma interface publica, que captura os principais "casos de uso" da classe, enquanto mantém a lógica mais granular e específica como privada.

Conclusão

Ufa! Quanto assunto sobre o encapsulamento. Parece um assunto raso e que não tem tanta importância. Mas quando colocamos na ponta do lápis estudando detalhadamente como aplicar em nosso dia a dia, vemos que temos muitos pontos a melhorar e podemos tirar muito proveito desse pilar tão importante da OOP.

Ao olhar além da superfície, percebemos que não se trata apenas de esconder dados, mas de proteger a integridade de um sistema, garantir sua manutenção eficaz e promover uma comunicação clara entre os componentes do software.

Quando utilizamos o encapsulamento da maneira correta, temos a capacidade de construir sistemas mais resilientes, menos propensos a erros e mais adaptáveis a mudanças. Neste sentido, o encapsulamento se assemelha ao trabalho de um escultor: ele não apenas molda a forma externa, mas também se preocupa profundamente com a estrutura e integridade internas de sua obra.

Para os desenvolvedores que buscam excelência, é fundamental ver o encapsulamento não apenas como um mero requisito, mas como uma poderosa ferramenta que, quando usada corretamente, pode elevar a qualidade do software a novos patamares. Portanto, lembre-se sempre de olhar além da superfície, pois é lá que reside a verdadeira arte da programação.

1. Java: Em Java, você usaria a palavra-chave final para campos para obter um comportamento semelhante. No entanto, vale lembrar que final em Java também pode ser usado para métodos e classes, significando que eles não podem ser sobrescritos ou estendidos, respectivamente.

Python: Python não tem um modificador direto semelhante ao readonly, já que a linguagem segue o princípio "somos todos adultos aqui", confiando que os desenvolvedores seguirão as convenções. No entanto, um padrão comum é usar um sublinhado prefixado (_) para indicar propriedades que não devem ser modificadas externamente. Também é possível criar propriedades somente de leitura usando o decorador @property.

TypeScript/JavaScript (ES6+): No TypeScript, você pode usar o modificador readonly diretamente. Em JavaScript puro (ES6+), você pode usar Object.freeze() ou definir propriedades somente de leitura.