Por que eu devo ler este artigo:Neste artigo serão apresentados alguns dos erros mais comuns realizados por desenvolvedores Java, principalmente por não compreenderem perfeitamente os fundamentos da própria Orientação a Objetos.

Exemplos mostram como identificar trechos de código com alto acoplamento e como isso prejudica a manutenção e a extensão de um sistema OO.

Além disso, os propósitos de conceitos como Encapsulamento, Herança e Polimorfismo, bem como o padrão Modelo-Visão-Controle, são revisitados, mostrando como utilizá-los corretamente para deixar o projeto mais rico e facilitar o reuso de classes.

Quando ouvimos falar em Java como linguagem de programação, a expressão “Orientação a Objetos” logo vem à cabeça. Apesar de ser um dos primeiros temas a estudar quando aprende-se a programar em Java, muitas pessoas o negligenciam achando, por exemplo, que Encapsulamento se reduz a utilizar métodos do tipo getXXX() e setXXX() em suas classes quando, na verdade, estes tipos de métodos devem ser evitados a qualquer custo justamente por ferir este princípio fundamental.

Outros exibem orgulhosos a “árvore genealógica” das classes que compõem o seu sistema, sem saber que o esforço para estender e manter o código funcionando corretamente aumenta proporcionalmente com o tamanho da “árvore”.

Diante deste cenário, este artigo tem como objetivo principal revisitar os conceitos fundamentais da Orientação a Objetos: Encapsulamento, Herança e Polimorfismo.

Ao mesmo tempo, alguns padrões GRASP (General Responsibility Assignment Software Patterns) são introduzidos. Estes padrões, ao contrário dos Padrões de Projeto escritos pela “Gangue dos Quatro”, possuem o objetivo de facilitar o entendimento sobre quais são as responsabilidades de cada classe em um sistema.

Apesar de muitos desenvolvedores considerarem estes padrões mais básicos, sua importância é enorme e não deve ser menosprezada pois, nem mesmo uma abordagem ágil com todas as suas técnicas que preveem suporte a alterações frequentes no código, é capaz de diminuir os impactos negativos de um código mal escrito.

Nota: Durante o desenvolvimento de softwares orientados a objetos, existem alguns problemas que são recorrentes, ou seja, aparecem várias vezes e em diferentes situações, às vezes até “mascarados” como problemas diferentes. Desta forma, há algum tempo, quatro dos grandes nomes da comunidade de orientação a objetos (Erich Gamma, John Vlissides, Ralph Johnson e Richard Helm) perceberam esse padrão e começaram a catalogar as soluções utilizadas para resolver estes problemas, dando nomes a elas e descrevendo como e quando utilizá-las.

Posteriormente, estas soluções foram compartilhadas através do livro “Padrões de Projeto: soluções reutilizáveis de softwares orientados a objetos” e seus autores passaram a ser conhecidos como a “Gangue dos Quatro”. O livro é uma referência até hoje para aqueles que querem se aprofundar no estudo da orientação a objetos.

Como exemplo, considere as Listagens 1, 2 e 3, onde são exibidas as classes de um sistema bancário simples que permite a criação de agências. O código foi propositalmente escrito com a classe que representa o domínio (AgenciaBancaria) contendo somente métodos getXXX() e setXXX(), funcionando como um recipiente de dados.

O padrão arquitetural Modelo-Visão-Controle (outro conceito mal compreendido por muitos desenvolvedores) foi utilizado como forma de separar as responsabilidades envolvidas em cada classe. A Figura 1 mostra o diagrama de classes deste sistema.

Listagem 1. Classe que representa o domínio do problema no sistema bancário.


public class AgenciaBancaria {
   private String codigo;
   private List<ContaBancaria> contas = new LinkedList<>();
   public List<ContaBancaria> getContas() {
         return contas;
   }
   public void setContas(List<ContaBancaria> contas) {
         this.contas = contas;
   }
   public String getCodigo() {
         return codigo;
   }
   public void setCodigo(String codigo) {
         this.codigo = codigo;
   }
}
    

Listagem 2. Classe que representa a lógica de negócio no sistema bancário.


public class ControladorAgencia {
   private  ... 

Fim do trecho gratuito • continue abaixo
CONTEÚDO EXCLUSIVO

Desbloqueie toda a DevMedia

  • +2000 artigos e vídeos
  • +40 trilhas sobre Front-end, Back-end, IA e muito mais
  • +5000 exercícios práticos
  • Mentorias ao vivo individuais
até 50% OFF
A partir de
R$ 69 /mês
Assinar agora