Construir um software que realmente seja orientado a objetos, não é uma tarefa fácil. Utilizar OO de verdade, exige maturidade, prática e entender seus princípios, para que se possa utilizar realmente todos os benefícios da orientação a objetos. O que geralmente acontece, é que os desenvolvedores se preocupam somente o que é necessário para fazer o software funcionar, e não considera questões como manutenção, construir algo que seja fácil de modificar e que siga realmente a Orientação a objetos de fato. Hoje iremos começar a entender os princípios que são básicos, porém muito importantes para se construir um software que realmente seja OO; ter decorado conceitos como herança, encapsulamento e polimorfismo , por exemplo não bastam, é preciso entender mais profundamente para ter algo de qualidade.
O poder das Abstrações
Em um cenário orientado a objetos, a abstração representa uma entidade do mundo real. Mais sua importância não para por ai, a abstração é uma peça chave não só para o cenário OO, como também, pare ter um cenário desacoplado; saber utilizar abstrações, é saber colocá-las em lugares estratégicos que venham viabilizar um baixo acoplamento. Quando são utilizadas classes concretas ao invés de abstrações, você cria o que é chamado de forte acoplamento, e que em caso de mudança, causa um grande impacto e esforço para esta mudança acontecer. Veja o diagrama abaixo:
Note que a classe abstrata Produto, circulada em vermelho, é a base para toda classe que for um produto, ou seja, não importa se o produto concreto é um livro, mochila, caderno, enfim a questão é que todas as classes serão herdeiras da classe Produto. Dentro de sua arquitetura, a classe que for servir de base para representar um item do mundo real, tem que conter os principais conceitos do que se deseja abstrair. Em nosso exemplo, estamos querendo abstrair, um Produto qualquer do mundo real, e note no diagrama mostrado anteriormente, que tenho as princípais informações na classe Produto, e toda e qualquer particularidade, passa a ser da responsabilidade da classe concreta implementar estes detalhes; vemos no exemplo a classe livro tendo atributos como ISBN e autor, e a classe mochila tendo os atributos cor e marca. Mais o conceito principal e comum, a todo e qualquer Produto, seja ele um Livro ou uma mochila, estão centralizados na abstração, ou seja, na classe Produto.
Note que a classe ItemPedido não faz referência a classe concreta Livro ou Mochila, ela faz referência a classe abstrata Produto; isto faz com que, qualquer alteração nas classes concretas não irão afetar em nada a classe ItemPedido. Esta forma de design, faz com que tenhamos um baixo acoplamento e tenhamos dependências mais leves, o que torna a manutenção mais fácil e a evolução também.
Dependências
Tudo o que um objeto precisa para funcionar, é chamado de Dependência. No mundo orientado a objetos, temos objetos se relacionando e fazendo referência a outros objetos a todo momento, e isto é normal. Mais a grande questão é que estas dependências, podem começar a ser um problema na hora de dar manutenção, e isto vai depender da “leveza” das mesmas, por que, podemos ter dependências leves ou pesadas. A dependência começa a ser um “peso”, justamente quando ignoramos o que foi dito anteriormente, as abstrações.
Quando um objeto tem uma dependência para uma classe concreta, qualquer mudança neste objeto fatalmente irá afetar o objeto que depende dele. E ai que mora o perigo, pois quantas não são as vezes que o desenvolvedor ao dar manutenção em um software, não corrigiu um problema e causou outro? Quantas não são as vezes que as dependências são tão pesadas, que para fazer uma simples adição de funcionalidade consome inúmeras horas de trabalho? Uma das formas de eliminar este problema é trabalhar justamente com abstrações. Veja o exemplo abaixo:
Veja que a classe TelaCadastro, representa uma tela de cadastro que tem uma dependência para a classe Repositorio, mais veja que esta é uma dependência “leve”, pois aponta para uma abstração; se o repositório concreto é um RepositorioSQLServer ou RepositorioOracle, isto para a classe TelaCadastro não importa, ou seja, qualquer alteração em uma destas duas classes de repositório concreto, não a afetam em nada; e além disto se for necessário passar a acessar um banco de dados DB2, basta apenas criar uma classe que herde da classe abstrata Repositorio e utilizá-la. Caso a dependência fosse para uma classe concreta, que implementasse as funcionalidades do banco de dados, não se teria a mesma facilidade para trocar de banco de dados; o que no exemplo acima é transparente e fácil.
Considere sempre utilizar abstrações em seu design, isto irá tornar as dependências mais “leves”, irá facilitar a manutenção, como também a evolução. Bom pessoal espero que tenham gostado do artigo, e que seja de bom proveito para o crescimento e amadurecimento profissional de cada um dos leitores deste artigo. Abraços e até a próxima.
