Introdução à Programação Orientada a Objetos (POO)

Ao longo desses artigos até o momento, você chegou a conhecer uma grande parte fundamental das características que as linguagens de programação possuem umas com as outras. A ideia é exatamente, fazer com que você não se torne um programador “preconceituoso”. Vejo na internet uma galera segregando os profissionais segundo as suas “linguagens de programação preferidas”. No artigo “O que são linguagens de programação?”, explico que existem evoluções nas linguagens e a cada nova geração, vão surgindo problemas e por consequência, vão surgindo novas linguagens e novos paradigmas. Nesse mesmo artigo, abordo que existem vários paradigmas em programação, e no artigo anterior a este, complemento falando sobre classes e objetos, que está totalmente ligado ao paradigma de Programação Orientada a Objetos (simplesmente POO).

Resumo da história da Programação Orientada a Objetos

Só para você contextualizar, essa galera que falei que fica de “mimimi” escolhendo linguagens de programação de estimação, em sua grande maioria não fazem ideia sobre essas questões das evoluções que as linguagens passam. Por exemplo, quando você for concorrer a uma vaga de emprego como programador, hoje, um dos pré-requisitos é saber programar orientado a objetos. Parece algo novo, moderno, não é? Porém, sua origem é bem antiga, só agora que está em evidência.

A Programação Orientada ao Objeto, ou em inglês Object-Oriented Programming (OOP), foi criada no início da década de 70, a sua origem vem da linguagem de programação chamada Simula, criada na Noruega na década de 60. Essa linguagem foi criada para fazer simulações, que visava utilizar “similaridades do mundo real” para organizar logicamente as coisas dentro do programa. 

Antes que o “mimimim” de linguagem de estimação te pegue, lembre-se: em 1967 a linguagem Simula-68, introduziu os primeiros conceitos sobre Orientação a Objetos e só a partir de 1995 que começaram a surgir as linguagens populares que temos hoje, como grande exemplo o Java. Sacou? Sem “mimimi” ok? kkkkk

No artigo anterior, você já viu uma “salada de palavras reservadas”: private, public, void, self, … Elas só vão fazer sentido, se você entender os pilares da Orientação a Objetos.

Desmistificando os pilares da Orientação a Objetos

A Programação Orientada a Objetos tem quatro pilares, são eles: abstração, encapsulamento, herança e polimorfismo.

Nossa! Parece que estou complicando, não é? Mas não estou não!!! kkkkk Todos esses 4 pilares você já sabe naturalmente. Se a orientação a objetos é a capacidade de pegar a representação da nossa realidade, como exemplo, abstrair as características de uma zebra, então, você já tem esses quatro pilares em sua mente. Só precisa agora ver como utilizar em programação. Sacou? Quer ver como é mais simples do que parece? Vamos lá!!!!

Abstração

Abstrair significa selecionar aspectos, características, atributos e métodos específicos de alguma coisa a ser analisada. Quanto maior o nível de abstração, maior serão os detalhes. Por exemplo, vamos fazer uma abstração se um “carro”. 

• Um carro tem portas. Pode ter 2, 3, 4, 5…
• Um carro tem uma cor, tem uma marca
• Um carro tem rodas, pneus
• Um carro tem motor…  E por aí em diante… 

É isso! Pegamos atributos (características, como exemplo a cor) e métodos (que representam ações, como dirigir).

Grave bem essa frase: quanto maior o nível de abstração, maior será a sua complexidade. Veja outros exemplos sobre abstração no artigo anterior.

Encapsulamento

A palavra encapsulamento te faz lembrar o que? Eu sempre lembro de uma cápsula de remédio. Agora vamos fazer uma abstração… Você sabe que tem alguma coisa dentro da cápsula, sabe que é um remédio e sabe qual será o mal aquele remédio vai tratar, correto? Você precisa saber o que tem dentro dessa cápsula de remédio para saber que é um remédio? Literalmente o fabricante “encapsula” esses ingredientes do remédio em uma cápsula.  Sacou?

Sempre tenha em mente, quando você criar uma classe e quiser que algo seja “protegido” (protected) ou deixar alguma coisa “privada” (private)  de acesso “livre” (public) para outras partes de seu programa, você está “encapsulando” as regras do seu código (chamadas de regras de negócio).

