Objetos ou Estruturas de dados? A pergunta surge pelo fato de que embora hoje existam linguagens e ferramentas que dão total suporte ao desenvolvimento orientado a objetos, nem todos os desenvolvedores fazem uso de todos os recurso que a OO oferece. A Orientação a objetos nos diz que “objetos são representações de personagens do mundo real” e “objetos reúnem dados e comportamento”, mais ao contrário destas definições o que vemos é o que mostra a figura abaixo:
O que vemos na imagen acima, é o que a anos vem sendo feito em questão de modelagem de software. As classes, ao invés de serem representações de personagens do mundo real, passam a ser a representação das tabelas do banco de dados, indo totalmente contra os princípios da orientação a objetos. Pode parecer muito purismo, mais quando se trata de software temos questões como manutenção, evolução e correção de erros; uma vez utilizando abordagens como a demostrada acima, estas tarefas se tornam muito difíceis e custosas de se fazer.
Objetos x Estruturas de Dados
Como identificar quando temos um objeto e quando temos uma estrutura de dados? É simples como na figura mostrada anteriormente, o que temos é uma estrutura de dados que é uma classe que expõe seus atributos, onde o consumidor da classe pode livremente acessar suas propriedades e modifica-las; Já quando temos objetos, os mesmos, não permitem que seus dados sejam modificados diretamente, mais expõem métodos que efetuam tais mudanças, ou seja, quando o consumidor da classe deseja realizar alguma operação no objeto em questão, ele chama um de seus métodos para realizar tal tarefa. Observe o exemplo abaixo, de como ficaria o cenário abordado na figura anterior contemplando a orientação a objetos:
Observe o código abaixo da classe cliente:
O primeiro detalhe no código acima é o seguinte: as propriedades da classe não podem ser escritas diretamente, isto faz com que tenhamos que expor métodos que serão utilizados quando o consumidor da classe quiser efetuar alterações no estado do objeto. Temos o exemplo da propriedade Endereco e Telefone, que possuem métodos que efetuam a escrita nas propriedades já que isto não pode ser feito diretamente. O construtor parametrizado, recebe como parâmetro dados que são obrigatórios na criação do objeto, como por exemplo TODO cliente precisa ter um nome. Talvez você esteja se perguntando: estamos trabalhando igual ao java que não tem propriedades? Trabalham com métodos get e set? Não estamos utilizando REALMENTE a orientação a objetos, e isto quer dizer que não devemos dizer a um objeto o que ele deve fazer, que é quando temos acesso diretamente aos seus atributos, mais pedir que ele faça tal tarefa, que é quando chamamos os métodos expostos por ele. E note que o diagrama mostrado anteriormente, além de mais organizado, está realmente se comportando como o espelho de personagens do mundo real e traduzindo em objetos, e não é mais um espelho das tabelas de um banco de dados. Vale ressaltar que, isto vale também para as regras de negócio à que estejam relacionado o objeto em questão, e não somente aos seus
atributos. Veja o exemplo abaixo:
Imaginando que este método esteja em uma classe pedido, ele está realizando uma validação de negócio, em que não pode ser adicionado um item de pedido em que quantidade seja zero.
Trabalhando levando em consideração os princípios da orientação a objetos, temos várias vantagens que nos fazem ter certeza, que esta forma de trabalhar é muito melhor do que o método convencional, em que os desenvolvedores enxergam os objetos apenas como espelho do banco de dados. Se os princípios forem utilizados corretamente, os benefícios que ele traz irão aparece através de uma manutenção mais rápida e evolução mais eficiente.
Bom Pessoal , espero que tenham gostado do artigo, e que ele possa colaborar com o crescimento e evolução profissional de cada leitor, abraços e até a próxima.
Advertisement
Like this:
Be the first to like this post.
