Na sociedade de hoje, impulsionada pela tecnologia, o conhecimento de programação de computadores está em alta demanda. Como desenvolvedor, você precisará conhecer várias linguagens de programação.

Nas últimas décadas, muitas linguagens de programação ganharam popularidade. Você pode ver como as linguagens populares são classificadas neste gráfico de classificação em tempo real aqui (site em inglês).

Enquanto novas linguagens estão sendo criadas, as existentes estão sempre sendo atualizadas para ficarem cada vez melhores.

Embora a maioria das linguagens de programação tenham algumas semelhanças, cada uma tem regras e métodos específicos que a tornam única.

Um conceito que é comum entre muitas linguagens de programação é a Programação Orientada a Objetos.

Quando me deparei com esse termo pela primeira vez, foi um pouco confuso. Levei algum tempo para realmente entender sua importância na programação. Isso, porém, serviu também como uma oportunidade para aprender seus conceitos-chave e saber da importância do conceito para a carreira de um desenvolvedor e para ser capaz de resolver desafios.

Neste artigo, abordaremos a Programação Orientada a Objetos (OOP – do inglês Object-Oriented Programming) como um todo, sem depender de uma linguagem específica. Você aprenderá o que é, por que é tão popular como paradigma de programação, sua estrutura, como funciona, seus princípios e muito mais.

Vamos começar.

O que é a Programação Orientada a Objetos?

Se você fizesse uma pesquisa rápida na internet sobre o que é programação orientada a objetos, descobriria que a OOP é definida como um paradigma de programação que se baseia no conceito de classes e objetos.

Agora, para um iniciante, isso pode ser um pouco confuso – mesmo assim, você não precisa se preocupar. Tentarei explicar da maneira mais simples possível, como na famosa frase: "Explique para mim como se eu tivesse 5 anos".

Aqui está uma breve visão geral do que você pode alcançar com a OOP: você pode usá-la para estruturar um programa em blocos de código simples e reutilizáveis (neste caso, geralmente chamados de classes), que você, então, usará para criar instâncias individuais dos objetos.

Então, vamos encontrar uma definição mais fácil de programação orientada a objetos e aprender mais sobre ela.

Explique OOP como se eu tivesse 5 anos

A expressão "orientada a objetos" é uma combinação de dois termos, objeto e orientada.

O significado dicionarizado de objeto é "uma entidade que existe no mundo real", e orientada significa "interessada em um tipo particular de coisa ou entidade".

Em termos básicos, OOP é um padrão de programação que é construído em torno de objetos ou entidades. Por isso, ela é chamada de programação orientada a objetos.

Para entender melhor o conceito, vamos dar uma olhada em programas comumente usados: um bom exemplo para explicar isso seria o uso de uma impressora quando você está imprimindo um documento.

A primeira etapa é iniciar a ação clicando no comando de impressão ou usando atalhos de teclado. Em seguida, você precisa selecionar sua impressora. Depois, você esperará uma resposta informando se o documento foi impresso ou não.

Por trás do que não podemos ver, o comando que você clicou interage com um objeto (impressora) para realizar a tarefa de impressão.

Talvez você se pergunte, como exatamente a OOP se tornou tão popular?

Como a OOP se tornou popular

Os conceitos de OOP começaram a surgir na década de 1960 com uma linguagem de programação chamada Simula. Embora, naquela época, os desenvolvedores não abraçassem completamente os primeiros avanços nas linguagens OOP, as metodologias continuaram a evoluir.

Avançando para a década de 1980, um editorial escrito por David Robinson foi uma das primeiras introduções à OOP, já que muitos desenvolvedores não sabiam que ela existia.

Até então, linguagens como C++ e Eiffel se tornaram mais populares e comuns entre os programadores de computadores. O reconhecimento continuou a crescer durante a década de 1990 e, com a chegada do Java, a OOP atraiu um grande número de seguidores.

Em 2002, em conjunto com o lançamento do .NET Framework, a Microsoft introduziu uma nova linguagem OOP chamada C# – que é frequentemente descrita como a linguagem de programação mais poderosa.

É interessante que, gerações depois, o conceito de organizar seu código em objetos significativos que modelam as partes do seu problema continua a intrigar os programadores.

Muitas pessoas que não têm ideia de como um computador funciona acham o pensamento de programação orientada a objetos bastante natural. Em contraste, muitas pessoas que têm experiência com computadores inicialmente acham que há algo de estranho nos sistemas orientados a objetos.

Estrutura da OOP

Imagine que você está administrando uma loja de animais de estimação, com muitas raças diferentes, e que você precisa controlar os nomes, a idade, os dias de atendimento e outros detalhes comuns de manutenção. Como você projetaria um software reutilizável para lidar com isso?

Lembre-se de que temos muitas raças. Assim, escrever código para cada uma seria cansativo. Podemos, no entanto, agrupar informações relacionadas para que possamos produzir código mais curto e reutilizável.

É aí que os blocos de construção entram para nos ajudar a fazer isso usando Classes, Objetos, Métodos e Atributos.

Vamos mergulhar a fundo e entender exatamente o que são esses blocos de construção:

Classes – são tipos de dados definidos pelo usuário que atuam como o modelo para objetos, atributos e métodos.

Objetos – são instâncias de uma classe com dados especificamente definidos. Quando uma classe é definida inicialmente, a descrição é o único objeto que é definido.

Métodos – são funções definidas dentro de uma classe que descrevem o comportamento de um objeto. Eles são úteis para a reutilização ou para manter a funcionalidade encapsulada dentro de um objeto por vez. A reutilização de código é um grande benefício ao depurar.

Atributos – são definidos no modelo de classe e representam o estado de um objeto. Os objetos contêm dados armazenados no campo de atributo.

Princípios da OOP

Para que possamos saber como escrever um bom código OOP, precisamos entender os 4 pilares da OOP que devemos seguir:

• Encapsulamento
• Abstração
• Herança
• Polimorfismo

Vamos mergulhar a fundo e entender melhor o que exatamente cada um deles significa.

Encapsulamento

Esse é o conceito que vincula os dados. As funções manipulam as informações e as mantêm seguras. Nenhum acesso direto é concedido às informações, caso elas estejam ocultas. Se você deseja obter acesso às informações, precisa interagir com o artigo responsável pelas informações.

Se você trabalha em uma empresa, é muito provável que tenha tido experiência com encapsulamento.

Pense em um departamento de recursos humanos. Os membros da equipe de recursos humanos encapsulam (escondem) os dados sobre os funcionários. Eles determinam como esses dados serão usados e manipulados. Qualquer solicitação de dados do trabalhador ou solicitação para atualizar as informações deve ser encaminhada por meio deles.

Ao encapsular dados, você torna as informações do seu sistema mais seguras e confiáveis. Você também pode monitorar como as informações estão sendo acessadas e quais operações estão sendo realizadas nelas. Isso torna a manutenção do programa mais fácil e simplifica o processo de depuração.

Abstração

Abstração se refere ao uso de classes simples para representar a complexidade. Basicamente, usamos a abstração para lidar com a complexidade, permitindo que o usuário veja apenas informações relevantes e úteis.

Um bom exemplo para explicar isso é dirigir um carro automático. Quando você tem um carro automático e deseja ir do ponto A ao ponto B, tudo o que precisa fazer é informar o destino e dar partida no carro. Então, ele o levará ao seu destino.

O que você não precisa saber é como o carro é feito, como ele recebe e segue as instruções corretamente, como o carro filtra diferentes opções para encontrar a melhor rota e assim por diante.

O mesmo conceito é aplicado ao construir aplicações em OOP. Você faz isso ocultando detalhes que o usuário não precisa ver. A abstração facilita e permite que você gerencie seus projetos em partes pequenas e gerenciáveis.

Herança

A herança permite que as classes herdem recursos de outras classes. Como exemplo, você poderia classificar todos os gatos juntos como tendo certas características comuns, como ter quatro patas. Suas raças os classificam ainda mais em subgrupos com atributos comuns, como tamanho e cor.

Você usa a herança na OOP para classificar os objetos em seus programas de acordo com características e desempenho comuns. Isso torna o trabalho com os objetos e a programação mais fácil, pois permite que você tenha características gerais em um objeto pai e faça com que os objetos filhos herdem essas características.

Por exemplo, você definirá um objeto funcionário, que define todas as características gerais dos funcionários da sua empresa.

Você poderá, então, definir um objeto gerente que herda as características do objeto funcionário, mas também adiciona características exclusivas dos gerentes da sua empresa. O objeto gerente refletirá automaticamente quaisquer alterações na implementação do objeto funcionário.

Polimorfismo

