Orientação a objetos: encapsulamento e abstração

Orientação a objetos é um daqueles assuntos que assusta pelo nome antes mesmo de você entender o que é. Encapsulamento, abstração, herança, polimorfismo. Parece coisa de faculdade de exatas, mas na prática é muito mais simples do que parece.

A primeira coisa que você precisa entender é que orientação a objetos não é melhor nem pior do que programação estruturada. É uma forma diferente de programar, com vantagens que aparecem em contextos específicos. E hoje a maioria dos sistemas usa orientação a objetos, então vale entender como isso funciona.

O que é um objeto

Pensa em um controle de ar condicionado. Você aperta o botão de menos e a temperatura diminui. Simples assim do seu ponto de vista. Mas por trás desse botão tem um sinal elétrico, uma comunicação com o aparelho, o aparelho acionando o compressor, ajustando o fluxo de ar, e por aí vai.

Você não precisa saber nada disso. Você só aperta o botão.

Na programação orientada a objetos é exatamente essa a ideia. Você cria estruturas de código, os objetos, que fazem coisas complexas por dentro mas que para quem está usando ficam simples de operar. O programador que usa o objeto aperta o botão. Quem criou o objeto é que precisou montar toda a parte interna.

Encapsulamento

Encapsulamento é basicamente isso: pegar códigos que falam de uma mesma coisa e agrupá-los em um lugar só.

Vamos ver com um exemplo prático. Imagine que você quer calcular o salário efetivo de um funcionário. Na programação estruturada você faria assim:

$nome = "Fulano";
$salarioBase = 1000;
$horasExtras = 10;
$valorDaHora = 20;
 
$salarioEfetivo = $salarioBase + ($horasExtras * $valorDaHora);
 
echo $salarioEfetivo; // 1200

Funcionou. Resultado correto. Agora imagine que em dez lugares diferentes do sistema você precisa calcular o salário efetivo. Você vai copiar e colar esse bloco dez vezes.

O problema aparece quando a regra muda. A empresa decide que todo funcionário com horas extras vai ter um adicional de 10% no salário base. Agora você precisa sair procurando esse cálculo em todos os dez lugares do sistema e ajustar um por um. E o risco de esquecer algum, de ter um lugar calculando diferente dos outros, é real.

Na orientação a objetos você cria uma classe:

class Funcionario {
    public $nome;
    public $salarioBase;
    public $horasExtras;
    public $valorDaHora;
 
    public function getSalarioEfetivo() {
        return $this->salarioBase + ($this->horasExtras * $this->valorDaHora);
    }
}

E onde você precisar usar:

$funcionario = new Funcionario();
$funcionario->nome = "Fulano";
$funcionario->salarioBase = 1000;
$funcionario->horasExtras = 10;
$funcionario->valorDaHora = 20;
 
echo $funcionario->getSalarioEfetivo(); // 1200

Parece mais código para o mesmo resultado, e é. A vantagem não aparece agora, aparece quando você usa essa mesma classe em dez lugares do sistema. Quando a regra mudar, você altera só o método getSalarioEfetivo dentro da classe e pronto. Todo o sistema passa a calcular corretamente, sem precisar tocar em mais nada.

Abstração

Abstração anda junto com encapsulamento e é a consequência direta dele. O objetivo é fazer com que o programador que vai usar a classe não precise saber o que acontece por dentro dela.

Voltando ao exemplo: o programador que usa o objeto Funcionario não sabe como o getSalarioEfetivo faz o cálculo. Ele só sabe que, quando chamar esse método, vai receber o salário correto. A complexidade fica por trás, abstraída.

Isso fica ainda mais claro quando você pensa em uma funcionalidade como salvar o funcionário no banco de dados. Na programação estruturada você montaria o SQL, executaria a query, trataria os erros, em cada lugar que precisasse salvar um funcionário.

Na orientação a objetos:

$funcionario->adicionar();

Uma linha. Por dentro pode ter SQL, pode ter Firebase, pode ter uma API externa. Não importa para quem está usando. E se um dia o sistema trocar de banco de dados, você muda só o método adicionar dentro da classe e nenhuma outra parte do código precisa ser tocada.

É exatamente o controle de ar condicionado de novo. Não importa se o sinal vai por infravermelho, bluetooth ou wifi. Você aperta o botão e funciona.

Por que isso faz sentido no mundo real

Orientação a objetos começa a valer quando o sistema cresce. Para um script de oito linhas, estruturado é mais direto e mais simples.

Mas quando você tem um sistema com relatórios, telas de cadastro, folha de pagamento, e todos esses lugares precisam calcular o salário de um funcionário, ter tudo centralizado em uma classe significa que o código fica confiável. Você sabe que em qualquer lugar que calcule o salário efetivo, a conta vai ser a mesma. E qualquer ajuste de regra de negócio você resolve em um lugar só.

Nos próximos vídeos a gente vai ver os outros dois conceitos, herança e polimorfismo, que aprofundam ainda mais o que dá pra fazer com esse modelo.