Skip to main content

4 pilares da orientação a objetos.

Este post faz parte de uma sequência de posts para desmistificar a orientação a objetos, esses posts serão:

#1 O que é a orientação a objetos, uma visão geral sobre orientação a objetos e como ela funciona.

#2 Os 4 Pilares da orientação a objetos.

#3 Os principais benefícios que a orientação a objetos traz para você e para seu código.

#4 como continuar evoluindo em orientação a objetos.

Se você leu o primeiro post viu que um para a orientação a objetos sempre devemos estar pensando em como os objetos se relacionam certo?

Porém as vezes precisamos criar novas funcionalidades nos nossos objetos para que essa relação seja mais completa, mas, como fazemos isso?

Utilizando os 4 pilares da orientação a objetos podemos criar, estender ou modificar comportamentos das nossas classes para que elas consigam interagir de uma forma mais semântica, mas, quais são esses pilares? Ótima pergunta, vamos lá!!

Encapsulamento

Na programação procedural, temos nossos programas escritos através de um punhado de funções que vão se interligando até a saída do sistema, porém a medida que o código cresce o as funções vão se duplicando e fica cada vez mais complexo de manter as funcionalidades do sistema por que estamos produzindo um código macarrônico.

A orientação objetos resolve esse problema pois ao centralizar todas essas funções em um único ponto podemos reutiliza-las onde a gente quiser. Essa centralização é o que chamamos de encapsulamento.

Toda classe encapsula seus atributos(variáveis) e seus comportamentos (funções) e a partir da instancia dessa classe podemos reutilizar essas funções em todo lugar do sistema.

Porém um código bem encapsulado não é uma tarefa simples, precisamos questionar sempre ao criar um método em uma classe se o mesmo está no lugar certo além de seus atributos de acessibilidade.

Por exemplo não podemos esperar que nas propriedades de uma classe pessoa tenhamos a propriedade quantidade de rodas, pois por definição Pessoas não tem rodas. Logo nesse sentido o mais prudente seria criar uma classe automóvel e definir como suas propriedades quantidade de rodas.

Assim poderíamos relacionar os objetos futuramente, dizendo que um Pessoa pode possuir um carro?

Abstração

Aqui que normalmente o programador começa a ficar confuso, por tanto vou ser o mais descritivo possível para não restar dúvidas.

Uma abstração é um “Modelo” de algum objeto, é a representação mais simples possível sem se preocupar ainda com os detalhes da implementação.

Por exemplo, se a gente analisar as pessoas do mundo real, todos nós somos da classe raça humana, que por sua vez é um mamífero.

Mamífero é a representação “abstrata” de um ser humano, pois compartilhamos comportamentos comuns com outros mamíferos.

Podemos fazer essa mesma lógica com carros, carros são na verdade um tipo de “Automóvel”, e o carro compartilha comportamentos com outros automóveis como, por exemplo, quantidade de rodas, o ato de ligar e desligar.

Classes Abstratas servem como implementações padrão (Templates) e não podem ser instanciadas uma vez que dependem da implementação final para funcionar.

Podemos citar também que a partir da abstração conseguimos reduzir os efeitos colaterais de novas implementações, pois o comportamento novo deverá ser implementado na classe filha.

E por falar nisso.

Herança

A herança ajuda a reduzir a quantidade de código duplicado em nosso sistema, como?

Bom, vamos imaginar a maioria dos componentes de um formulário HTML eles têm dentro de si as mesmas funções básicas de “OnClick” para quando o usuário clica no elemento ou “OnHover” para quando o usuário posiciona o mouse em cima do elemento.

Neste caso ao invés de duplicar código para todos os elementos do HTML seria mais indicado criar uma classe “ElementoHTML” onde cada elemento (CheckBox por exemplo) podesse estender a calsse ElementoHTML herdando assim seus comportamentos padrão.

Para voltar ao passo anterior a relação entre a classe Carro e Automóvel é uma reação onde a classe carro estende a classe automóvel herdando seus comportamentos padrão.

Polimorfismo

O Polimorfismo é quase como um efeito colateral de um sistema em escrito, se nós estamos utilizando as abstrações e suas implementações corretamente podemos admitir que uma Classe Abstrata tem “muitas formas” pois cada uma de suas classes filhas é uma forma potencial.

No caso do exemplo anterior, todos os “ElementoHTML” tem a capacidade de aparecer na tela, porém, cada elemento aparece de uma forma diferente, ao implementarmos o método aparecer em cada elemento filho podemos dizer que a classe “ElementoHTML” tem muitas formas de aparecer.

Na pratica isso ajuda nosso código reduzindo a quantidade de if e elses não precisamos tratar o comportamento pelo tipo da classe pai.

No próximo capítulo.

No Próximo iremos falar mais sobre os benefícios que cada uma dessas técnicas trás para o nosso código, então fica ligado que vem mais conteúdo por aí.

Se você gostou do post não esquece de curtir a nossa pagina nas redes socias, tem muito, muito conteúdo banca por lá também 😊

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

14 Compart.
Twittar
Compartilhar
Pin
Compartilhar14