Esse é o poder de dois objetos diferentes responderem de um mesmo modo. O programa determinará qual uso é crítico para cada execução da coisa da classe pai, o que reduz a duplicação de código. Também permite que diferentes tipos de objetos interajam com a mesma interface.

Exemplos de linguagens OOP

Tecnologia e linguagens de programação estão evoluindo o tempo todo. Vimos o surgimento de muitas linguagens sob a categoria OOP, mas a Simula é creditada como a primeira linguagem OOP.

Linguagens de programação que são consideradas OOP puras tratam tudo como objetos, enquanto as outras são projetadas principalmente com algum processo procedural.

Exemplos de linguagens OOP:

• Scala
• Emerald
• Ruby
• JADE
• Java
• Python
• C++
• JavaScript
• Visual Basic .NET
• PHP

Ainda existem várias outras, mas essas são as mais conhecidas.

Benefícios da OOP

Durante as décadas de 1970 e 1980, linguagens de programação orientadas a procedimentos, como C e Pascal, eram amplamente usadas para desenvolver sistemas de software orientados a negócios. À medida que os programas executavam funcionalidades de negócios mais complexas e interagiam com outros sistemas, porém, as deficiências da metodologia de programação estrutural começaram a aparecer.

Devido a isso, muitos desenvolvedores de software recorreram a metodologias e linguagens de programação orientadas a objetos para resolver os problemas encontrados. Os benefícios de se usar essas linguagens incluíam:

Reutilização de código – por meio da herança, você pode reutilizar o código. Isso significa que uma equipe não precisa escrever o mesmo código várias vezes.

Integração aprimorada com sistemas operacionais modernos.

Produtividade aprimorada – os desenvolvedores podem criar programas com facilidade e rapidez por meio do uso de várias bibliotecas.

O polimorfismo permite que uma única função se adapte à classe em que é colocada.

É fácil de atualizar – e os programadores também podem implementar funcionalidades do sistema de modo independente.

Por meio do encapsulamento, os objetos podem ser autocontidos. Isso também torna a solução de problemas e a colaboração no desenvolvimento mais fáceis.

Por meio do uso de encapsulamento e abstração, o código complexo é ocultado, a manutenção do software é mais fácil e os protocolos da Internet são protegidos.

Conclusão

Hoje, a maioria das linguagens permitem que os desenvolvedores misturem paradigmas de programação. Isso geralmente ocorre porque eles serão usados para vários métodos de programação.

Veja o JavaScript, por exemplo – você pode usá-lo para programação OOP e funcional. Quando você está programando em JavaScript orientado a objetos, você precisa pensar cuidadosamente sobre a estrutura do programa e planejar no início da programação. Você pode fazer isso visualizando como poderá dividir as necessidades em classes simples e reutilizáveis que serão instâncias de modelo de objetos personalizados.

Os desenvolvedores que trabalham com OOP geralmente concordam que, em geral, usá-la permite melhores estruturas de dados e reutilização de código. Isso economiza tempo a longo prazo.

A programação orientada à objetos oferece uma forma sustentável de escrever código espaguete. Ela permite que você escreva programas como se fosse uma colcha de retalhos.
― Paul Graham

Princípios de programação orientada a objetos

A programação orientada a objetos é um paradigma de programação onde tudo é representado como um objeto.

Objetos passam mensagens uns para os outros. Cada objeto decide o que fazer com uma mensagem recebida. A POO (em inglês, OOP - Object Oriented Programming) foca nos estados e comportamentos de cada objeto.

O que são objetos?

Um objeto é uma entidade que possui estados e comportamentos.

Por exemplo, cão, gato e veículo. Para ilustrar, um cão possui estados como idade, cor, nome e comportamentos como comer, dormir e correr.

Os estados nos dizem como o objeto se parece ou quais propriedades ele possui.

O comportamento nos diz o que o objeto faz.

Podemos representar um cão do mundo real em um programa como um objeto de software definindo seus estados e comportamentos.

Objetos de software são uma representação de um objeto do mundo real. É alocado espaço em memória sempre que um objeto lógico é criado.

Um objeto pode também ser referenciado como uma instância de uma classe. Instanciar uma classe significa a mesma coisa que criar um objeto.

Algo importante de se lembrar quando estamos criando um objeto é: o tipo de referência deve ser do mesmo tipo ou um supertipo do tipo do objeto. Veremos o que é um tipo de referência mais a frente neste artigo.

O que são classes?

Uma classe é um template - algo como a "planta" de uma construção - a partir do qual os objetos são criados.

Imagine uma classe como um cortador de biscoitos e os objetos como os próprios biscoitos.

Classes definem estados como variáveis de instância e comportamentos como métodos de instância.

Variáveis de instância também são conhecidas como "variáveis membro".

Classes não consomem espaço em memória.

Para dar uma ideia sobre classes e objetos, vamos criar uma classe Cat (Gato) que representa estados e comportamentos de um gato no mundo real.

public class Cat {
    /*
    Variáveis de instancia: Estados do gato
     */
    String name;
    int age;
    String color;
    String breed;

    /*
    Métodos de instancia: Comportamento do gato
     */
    void sleep(){
        System.out.println("Dormindo");
    }
    void play(){
        System.out.println("Brincando");
    }
    void feed(){
        System.out.println("Comendo");
    }

}

Agora que definimos um template de gatos, vamos dizer que temos dois gatos, chamados Thor e Rambo.

Como podemos defini-los em nossos programas?

Primeiro, precisamos criar dois objetos da classe Cat.

public class Main {
    public static void main(String[] args) {
       Cat thor = new Cat();
       Cat rambo = new Cat();
    }
}

Agora, vamos definir seus estados e comportamentos.

public class Main {

    public static void main(String[] args) {
       /*
       Criando os objetos
        */
       Cat thor = new Cat();
       Cat rambo = new Cat();

       /*
       Definindo o gato Thor
        */
       thor.name = "Thor";
       thor.age = 3;
       thor.breed = "Azul russo";
       thor.color = "Marrom";

       thor.sleep();

       /*
       Definindo o gato Rambo
        */
       rambo.name = "Rambo";
       rambo.age = 4;
       rambo.breed = "Maine Coon";
       rambo.color = "Marrom";

       rambo.play();
    }

}

Como nos exemplos de código acima, podemos definir nossas classes, instanciá-las (criar objetos) e especificar os estados e comportamentos para esses objetos.

Até aqui já cobrimos o básico de orientação a objetos. Vamos avançar para os princípios da orientação a objetos.

Princípios da programação orientada a objetos

Esses são os quatro princípios fundamentais do paradigma de programação orientada a objetos. Entendê-los é essencial para se tornar um programador de sucesso.

1. Encapsulamento
2. Herança
3. Abstração
4. Polimorfismo

Agora, vamos dar uma olhada neles com mais detalhes.

Encapsulamento

Encapsulamento é um processo de envolver dados e código em uma única unidade.

É como uma capsula que possui uma mistura de diversos medicamentos, é uma técnica que ajuda a manter as variáveis de instância protegidas.

Essa proteção pode ser conquistada utilizando o modificador de acesso private, que indica que a variável ou dado não pode ser acessado de fora da classe. Para acessar estados privados de modo seguro, temos que providenciar métodos getters e setters públicos (em Java, esses métodos devem seguir os padrões de nomenclatura "JavaBeans").

Digamos que existe uma loja de discos que vende álbuns de músicas de diferentes artistas e um estoque para o gerenciamento.

Se você observar a figura 4, a classe StockKeeper pode acessar os estados da classe Album diretamente, já que os atributos da classe Album estão definidos como public (sinal de +).

Se o gerenciador de estoque criar um álbum e definir seus estados como negativos, ele pode acabar fazendo isso mesmo que sem intenção.

Para ilustrar, vamos ver um exemplo de um programa em Java que explica o diagrama e a afirmação acima.

Classe Album:

public class Album {
    public String name;
    public String artist;
    public double price;
    public int numberOfCopies;
    public void sellCopies(){
        if(numberOfCopies > 0){
            numberOfCopies--;
            System.out.println("Um album foi vendido!");
        }
        else{
            System.out.println("Não há albuns disponíveis!");
        }
    }
    public void orderCopies(int num){
        numberOfCopies += num;
    }
}

Classe StockKeeper:

public class StockKeeper {
    public String name;
    public StockKeeper(String name){
        this.name = name;
    }
    public void manageAlbum(Album album, String name, String artist, double price, int numberOfCopies){
      /*
       Definindo os estados e comportamentos para album
       */
        album.name = name;
        album.artist = artist;
        album.price = price;
        album.numberOfCopies = numberOfCopies;

       /*
       Imprimindo os detalhes do album
        */
        System.out.println("Album gerenciado por :"+ this.name);
        System.out.println("Detalhes do album::::::::::");
        System.out.println("Nome do album: " + album.name);
        System.out.println("Artista do Album : " + album.artist);
        System.out.println("Preço do Album : " + album.price);
        System.out.println("Número de cópias do album : " + album.numberOfCopies);
    }
}