Olha ai!!! Essas 3 palavras reservadas que você já está vendo, protected, private e public. São chamados de modificadores de visibilidade. São elas que vão gerar o conceito de encapsulamento. Quando for explicar sobre herança, vou mostrar como funciona esses modificadores, através alguns exemplos.

Herança

Quando você vê essa palavra herança, já pensa logo em alguem morrendo e outras pessoas brigando pelos seus bens, não é kkkkkk? A herança em programação, tem mais o sentido de você herdar características de outras coisas. Por exemplo, imagine um casal de chineses que acaba de ter um filho. Esse filho vai “herdar” características dos pais, como exemplo os olhinhos puxados, não é verdade? Em programação orientada a objetos, sempre pense em herança como uma classe filha que “herda” os  atributos e métodos da classe pais.  A classe pai é chamada de superclasse e as classes filhas são chamadas de subclasses. 

Vou te mostrar um exemplo muito comum de herança com encapsulamento utilizando a linguagem de programação Java. Pense em uma empresa… Uma empresa possui vários funcionários, correto? E dentro dessa categoria de funcionário, existem outros qualificadores que distinguem as suas funções. Par agora, vamos pensar apenas em um funcionário faxineiro e em um funcionário gerente.

Atenção! Que quando estou escrevendo meu código-fonte, só utilizo acentuação nos textos entre aspas (string), no resto, não utilizo. Como no exemplo a seguir, “Funcionário”, eu escrevo “Funcionario” sem acento. Isso faz parte das linguagens de programação. Se você tentar escrever uma variável ou uma função com acentuação, o seu código não vai compilar. Vai gerar um erro de sintaxe.

Continuando…

Primeiro vamos criar a classe PAI (superclasse) chamada “Funcionario”:

Note que essa classe é “pública”, ou seja, pode ser vista em todas as partes de nosso projeto, assim como também os 2 atributos e 1 método são públicos, ou seja, podem ser acessado e manipulados livremente no programa que utilizar essa classe.

Agora você deve estar pensando: agora complicou Walmir!!!! kkkkkk Relaxa! Você vai entender agora… Voltando… Para criarmos essa classe “Funcionario”, precisamos antes de um motivo, um objetivo, ou seja, um problema para resolver. O problema que vamos resolver é criar um método para exibir o salário dos funcionários. Por isso temos o método “exibirSalario”. Ao utilizar essa classe, vamos ter a seguinte saída (output):

Observe que quando quero informar o nome do funcionário, estou acessando o atributo nome, publicamente, ou seja, diretamente fora da classe. Da mesma forma o salário também está público, imagine se tivéssemos outro programa trocando de 12 mil para 100 mil, teríamos um grande problema, não é verdade? É por causa desse e outros tipos de problemas, que encapsulamos as regras de negócio. Para contornar esse problema, utilizamos a palavra reservada “private” nos atributos da classe. Dessa forma, não será possível, fazer a ação anterior (trocar seus valores fora da classe).

Se você tentar agora acessar esses atributos publicamente, dará um erro e o programa não será compilado. Veja como ficará a chamada dessa classe com seus atributos agora encapsulados:

Note que até o valor do Salário eu encapsulei kkkk Agora pense o seguinte: dá para identificar que esse funcionário é do tipo Gerente ou Faxineiro? Outra situação, imagine que o funcionário do tipo Gerente, tivesse seu salário um acréscimo de 10% em bonificação… Imaginou? É aí que entra a “herança” na jogada para resolver esse problema. Vamos fazer duas novas classes que serão uma EXTENSÃO da superclasse (classe pai):

Observe que em Java utilizamos a palavra reservada “extends” para fazer as subclasses herdarem os atributos e métodos da superclasse. Apenas fizemos essas duas novas classes herdarem tudo… Veja o que acontece:

As classes Gerente e Faxineiro que são do tipo Funcionário, agora estão herdando tudo da classe “Funcionario”, inclusive o salário está igual para os dois tipos de funcionários kkkk…  Mas como definimos os atributos da classe “Funcionario” como “privados”, as classes filhas não conseguem trocar o seu valor. Para que elas tenham essa capacidade, os atributos da superclasse precisam ter a sua visibilidade como protegidos (protected) e não privados (private). Desse modo, as filhas continuam tendo o encapsulamento funcionando, e esses atributos continuam “indisponíveis” fora da classe (public). Veja:

Observe que nas subclasses (filhas), nós não implementamos o método “exibirSalario”, ela herdou da superclasse. Observe também que quando vamos rodar (run) o programa, nada muda na chamada (a escrita continua igual na quando chamado no programa “TestFuncionario”), porém os valores dos salários agora são distintos quando exibidos:

Resumo sobre Herança e Encapsulamento

No começo parece um pouco confuso esse tema. Mas vou fazer um super resumo para te ajudar a compreender todos esses exemplos e conceitos explicados até agora kkkk. Vamos la!

• Uma classe pai é chamada de superclasse
• Uma classe filha é chamada de subclasse
• Existem modificadores de visibilidade de atributos e métodos, são eles:
  • public = Público, permite que quando instanciamos uma classe, podemos ter acesso aos seus atributos e métodos livremente (publicamente);
  • private = Privado, permite “privar” uma classe de ter os seus atributos ou métodos acessíveis fora dela mesma. Nem herdando, a subclasse vai poder manipular (trocar os valores) dos atributos e métodos privados que constam na superclasse;
  • protected = Protegido, permite a uma superclasse deixar seus atributos e métodos “visíveis” e “acessíveis” apenas para as suas subclasses (que estendem da superclasse). Se tentar acessar esses atributos e métodos fora da classe, o programa não vai compilar e vai gerar um erro.
• Ressaltando: uma vez que houver uma herança, as classes filhas só terão acesso a visualizar e manipular atributos e métodos que estiverem com a visibilidade public ou protected, private não!

Nem todas as linguagens de programação possuem essas palavras reservadas. Algumas utilizam outros nomes ou artificios, como exemplo no C#, a herança utiliza o sinal de dois pontos (:) para representar uma extensão (extends).

Outra coisa.. Nem todas as linguagens têm capacidade de ser utilizada para Programação Orientado a Objetos.  Então, fique atento a isso!!! Vamos continuar… Agora vem o Polimorfismo.

Polimorfismo

Chegamos ao polimorfismo, que significa “muitas formas”. Para você entender esse conceito, vamos mudar um pouco a classe “Funcionario”.  Imagine agora que os Funcionários do tipo Gerente, recebem um acréscimo de 10% no salário. Temos o método “exibirSalario” na superclasse, no entanto, precisamos desses ‘múltiplos comportamentos” em nosso progrma. Ou seja, precisamos de “múltiplas formas” de implementação do método “exibirSalario”. A esse comportamento, chamamos de polimorfismo.

Para ficar mais claro e didático, além do Gerente, vamos definir que o Faxineiro também vai ter 5% de acréscimo no salário kkkk  É pouco o acréscimo, mas é de coração kkkkk Então o código-fonte vai ficar assim para essas 3 classes:

Essa ação de fizemos aqui para simular o polimorfismo, chama-se sobrescrita de método.

Uma coisa importante, observe que a classe “Funcionario”, continua com o método “exibirSalario” inalterado, sem acréscimo de porcentagem. Ou seja, quem estender essa classe, vai ter o método “exibirSalario” na sua forma original.

É isso aí! Acredito que consegui te passar esses conceitos tão importantes em Programação Orientada a Objetos. Existem outros detalhes que algumas linguagens de programação possuem em POO, mas, para agora não convém explicar, porque o foco é te mostrar características comuns que existem entre diversas linguagens de programação da atualidade. Foquem nos conceitos!

Hoje, se você chegar em uma entrevista de emprego e não souber os conceitos de paradigma de  programação orientada a objetos, será muito difícil a sua contratação. Então, leiam, releiam mil vezes se for o caso kkkk Se tiver dúvidas, deixe um comentário aqui! Beleza? No próximo artigo vou explicar um pouco mais sobre os diversos paradigmas de programação mais comuns que irão te ajudar nessa jornada como programador ou programadora. Até lá!

Confiança Sempre!!!