Classe Main:

public class Main {
    public static void main(String[] args) {
       StockKeeper johnDoe = new StockKeeper("John Doe");
       /*
       O gerenciador de estoque cria um album e atribui valores negativos para o preço e o numero de cópias disponíveis
        */
       johnDoe.manageAlbum(new Album(), "Slippery When Wet", "Bon Jovi", -1000.00, -50);
    }
}

Saída:

Album gerenciado por :John Doe
Detalhes do album::::::::::
Nome do album : Slippery When Wet
Artista do Album : Bon Jovi
Preço do Album :  -1000.0
Número de cópias do album : -50

O preço do álbum e número de cópias não podem ser valores negativos. Como podemos evitar essa situação? Aqui é onde usamos o encapsulamento.

Neste cenário, podemos impedir o gerenciador de estoque de atribuir valores negativos. Se ele tentar atribuir valores negativos para o preço e o número de cópias do álbum, definiremos 0.0 como o valor e 0 como o número de cópias.

Classe Album:

public class Album {
    private String name;
    private String artist;
    private double price;
    private int numberOfCopies;
    public void sellCopies(){
        if(numberOfCopies > 0){
            numberOfCopies--;
            System.out.println("Um álbum foi vendido!");
        }
        else{
            System.out.println("Nenhum álbum disponível!");
        }
    }
    public void orderCopies(int num){
        numberOfCopies += num;
    }
   public String getName() {
      return name;
   }
   public void setName(String name) {
      this.name = name;
   }
   public String getArtist() {
      return artist;
   }
   public void setArtist(String artist) {
      this.artist = artist;
   }
   public double getPrice() {
      return price;
   }
   public void setPrice(double price) {
      if(price > 0) {
         this.price = price;          
      }
      else {
         this.price = 0.0;
      }
   }
   public int getNumberOfCopies() {
      return numberOfCopies;
   }
   public void setNumberOfCopies(int numberOfCopies) {
      if(numberOfCopies > 0) {
         this.numberOfCopies = numberOfCopies;        
      }
      else {
         this.numberOfCopies = 0;
      }
   }
}

Classe StockKeeper:

public class StockKeeper {
    private String name;
    StockKeeper(String name){
        setName(name);
    }
    public void manageAlbum(Album album, String name, String artist, double price, int numberOfCopies){
         /*
          Definindo estados e comportamentos para o album
          */
        album.setName(name);
        album.setArtist(artist);
        album.setPrice(price);
        album.setNumberOfCopies(numberOfCopies);
          /*
          Imprimindo os detalhes do album
           */
        System.out.println("Album gerenciado por :"+ getName());
        System.out.println("Detalhes do album::::::::::");
        System.out.println("Nome do album : " + album.getName());
        System.out.println("Artista do Album : " + album.getArtist());
        System.out.println("Preço do Album : " + album.getPrice());
        System.out.println("Número de cópias do album : " + album.getNumberOfCopies());
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

Classe Main:

public class Main {
    public static void main(String[] args) {
       StockKeeper johnDoe = new StockKeeper("John Doe");
       /*
       Gerenciador de estoque cria um album e atribui valores negativos para o preço e o número de cópias disponíveis do album
        */
       johnDoe.manageAlbum(new Album(), "Slippery When Wet", "Bon Jovi", -1000.00, -50);
    }
}

Saída:

Album gerenciado por :John Doe
Detalhes do album::::::::::
Nome do album : Slippery When Wet
Artista do Album : Bon Jovi
Preço do Album : 0.0
Número de cópias do album : 0

Com o encapsulamento, impedimos nosso gerenciador de estoque de definir valores negativos, o que significa que temos o controle sobre as informações.

Vantagens do encapsulamento em Java

1. Podemos fazer uma classe somente leitura ou somente escrita. Para uma classe somente leitura, temos que informar apenas os métodos getters. Para uma classe somente escrita, devemos informar apenas os métodos setters.
2. Controle sobre os dados: podemos controlar os dados adicionando lógica nos métodos setters, assim como fizemos para evitar que o gerenciador de estoques definisse valores negativos nos exemplos acima.
3. Proteção dos dados: outras classes não podem acessar membros privados de uma classe diretamente.

Herança

Consideremos que a loja de discos que falamos anteriormente também venda filmes em Blu-ray.

Como você pode ver no diagrama acima, existem muitos estados e comportamentos em comum (código duplicado) entre Album e Movie.

Quando for transformar esse diagrama de classes em código, você vai reescrever/copiar todo o código novamente para Movie? Caso você faça isso, você estará se repetindo. Como você pode evitar a duplicação de código?

Aqui é onde usamos a herança.

Herança é um mecanismo onde um objeto recebe todos os comportamentos e estados de um objeto pai.

A herança utiliza um relacionamento de pais e filhos (relacionamento "É um" ).

Então o que exatamente é herdado?

Visibilidade/modificadores de acesso impacta o que pode ser herdado de uma classe para a outra.

Em Java, como regra fundamental, tornamos as varáveis de instância private e os métodos de instância public.

Neste caso, certamente podemos dizer que o seguinte será herdado:

1. métodos públicos de instância.
2. variáveis de instância privadas (que podem ser acessadas apenas por meio de métodos getters e setters públicos) .

Tipos de herança no Java

Existem cinco tipos diferentes de herança no Java. Elas são:  simples, multinível, hierárquica, múltipla e híbrida.

Classes permitem heranças simples, multinível e hierárquicas. Interfaces permitem heranças múltiplas e híbridas.

Uma classe pode estender apenas uma classe. Entretanto, não há limite para a implementação de interfaces. Uma interface pode estender mais de uma interface.

Relacionamentos

I. Relacionamento É UM

Um relacionamento É UM refere-se à herança ou implementação.

a. Generalização

Generalização usa um relacionamento É UM de uma classe especializada para uma classe generalizada.

II. Relacionamento TEM UM

Uma instância de uma classe TEM UMA referência para uma instância de outra classe.

a. Agregação

Neste relacionamento, a existência de uma classe A e B não são dependentes umas das outras.

Para essa parte de agregação, vamos ver um exemplo da classe Student e da classe ContactInfo.

class ContactInfo {
    private String homeAddress;
    private String emailAddress;
    private int telephoneNumber; //12025550156
}
public class Student {
    private String name;
    private int age;
    private int grade;
    private ContactInfo contactInfo;//Student TEM UM ContactInfo
    public void study() {
        System.out.println("Study");
    }
}

Student (aluno) TEM UMA ContactInfo (informação de contato). ContactInfo pode ser usado em outros lugares – por exemplo, uma classe Employee (funcionário) de um companhia também poderia utilizar a classe ContactInfo. Assim, Student pode existir sem ContactInfo e ContactInfo pode existir sem Student. Este tipo de relacionamento é conhecido como agregação.

b. Composição

Neste relacionamento, a classe B não pode existir sem uma classe A – mas a classe A pode existir sem a classe B.

Para dar uma ideia sobre composição, vamos ver esse exemplo da classe Student e a classe StudentId.

class StudentId {
    private String idNumber;//A-123456789
    private String bloodGroup;
    private String accountNumber;
}
public class Student {
    private String name;
    private int age;
    private int grade;
    private StudentId studentId;//Student TEM UM StudentId
    public void study() {
        System.out.println("Study");
    }
}

Student TEM UM StudentId. Student pode existir sem StudentId, mas StudentId não pode existir sem Student. Esse tipo de relacionamento é conhecido como composição.

Agora, vamos voltar para nosso exemplo da loja de discos que discutimos acima.

Podemos implementar esse diagrama em Java para evitar duplicação de código.

Vantagens de se usar herança

1. Reaproveitamento de código: as classes filhas herdam todos os membros de instância da classe pai.
2. Você tem mais flexibilidade de mudar o código: mudar o código em um lugar é o suficiente.
3. Você pode usar polimorfismo: a sobrescrita de métodos requer um relacionamento É UM.

Abstração

Abstração é o processo de esconder os detalhes de implementação e exibir apenas as funcionalidades para o usuário.

Um exemplo comum de abstração é o acelerador do carro: pisando mais forte, você aumenta a velocidade. Os motoristas, no entanto, não sabem como essa ação altera a velocidade – eles não precisam saber.

Tecnicamente, abstrato significa algo incompleto ou a ser finalizado no futuro.

Em Java, podemos obter abstração de duas maneiras: classes abstratas (0% a 100%) e interfaces (100%).

A palavra-chave abstract pode ser aplicada à classes e métodos. abstract e final ou static nunca podem estar juntas.

I. Classes abstratas

Uma classe é abstrata quando ela contém a palavra reservada abstract.

Classes abstratas não podem ser instanciadas  (não é possível criar objetos de classes abstratas). Elas podem ter construtores, métodos estáticos e métodos finais.

II. Métodos abstratos

Um método é abstrato quando ele contém a palavra chave abstract.

Um método abstrato não possui implementação (não possui um corpo e termina com ponto e virgula). Métodos abstratos não devem ser marcados como private.

III. Classes abstratas e métodos abstratos

• Se pelo menos um método for abstrato dentro de uma classe, então toda a classe deve ser abstrata.
• É possível ter uma classe abstrata sem nenhum método abstrato.
• Podemos ter qualquer quantidade de métodos abstratos e não abstratos ao mesmo tempo na mesma classe.
• A primeira classe concreta que herde de uma classe abstrata deve prover implementação para todos os métodos abstratos.
• Caso a subclasse não implemente os métodos abstratos da superclasse, ela deve também ser marcada como abstrata.

Em um cenário real, a implementação vai ser feita por alguém desconhecido ao usuário final. Usuários não conhecem a classe de implementação nem os detalhes da implementação.

Vamos considerar um exemplo de uso do conceito de classes abstratas.

abstract class Shape {
    public abstract void draw();
}
class Circle extends Shape{
    public void draw() {
        System.out.println("Círculo!");
    }
}
public class Test {
    public static void main(String[] args) {
        Shape circle = new Circle();
        circle.draw();
    }
}

Quando vamos querer marcar uma classe como abstrata?

1. Para forçar subclasses a implementar métodos abstratos.
2. Para impedir que existam objetos daquela classe.
3. Para manter a referência à uma classe.
4. Para manter código comum.

Interface

Uma interface é um template (ou uma "planta" de construção) de uma classe.

Uma interface é 100 abstrata. Construtores não são permitidos aqui. A interface representa o relacionamento "É UM".

Observação: interfaces apenas definem quais os métodos necessários. Não podemos manter código comum.

Uma interface possui apenas métodos abstratos, não possui métodos concretos. Os métodos da interface são, por padrão, public e abstract. Então, dentro da interface, não precisamos especificar as palavras-chaves public e abstract.

Então, quando uma classe implementa um método da interface sem especificar os modificadores de acesso daquele método, o compilador vai lançar uma exceção dizendo "Cannot reduce the visibility of the inherited method from interface" (Não é possível reduzir a visibilidade de um método herdado de uma interface). Sendo assim, o modificador de acesso de um método implementado de uma interface deve ser public.

Por padrão, as variáveis de interface são public, static e final.

Por exemplo:

interface Runnable {
    int a = 10; //equivale a: public static final int a = 10;
    void run(); //equivale a: public abstract void run();
}
public class InterfaceChecker implements Runnable{
    public static void main(String[] args) {
        Runnable.a = 5;//o valor do campo final Runnable.a não pode ser reatribuido.
    }
}

Vamos ver um exemplo que explica o conceito de interface:

interface Drawable {
    void draw();
}
class Circle implements Drawable{
    public void draw() {
        System.out.println("Círculo!");
    }
}
public class InterfaceChecker {
    public static void main(String[] args) {
        Drawable circle = new Circle();
        circle.draw();
    }
}

Métodos default e métodos estáticos nas Interfaces

Normalmente, implementamos os métodos de uma interface em classes separadas. Digamos que seja necessário adicionar um novo método à interface. Então, deveremos implementar esse método em todas as outras classes que implementam essa interface também.

Para evitar esse tipo de problema, a partir do Java, 8 foi introduzida a possibilidade de implementar métodos default e estáticos dentro de uma interface, além dos métodos abstratos.

• Método default

public interface DefaultInterface {
    void sleep();
    default void run() {
        System.out.println("Estou correndo!");
    }
}
public class InterfaceCheckers implements DefaultInterface{
    public void sleep() {
        System.out.println("Dormindo...");
    }
    public static void main(String[] args) {
        InterfaceCheckers checker = new InterfaceCheckers();
        checker.run();
        checker.sleep();
    }
}
/*
Saída:
Estou correndo!
Dormindo...
 */

• Métodos estáticos

Assim como métodos estáticos de classes, nós podemos chamá-los usando o nome da interface.

public interface DefaultInterface {
    void sleep();
    static void run() {
        System.out.println("Estou correndo!");
    }
}
public class InterfaceCheckers implements DefaultInterface{
    public void sleep() {
        System.out.println("Dormindo...");
    }
    public static void main(String[] args) {
        InterfaceCheckers checker = new InterfaceCheckers();
        DefaultInterface.run();
        checker.sleep();
    }
}
/*
Saída:
Estou correndo!
Dormindo...
 */

• Interface de marcação

São interfaces vazias. Por exemplo as interfaces Serializable, Cloneable e Remote.

public interface Serializable 
{
  //Sem campos ou métodos
}

Vantagens das interfaces

• Nos ajudam a utilizar herança múltipla no Java.
• Elas fornecem abstração.
• Elas fornecem baixo acoplamento: os objetos são independentes uns dos outros.

Quando vamos querer mudar de uma classe para uma interface?

1. Para forçar subclasses a implementar métodos abstratos.
2. Para evitar a criação de objetos dessa classe.
3. Para manter a referência à uma classe.

Observação: lembre-se de que não podemos manter código comum dentro de uma interface.

Caso você queira definir métodos que podem ser necessários e código comum, use uma classe abstrata.

Caso queira apenas definir métodos necessários, use uma interface.

Polimorfismo

Polimorfismo é a habilidade de um objeto de assumir diversas formas.

Polimorfismo em POO acontece quando uma superclasse faz referência a um objeto de uma subclasse.

Todos os objetos do Java são considerados polimórficos já que eles compartilham mais de um relacionamento É UM (pelo menos, todos os objetos vão passar no teste É UM para seu próprio tipo e para a classe Object).

Podemos acessar um objeto através de uma variável de referência. Uma variável de referência pode ser apenas de um tipo. Após declarada, o tipo da variável de referência não pode ser alterado.

Uma variável de referência pode ter uma classe ou uma interface como tipo.

Um único objeto pode ser referenciado por variáveis de referência de diversos tipos (desde que esses tipos estejam na mesma hierarquia), sendo o objeto do mesmo tipo da variável de referência ou de uma superclasse.

Sobrecarga de métodos

Se uma classe possui vários métodos, que possuem o mesmo nome mas parâmetros diferentes, isso é conhecido como sobrecarga de métodos (method overload).

Regras da sobrecarga de métodos:

1. Precisa ter uma lista de parâmetros diferente.
2. Pode possuir tipos de retorno diferentes.
3. Pode possuir modificadores de acesso diferentes.
4. Pode lançar exceções diferentes.

class JavaProgrammer{
    public void code() {
        System.out.println("Programando em C++");
    }
    public void code(String language) {
        System.out.println("Programando em " + language);
    }
}
public class MethodOverloader {
    public static void main(String[] args) {
        JavaProgrammer gosling = new JavaProgrammer();
        gosling.code();
        gosling.code("Java");
    }
}
/*
Saída:
Programando em C++
Programando em Java
 */

Observação: métodos estáticos também podem sofrer sobrecarga.

class Addition {
    public static int add(int a,int b) {
        return a+b;
    }
    public static int add(int a,int b,int c) {
        return a+b+c;
    }
}
public class PolyTest {
    public static void main(String[] args) {
        System.out.println(Addition.add(5, 5));
        System.out.println(Addition.add(2, 4, 6));
    }
}

Observação: podemos sobrecarregar o método main(), mas a JVM (Java Virtual Machine) vai chamar o método main() que recebe um array de strings como parâmetro.

public class PolyTest {
    public static void main() {
        System.out.println("main()");
    }
    public static void main(String args) {
        System.out.println("String args");
    }
    public static void main(String[] args) {
        System.out.println("String[] args");
    }
}
//Saída: String[] args

Regras a seguir para o polimorfismo

Regras de tempo de compilação

1. O compilador conhece apenas tipos de referência.
2. Ele só pode procurar métodos em tipos de referência.
3. Gera uma assinatura de método.

Regras de tempo de execução

1. Em tempo de execução, a JVM segue o tipo de tempo de execução exato (tipo de objeto) para localizar o método.
2. Deve corresponder a assinatura do método de tempo de compilação ao método na classe real do objeto.

Sobrescrita de métodos

Se uma subclasse tem o mesmo método que foi declarado na superclasse, isso é conhecido como sobrescrita de métodos (method override).

Regras da sobrescrita de métodos:

1. Deve possuir a mesma lista de parâmetros.
2. Deve possuir o mesmo tipo de retorno: embora um retorno covariante nos permita alterar o tipo de retorno do método sobrescrito.
3. Não pode possuir um modificador de acesso mais restritivo: deve possuir um modificador de acesso menos restritivo.
4. Não deve lançar uma exceção verificada (checked exception) nova ou mais ampla: pode lançar exceções verificadas mais restritas e pode lançar qualquer exceção não verificada.
5. Apenas métodos herdados podem ser sobrescritos (é necessário um relacionamento É UM).

Exemplo de sobrescrita de método:

public class Programmer {
    public void code() {
        System.out.println("Programando em C++");
    }
}
public class JavaProgrammer extends Programmer{
    public void code() {
        System.out.println("Programando em Java");
    }
}
public class MethodOverridder {
    public static void main(String[] args) {
        Programmer ben = new JavaProgrammer();
        ben.code();
    }
}
/*
Saída:
Programando em Java
 */

Observação: métodos estáticos não podem ser sobrescritos porque métodos são sobrescritos em tempo de execução (runtime). Métodos estáticos são associados com classes, enquanto métodos de instância são associados com objetos. Então, em Java, o método main() não pode ser sobrescrito.

Observação: construtores podem ser sobrecarregados mas não podem ser sobrescritos.

Tipos de objeto e tipos de referência

class Person{
    void eat() {
        System.out.println("A pessoa está comendo");
    }
}
class Student extends Person{
    void study() {
        System.out.println("O estudante está estudando");
    }
}
public class InheritanceChecker {
    public static void main(String[] args) {
        Person alex = new Person();//New Person "É UMA" Person
        alex.eat();
        Student jane = new Student();//New Student "É UM" Student
        jane.eat();
        jane.study();
        Person mary = new Student();//New Student "É UM" Person
        mary.eat();
        //Student chris = new Person(); //New Person não É UM Student.
    }
}

Em Person mary = new Student(); esse modo de criar o objeto está correto.

mary é uma variável de referência do tipo Person e new Student() criará um novo objeto do tipo Student.

mary não pode acessar study() em tempo de compilação porque o compilador conhece apenas o tipo de referência. Já que study() não existe na classe do tipo de referência, não é possível acessá-lo. Em tempo de execução, no entanto, mary será do tipo Student (tipo de tempo de execução/tipo de objeto).

Veja esse artigo (texto em inglês) para entender melhor sobre tipos de tempo de execução.

Neste caso, podemos convencer o compilador dizendo "em tempo de execução, mary será do tipo Student, então permita-me chamar o método study()". Como podemos convencer o compilador a fazer isso? Aqui é onde usaremos o casting.

Podemos converter mary ao tipo Student em tempo de compilação e chamar study() se utilizarmos o casting.

((Student)mary).study();

Aprenderemos sobre casting a seguir.

Casting de tipos de objeto

O casting no Java é classificado em dois tipos:

1. Casting de ampliação (widening casting, implícito): conversão automática de tipos.
2. Casting de restrição (narrowing casting, explícito): precisa de uma conversão explícita.

Com primitivos, long é um tipo mais abrangente que int. Assim como ocorre com os objetos, a classe mãe é mais abrangente que a classe filha.

A variável de referência apenas faz referência a um objeto. Utilizar casting em uma variável de referência não muda o tipo do objeto em memória, mas rotula o mesmo objeto de uma outra maneira para se ter acesso aos membros de instância.

I. Widening casting (casting de ampliação)

Superclass superRef = new Subclass();

II. Narrowing casting (casting de restrição)

Subclass ref = (Subclass) superRef;

Temos que tomar cuidado quando utilizamos um casting restritivo. Quando utilizamos o casting restritivo, convencemos o compilador a compilar sem erros. Caso estejamos errados, receberemos um erro em tempo de execução (geralmente, ClassCastException).

Para executar um casting restritivo corretamente, usamos o operador instanceof. Com ele, podemos verificar se o relacionamento é do tipo É UM.

class A {
    public void display(){
        System.out.println("Class A");
    }
}

class B extends A{
    public void display(){
        System.out.println("Class B");
    }
}

public class Test {
    public static void main(String[] args) {
        A objA = new B();
        if(objA instanceof B){
            ((B)objA).display();
        }
    }
}
/**
 * Saída: Class B
 */

Como eu disse anteriormente, devemos sempre nos lembrar de uma coisa muito importante quando criamos um objeto utilizando a palavra-chave new: o tipo de referência deve ser do mesmo tipo ou de um supertipo do objeto sendo criado.

Conclusão

Obrigado por ler este artigo. Espero que ele tenha ajudado.

Recomendo fortemente a leitura de mais artigos relacionados à POO.

Confira, também, a série original de artigos do autor no medium: Princípios de orientação a objetos em Java (texto em inglês).

Sonhos não são o que você vê quando está dormindo. Eles são o que não deixa você dormir.
― A P J Abdul Kalam, Asas de fogo: autobiografia

Obrigado.

Bons estudos!

O JavaScript é uma linguagem multiparadigma, ou seja, pode ser escrita seguindo diferentes paradigmas de programação. Um paradigma de programação é essencialmente um conjunto de regras que você segue ao escrever código, para ajudá-lo a resolver um problema específico.

No caso da Programação Orientada a Objetos, temos quatro pilares. Eles são princípios de design de software para ajudá-lo a escrever um código limpo e orientado a objetos.

Os quatro pilares da programação orientada a objetos são:

• Abstração
• Encapsulamento
• Herança
• Polimorfismo

Vamos dar uma olhada em cada um deles.

Abstração na Programação Orientada a Objetos

Abstrair algo significa esconder os detalhes da implementação dentro de algo – às vezes um protótipo, às vezes em uma função. Portanto, quando você chama a função, não precisa entender exatamente o que ela está fazendo.

Um exemplo claro do conceito de abstração seria o funcionamento de um carro. Quando acionamos ele para ligar, não precisamos saber quais passos ele faz para colocar o motor em funcionamento. Quando acionamos o freio, não precisamos saber todos os mecanismos que são acionados para fazer o carro frear. Apenas sabemos o que cada objeto ou função do carro produz como resultado.

Voltando para a codificação, se você tivesse que entender cada função em uma base de código grande, você nunca codificaria nada, pois, levaria meses para terminar de ler e entender a lógica de tudo isso.

Contudo, abstraindo certos detalhes, você é capaz de criar uma base de código reutilizável, simples de entender e facilmente alterável. Deixe-me lhe dar um exemplo:

function hitAPI(tipo){
	if (type instanceof CargaInicial) {
		// Exemplo de implementação
	} else if (type instanceof NavBar) {
		// Exemplo de implementação
	} else {
		// Exemplo de implementação
	}
}

Você percebeu nesse exemplo que você precisa especificar todos os passos da implementação de cada caso de uso?

Para cada novo tipo que você precisar acessar nessa função, você precisará de um novo bloco if e de seu próprio código personalizado. Isso não é um código abstraído, pois você precisa se preocupar com o passo a passo de cada implementação. Ele também não é reutilizável, sendo um pesadelo na hora de fazer a manutenção desse código.

Bom, e que tal o código abaixo?

hitApi('www.kealanparr.com', HTTPMethod.Get)

Desse modo, você simplesmente passou um URL para sua função e qual método HTTP deseja usar nela e está feito.

Você não precisa mais se preocupar com o funcionamento da função. Isso ajuda muito na reutilização de código, além de tornar seu código muito mais sustentável.

É disso que trata a Abstração. Encontrar coisas semelhantes em seu código e fornecer uma função ou objeto genérico e servir em vários lugares/com vários interesses.

Um bom exemplo para entender a Abstração é: imagine se você estivesse criando uma máquina para fazer café para seus usuários. Pode haver duas abordagens:

Como criá-la com abstração

• Ter um botão escrito "Fazer café"

Como criá-la sem abstração

• Ter um botão escrito "Adicionar água fria à chaleira"
• Ter um botão escrito "Ferver a água"
• Ter um botão escrito "Adicionar uma cápsula de café"
• Ter um botão escrito "Passar a água pela cápsula de café"
• Além de vários outros botões para completar o processo

É um exemplo muito simples, mas a primeira abordagem abstrai toda a lógica da máquina. A segunda abordagem força o usuário a entender como fazer café e essencialmente fazer o seu próprio.

O próximo pilar é o de Encapsulamento. Mostrarei uma forma de aplicarmos a Abstração, usando-o.

Encapsulamento na Programação Orientada a Objetos

A definição de encapsulamento é "a ação de colocar algo dentro ou como se estivesse em uma cápsula". Remover o acesso a partes do seu código e tornar as coisas privadas é exatamente o que o Encapsulamento faz (muitas vezes, as pessoas se referem a ele como "ocultação de dados").

Encapsulamento significa que o código de cada objeto deve controlar apenas seu próprio estado.  Se você não sabe o que é o estado de um objeto, vamos fazer a seguinte analogia:

Sabe aquele retrato de família, em que você era bebê ainda? Ele é um registro do estado "instantâneo" em que você estava naquele exato momento. De lá pra cá muita coisa mudou, e se hoje você tirar uma nova foto, seu estado já não é o mesmo que aquele. Aquilo que você fez durante o tempo com sua vida, transformou você. A mesma coisa ocorre com o objeto.

O estado é o "instantâneo" atual do objeto. Todas as chaves e métodos (funções) de um objeto são suas propriedades. Se você redefinir ou excluir uma chave, por exemplo, estará alterando o seu estado.

Por isso, é importante limitar o acesso de quais partes do código podem ser acessadas. Caso não sejam necessárias, torne as coisas mais inacessíveis para não possibilitar efeitos colaterais no estado do objeto.

Propriedades privadas são obtidas em JavaScript usando closures. Segue um exemplo abaixo:

var Cachorro = (function () {

	// Privado
	var executar = function () {
		// Implementação de executar
	};
    
	// Privado
	var raca = "Dálmata"
    
	// Público
	var nome = "Rex";

	// Público
	var fazerBarulho = function () {
 		return 'Au au!';
	};

 	return {
		fazerBarulho: fazerBarulho,
		nome: nome
 	};
})();

A primeira coisa que fizemos foi criar uma função que é chamada imediatamente (Immediately Invoked Function Expression, ou de forma abreviada, IIFE). Ela criou um objeto que qualquer um pode acessar, mas escondeu alguns detalhes dentro dela. Você não pode chamar o método executar e nem a chave raca, pois não o expomos no objeto final com o retorno.

Esse padrão específico acima é chamado de Revealing Module Pattern (Padrão do Módulo de Revelação), mas é apenas um exemplo de como você pode obter o encapsulamento.

Vamos, no entanto, focar mais na ideia de Encapsulamento (já que agora é mais importante entender o Encapsulamento como um todo, do que apenas aprender um padrão dele).

Concentre-se mais em como você pode tornar seus dados e código privados e separá-los. Modularizar e ter responsabilidades claras é a chave para a Orientação a Objetos.

Por que devemos preferir a privacidade? Por que não ter tudo acessível globalmente?

• Muitos bits de código não relacionados se tornarão dependentes/acoplados uns dos outros por meio de variáveis globais.
• Você provavelmente substituirá as variáveis ​​se o nome delas forem reutilizados, o que pode levar a erros ou comportamentos imprevisíveis.
• Você provavelmente terminará com um código espaguete – código que é difícil de raciocinar e entender o que está lendo e gravando suas variáveis​, ou onde muda o estado de cada uma.

O encapsulamento pode ser aplicado separando longas linhas de código em funções menores e separadas. É recomendado também separar essas funções em módulos. O objetivo é sempre escondermos os dados em um lugar em que nada mais precise de acesso e expormos os dados de modo claro onde for necessário.

O encapsulamento metaforicamente seria uma casca de noz. Vinculando seus dados a algo, seja uma classe, objeto, módulo ou função, e fazendo o possível para mantê-lo o mais privado possível.

Herança na Programação Orientada a Objetos

A herança permite que um objeto adquira as propriedades e métodos de outro objeto. Em JavaScript, isso é feito por Prototypal Inheritance (ou herança prototípica, em português).

A reutilização é o principal benefício aqui. Sabemos que às vezes a mesma coisa precisa ser feita em vários lugares e sempre de forma igual, exceto em alguma pequena parte. Esse é um problema que a herança pode resolver.

Sempre que usamos herança, tentamos fazer com que o pai e o filho tenham alta coesão. Coesão é o quanto seu código está relacionado. Por exemplo, o tipo Passaro consegue ser estendido do tipo MotorADiesel? Não, certo?

Por isso, mantenha sua herança simples de entender e previsível. Não faça heranças completamente não relacionadas somente porque há um método ou uma propriedade de que você precisa. A herança não resolve bem esse problema específico.

Ao usar herança, ela precisa ter a maior parte das funcionalidades (você nem sempre precisa ter absolutamente tudo).

Nós, desenvolvedores, temos um princípio chamado de princípio de substituição de Liskov. Ele afirma que, se conseguimos usar uma classe pai (vamos chamá-la de TipoPai) em qualquer lugar em que usamos uma classe filho (vamos chamá-la de TipoFilho) – e se TipoFilho é uma herança de TipoPai, então passamos no teste.

A principal razão pela qual se falha nesse teste é se TipoFilho estiver removendo coisas do pai. Se TipoFilho remove métodos herdados do pai, isso gera diversos TypeError, onde haverá coisas que estarão indefinidas e que estamos esperando que não sejam.

A "cadeia de herança" é o termo usado para descrever esse fluxo de herança do protótipo do objeto base (aquele do qual todos os outros herdam) até o "final" da cadeia de herança (o último tipo que está herdando – Cachorro, no exemplo acima).

Faça o seu melhor para manter suas cadeias de herança limpas e sensatas. Você pode facilmente acabar programando um antipadrão (antiPattern) ao usar Herança (chamado de antipadrão de base frágil). Isso acontece quando seus protótipos base são considerados "frágeis" – aqueles em que, se você faz uma alteração "segura" no objeto base, todos os seus filhos começam a quebrar.

Polimorfismo na Programação Orientada a Objetos

Polimorfismo significa "a condição de ocorrer de várias formas diferentes". É exatamente com isso que o quarto e último pilar está preocupado – que tipos nas mesmas cadeias de herança sejam capazes de fazer coisas diferentes.

Se você usou a herança corretamente, agora pode usar tanto os pais de maneira confiável como seus filhos. Quando dois tipos compartilham uma cadeia de herança, eles podem ser usados ​​alternadamente sem erros ou declarações em seu código.

A partir do último diagrama, podemos ter um protótipo base chamado Animal que define fazerBarulho. Em seguida, cada tipo que se estende desse protótipo pode substituí-lo para fazer seu próprio trabalho personalizado. Algo assim:

// Vamos configurar um exemplo de Animal e Cachorro
function Animal(){}
function Cachorro(){}

Animal.prototype.fazerBarulho = function(){
	console.log("Barulho base");
};

// A maioria dos animais que programamos tem 4 pernas. Isso pode ser substituído se necessário
Animal.prototype.pernas = 4;

Cachorro.prototype = new Animal();

Cachorro.prototype.fazerBarulho = function(){	console.log("Au au");  
};

var animal = new Animal();
var cachorro = new Cachorro();

animal.fazerBarulho();     // Barulho base
cachorro.fazerBarulho();   // Au au - isso foi substituído
cachorro.pernas;           // 4! Isso foi herdado

Aqui, a classe Cachorro estende Animal e pode fazer uso da propriedade padrão pernas. Porém, ela também é capaz de fazer sua própria implementação de fazer seu próprio barulho.

O verdadeiro poder do polimorfismo é poder compartilhar comportamentos e permitir substituições personalizadas.

Conclusão

Espero que isso tenha explicado quais são os quatro pilares da programação orientada a objetos e como eles levam a um código mais limpo e robusto.

Se você gostou desse artigo e quiser ver mais, eu compartilho meus textos no Twitter.

Os princípios SOLID são cinco princípios do design de classes orientado a objetos. Eles são um conjunto de regras e práticas recomendadas a serem seguidas na criação de uma estrutura de classe.

Esses cinco princípios nos ajudam a entender a necessidade de determinados padrões de projetos e arquitetura de software em geral. Por isso, creio que seja um tópico que todo desenvolvedor deveria conhecer.

Este artigo ensinará a você tudo o que você precisa saber para aplicar os princípios SOLID aos seus projetos.

Vamos começar dando uma olhada na história desse termo. Em seguida, vamos nos aprofundar nos detalhes – os porquês e modos de usar cada princípio – criando um design de classe e melhorando-o passo a passo.

Pegue, então, uma xícara de café ou de chá e vamos nessa!

Histórico

Os princípios SOLID foram apresentados pela primeira vez pelo famoso cientista da computação Robert J. Martin (também conhecido como Uncle Bob) em seu trabalho (texto em inglês) lançado no ano 2000. A abreviação SOLID, no entanto, foi apresentada mais tarde, por Michael Feathers.

Uncle Bob também é o autor de dois livros muito conhecidos, Código limpo e Arquitetura limpa, e um dos participantes da "Aliança Agile" (texto em inglês).

Portanto, não é de surpreender que todos esses conceitos sobre código limpo, arquitetura orientada a objetos e padrões de projetos estejam, de algum modo, conectados e complementem-se.

Todos eles servem ao mesmo propósito:

"Criar código compreensível, legível e testável no qual diversos desenvolvedores possam trabalhar de modo colaborativo."

Vamos examinar cada princípio, um por um. Seguindo a sequência da abreviação SOLID, temos:

• O Single Responsibility Principle (Princípio da responsabilidade única)
• O Open-Closed Principle (Princípio aberto/fechado)
• O Liskov Substitution Principle (Princípio da substituição de Liskov)
• O Interface Segregation Principle (Princípio da segregação da interface)
• O Dependency Inversion Principle (Princípio da inversão da dependência)

Princípio da responsabilidade única

O princípio da responsabilidade única declara que uma classe deve fazer apenas uma coisa e, portanto, deve ter apenas uma razão para ser modificada.

Vamos declarar esse princípio de um modo mais técnico: somente uma alteração em potencial (lógica do banco de dados, lógica de registro e assim por diante) na especificação do software pode ser capaz de alterar a especificação da classe.

Isso significa que, se uma classe for um contêiner de dados, como uma classe Livro ou uma classe Estudante, e se ela tiver campos relativos àquela entidade, ela deve ser alterada apenas quando alterarmos o modelo de dados.

Seguir o princípio da responsabilidade única é importante. Para começar, porque muitas equipes diferentes podem trabalhar no mesmo projeto e editar a mesma classe por motivos diferentes, o que poderia ocasionar incompatibilidade entre os módulos.

Em segundo lugar, isso torna mais fácil o controle de versão. Por exemplo, digamos que temos uma classe persistente que trata das operações do banco de dados, e vemos que ocorreu um commit no GitHub com uma mudança naquele arquivo. Seguindo o princípio, saberemos que essa mudança está relacionada com questões de armazenamento ou relacionadas ao banco de dados.

Conflitos de merge são um outro exemplo. Eles aparecem quando equipes diferentes alteram o mesmo arquivo. Se, no entanto, seguirmos o princípio da responsabilidade única, menos conflitos surgirão – os arquivos terão um único motivo para mudar e os conflitos que existirem serão muito mais fáceis de resolver.

Armadilhas comuns e antipadrões

Nesta seção, veremos alguns dos erros comuns que violam o princípio da responsabilidade única. Em seguida, falaremos sobre algumas formas de consertarmos esses erros.

Examinaremos o código de um programa simples de faturamento de uma livraria como exemplo. Vamos começar definindo a classe Livro, que será usada na fatura.

class Livro {
	String nome;
	String nomeAutor;
	int ano;
	int preco;
	String isbn;

	public Livro(String nome, String nomeAutor, int ano, int preco, String isbn) {
		this.nome = nome;
		this.nomeAutor = nomeAutor;
		this.ano = ano;
        this.preco = preco;
		this.isbn = isbn;
	}
}

Essa é uma classe Livro simples com alguns campos, nada demais. Não estou criando campos privados para que não precisemos lidar com getters e setters e possamos prestar atenção na lógica.

Agora, vamos criar a classe Fatura, que terá a lógica para o faturamento e o cálculo do preço total. Por agora, vamos considerar que nossa loja vende apenas livros.

public class Fatura {

	private Livro livro;
	private int quantidade;
	private double porcDesconto;
	private double porcImposto;
	private double total;

	public Fatura(Livro livro, int quantidade, double porcDesconto, double porcImposto) {
		this.livro = livro;
		this.quantidade = quantidade;
		this.porcDesconto = porcDesconto;
		this.porcImposto = porcImposto;
		this.total = this.calcularTotal();
	}

	public double calcularTotal() {
	        double preco = ((livro.preco - livro.preco * porcDesconto) * this.quantidade);

		double precoComImposto = preco * (1 + porcImposto);

		return precoComImposto;
	}

	public void imprimirFatura() {
            System.out.println(quantidade + "x " + livro.nome + " " +          livro.preco + "$");
            System.out.println("Porcentagem de desconto: " + porcDesconto);
            System.out.println("Procentagem de imposto: " + porcImposto);
            System.out.println("Total: " + total);
	}

        public void salvarParaArquivo(String nomeArquivo) {
	// Cria um arquivo com o nome especificado e salva a fatura
	}

}

Essa é a nossa classe Fatura. Ela também contém alguns campos relativos ao faturamento e 3 métodos:

• Método calcularTotal, que calcula o preço total,
• Método imprimirFatura, que imprime a fatura no console e
• Método salvarParaArquivo, responsável por salvar a fatura em um arquivo.

Dedique uns instantes a entender o que há de errado com o design dessa classe antes de ler o próximo parágrafo.

O que está acontecendo aqui? nossa classe viola o princípio da responsabilidade única de diversas maneiras.

A primeira violação está no método imprimirFatura, que tem nossa lógica de impressão. De acordo com o princípio da responsabilidade única, nossa classe deve ter apenas uma única razão para ser alterada. Essa razão deve ser uma mudança no cálculo da fatura para nossa classes.

Nessa arquitetura, no entanto, se quiséssemos mudar o formato de impressão, precisaríamos mudar a classe. É por isso que não devemos misturar a lógica de impressão com a lógica de negócios na mesma classe.

Temos um outro método que viola o princípio da responsabilidade única em nossa classe: o método salvarParaArquivo. É um erro muito comum misturar a lógica da persistência com a lógica dos negócios.

Não pense em termos de salvar um arquivo – poderíamos estar falando em salvar em um banco de dados, fazer uma chamada à API ou alguma outra coisa relacionada à persistência.

Bem, como podemos, então, consertar esse problema?

Podemos criar novas classes para as lógicas de impressão e persistência, para não precisarmos mais modificar a classe Fatura para esses fins.

Criamos 2 classes, ImpressaoDeFatura e PersistenciaDaFatura, e movemos os métodos.

public class ImpressaoDeFatura {
    private Fatura fatura;

    public ImpressaoDeFatura(Fatura fatura) {
        this.fatura = fatura;
    }
    
    public void imprimir() {
            System.out.println(fatura.quantidade + "x " + fatura.livro.nome + " " + fatura.livro.preco + "$");
            System.out.println("Porcentagem de desconto: " + fatura.porcDesconto);
            System.out.println("Procentagem de imposto: " + fatura.porcImposto);
            System.out.println("Total: " + fatura.total);
	}
}

public class PersistenciaDaFatura {
    Fatura fatura;

    public PersistenciaDaFatura(Fatura fatura) {
        this.fatura = fatura;
    }

    public void salvarParaArquivo(String nomeArquivo) {
		// Cria um arquivo com o nome especificado e salva a fatura
	}
}

Agora, nossa estrutura de classe obedece ao princípio de responsabilidade única e cada classe é responsável por um aspecto de nossa aplicação. Ótimo!

Princípio aberto/fechado

O princípio de aberto/fechado diz que as classes devem estar abertas para extensão, mas fechadas para modificação.

Modificação significa alterar o código de uma classe existente, enquanto extensão significa adicionar novas funcionalidades.

O que esse princípio representa, portanto é que: devemos poder adicionar novas funcionalidades sem tocar no código existente para a classe. Isso se dá porque, sempre que modificamos o código existente, estamos nos arriscando a criar bugs em potencial. Assim, devemos evitar de tocar em código em produção testado e confiável (em grande parte), se possível.

No entanto, como podemos adicionar novas funcionalidades sem tocar na classe? Geralmente, isso é feito com o auxílio de interfaces e classes abstratas.

Agora que já tratamos do básico sobre o princípio, vamos aplicar isso ao nosso programa de faturamento.

Digamos que nosso chefe tenha nos dito que deseja que as faturas sejam salvas em um banco de dados onde possamos fazer pesquisas facilmente. Para nós, isso seria fácil, então pedimos pouco tempo!

Criamos o banco de dados, fazemos a conexão a ele e adicionamos um método de salvamento em nossa classe PersistenciaDaFatura:

public class PersistenciaDaFatura {
    Fatura fatura;

    public PersistenciaDaFatura(Fatura fatura) {
        this.fatura = fatura;
    }

    public void salvarParaArquivo(String nomeArquivo) {
		// Cria um arquivo com o nome especificado e salva a fatura
	}

    public void salvarParaBancoDeDados() {
        // Salva a fatura em um banco de dados
    }
}

Infelizmente para nós, os desenvolvedores preguiçosos da livraria, não criamos as classes de modo que pudessem ser extensíveis no futuro. Assim, para adicionar esse recurso, modificamos a classe PersistenciaDaFatura.

Se nossa criação das classes tivesse obedecido o princípio de aberto/fechado, não precisaríamos alterar essa classe.

Então, por sermos os desenvolvedores preguiçosos, porém inteligentes, da livraria, percebemos o problema do design e decidimos refatorar o código para que possamos atender àquele princípio.

interface PersistenciaDaFatura {

    public void salvar(Fatura fatura);
}

Mudamos o tipo de PersistenciaDaFatura para Interface e adicionamos um método de salvamento. Cada classe de persistência implementará esse método.

public class PersistenciaEmBD implements PersistenciaDaFatura {

    @Override
    public void salvar(Fatura fatura) {
        // Salvar no BD
    }
}

public class PersistenciaEmArquivo implements PersistenciaDaFatura {

    @Override
    public void salvar(Fatura fatura) {
        // Salvar em arquivo
    }
}

Desse modo, nossa estrutura de classe terá essa aparência:

Agora, nossa lógica de persistência é facilmente extensível. Se nosso chefe nos pedir outro banco de dados e tiver dois tipos diferentes de BD, como o MySQL e o MongoDB, podemos fazer isso facilmente.

Você pode achar que simplesmente criaríamos diversas classes sem uma interface e adicionaríamos um método de salvamento a cada uma delas.

Digamos, porém, que tenhamos estendido nossa aplicação e que tenhamos diversas classes de persistência, como PersistenciaDaFatura, PersistenciaDeLivro e criamos uma classe GerenteDePersistencia que gere todas as classes de persistência:

public class GerenteDePersistencia {
    PersistenciaDaFatura persistenciaDaFatura;
    PersistenciaDeLivro persistenciaDeLivro;
    
    public GerenteDePersistencia(PersistenciaDaFatura persistenciaDaFatura,
                               PersistenciaDeLivro persistenciaDeLivro) {
        this.persistenciaDaFatura = persistenciaDaFatura;
        this.persistenciaDeLivro = persistenciaDeLivro;
    }
}

Agora, podemos passar qualquer classe que implemente a interface PersistenciaDaFatura para essa classe com o auxílio do polimorfismo. Essa é a flexibilidade fornecida pelas interfaces.

Princípio da substituição de Liskov

O princípio da substituição de Liskov declara que as subclasses devem ser substituíveis por suas classes de base.

Isso quer dizer que, se a classe B for uma subclasse da classe A, devemos poder passar um objeto da classe B para qualquer método que espere um objeto da classe A e o método não deverá produzir resultados estranhos, nesse caso.

Esse é o comportamento esperado, pois, quando usamos a herança, levamos em conta que a classe filha herda tudo o que a superclasse tem. A classe filha estende o comportamento, mas nunca o reduz.

Portanto, quando uma classe não obedece esse princípio, isso causa alguns bugs ruins e difíceis de detectar.

O princípio de Liskov é fácil de entender, mas difícil de detectar no código. Vamos dar uma olhada em um exemplo para entender melhor.

class Retangulo {
	protected int largura, altura;

	public Retangulo() {
	}

	public Retangulo(int largura, int altura) {
		this.largura = largura;
		this.altura = altura;
	}

	public int getLargura() {
		return largura;
	}

	public void setLargura(int largura) {
		this.largura = largura;
	}

	public int getAltura() {
		return altura;
	}

	public void setAltura(int altura) {
		this.altura = altura;
	}

	public int getArea() {
		return largura * altura;
	}
}

Temos uma classe Retangulo simples, e uma função getArea que retorna a área do retângulo.

Agora, decidimos criar outra classe para os quadrados. Como você deve saber, um quadrado é apenas um tipo de retângulo onde a largura é igual à altura.

class Quadrado extends Retangulo {
	public Quadrado() {}

	public Quadrado(int tamanho) {
		largura = altura = tamanho;
	}

	@Override
	public void setLargura(int largura) {
		super.setLargura(largura);
		super.setAltura(largura);
	}

	@Override
	public void setAltura(int altura) {
		super.setAltura(altura);
		super.setLargura(altura);
	}
}

Nossa classe Quadrado estende a classe Retangulo. Definimos que altura e largura têm o mesmo valor no construtor, mas não queremos que o usuário (aquele que usar nossa classe em seu código) altere altura e largura de maneira a poder violar a propriedade do quadrado.

Assim, sobrescrevemos os setters de ambas as propriedades sempre que uma delas é alterada. Ao fazer isso, no entanto, acabamos de violar o princípio da substituição de Liskov.

Vamos criar uma classe main para realizar testes na função getArea.

class Test {

   static void getAreaTeste(Retangulo r) {
      int largura = r.getLargura();
      r.setAltura(10);
      System.out.println("Área esperada de " + (largura * 10) + ", obteve " + r.getArea());
   }

   public static void main(String[] args) {
      Retangulo rc = new Retangulo(2, 3);
      getAreaTeste(rc);

      Retangulo sq = new Quadrado();
      sq.setLargura(5);
      getAreaTeste(sq);
   }
}

O testador da equipe acaba de aparecer com a função de teste getAreaTeste e conta que a função getArea não passa no teste para objetos quadrados.

No primeiro teste, criamos um retângulo onde a largura é 2 e a altura é 3 e chamamos getAreaTeste. O resultado é 20, como esperávamos, mas algo dá errado ao passar o quadrado. Isso ocorre por que chamamos a função setAltura no teste e ela está definindo a largura também. Isso resulta em um retorno inesperado.

Princípio da segregação da interface

Segregação quer dizer manter as coisas separadas. O princípio da segregação da interface tem a ver com separar as interfaces.

O princípio declara que muitas interfaces específicas do cliente são melhores que uma interface de propósito geral. Os clientes não devem ser forçados a implementar uma função que não necessitam.

Esse é um princípio simples de entender e de aplicar. Vamos ver um exemplo.

public interface Estacionamento {

	void estacionarCarro();	// Diminuir contagem de vagas em 1
	void sairDaVagaComCarro(); // Aumentar contagem de vagas em 1
	void getCapacidade();	// Retornar capacidade de carros
	double calcularTaxa(Carro carro); // Retornar o preço com base no número de horas
	void pagar(Carro carro);
}

class Carro {

}

Modelamos um estacionamento bem simplificado. É o tipo de estacionamento onde você paga um valor por hora. Imagine, agora, que queremos implementar um estacionamento gratuito.

public class EstacionamentoGratuito implements Estacionamento {

	@Override
	public void estacionarCarro() {
		
	}

	@Override
	public void sairDaVagaComCarro() {

	}

	@Override
	public void getCapacidade() {

	}

	@Override
	public double calcularTaxa(Carro carro) {
		return 0;
	}

	@Override
	public void pagar(Carro carro) {
		throw new Exception("Estacionamento gratuito");
	}
}

Nossa interface de estacionamento era composta de 2 coisas: lógica relacionada ao estacionamento (estacionar, sair da vaga com o carro, obter a capacidade) e lógica relacionada ao pagamento.

O problema é ser muito específica. Por causa disso, nossa classe EstacionamentoGratuito foi forçada a implementar métodos relacionados ao pagamento que são irrelevantes. Vamos separar o segregar as interfaces.

Você, agora, separou os estacionamentos. Com esse novo modelo, podemos até ir mais longe e dividir EstacionamentoPago para dar suporte a tipos diferentes de pagamento.

Agora, nosso modelo é muito mais flexível, extensível e os clientes não precisam implementar lógica irrelevante, pois fornecemos somente funcionalidade relacionada ao estacionamento na interface de estacionamento.

Princípio da inversão da dependência

O princípio da inversão da dependência declara que nossas classes devem depender de interfaces ou de classes abstratas em vez de classes concretas e de funções.

Neste artigo (2000, texto em inglês), Uncle Bob resume esse princípio da seguinte maneira:

"Se o princípio de aberto/fechado declara o objetivo da arquitetura orientada a objetos, o princípio de inversão da dependência declara seu mecanismo principal".

Esses dois princípios, de fato, estão relacionados. Aplicamos esse padrão anteriormente enquanto discutíamos o princípio de aberto/fechado.

Queremos que nossas classes estejam abertas para extensão, por isso reorganizamos nossas dependências para que dependam de interfaces em vez de classes concretas. Nossa classe GerenteDePersistencia depende de PersistenciaDaFatura em vez de classes que implementam aquela interface.

Conclusão

Neste artigo, começamos com a história dos princípios SOLID, depois tentamos chegar a um entendimento claro dos motivos e formas de implementar cada princípio. Nós, inclusive, refatoramos uma aplicação de faturamento simples para que ela obedecesse aos princípios SOLID.

Gostaria de agradecer a você pode usar de seu tempo para a leitura deste artigo na íntegra e espero que os conceitos apresentados tenham ficado claros.

Sugiro levar esses princípios em consideração sempre que criar, escrever e refatorar seu código, de modo que seu código seja muito mais limpo, extensível e testável.

Se estiver interessado em ler mais artigos a esse respeito, você pode assinar a lista de e-mails do blog do autor (textos em inglês) para ser notificado sempre que ele publicar um artigo novo.