Filosofia Orientação Objetos

A arte da OOP define uma diretriz que apenas aponta para a direção de um caminho que pode ser seguido. Ou seja, ninguém é obrigado a andar por ela, mas o que eu percebo nos lugares que tenho passado é que as pessoas deixam de usá-la por questões relacionadas a uma falta de entendimento sobre a sua filosofia. Com isso, posso afirmar que a motivação é simples:

O objetivo primordial da OOP é fazer com que a infra-estrutura do projeto de software seje flexível ao ponto de dar ao próprio autor o controle total e pleno de suas estruturas internas de execução.

O assunto é tão badalado há muitos anos nas literaturas quanto na web justamente pelo fato de que no ciclo de vida de um sistema, os responsáveis gastam mais tempos alterando (80%) do que criando (20%). Exemplificando o caso, em um sistema de 10 anos de idade, os autores em media gastam dois anos para criar e oito para dar manutenção (correções ou novos requisitos). Com isso, não existe dúvidas de que aplicar a OOP na construção de um sistema é algo indiscutivelmente benéfico para todos os envolvidos. A elaboração e a construção de um sistema consistem em nada mais do que automatizar uma serie de rotinas que manipulam as entradas e saídas de informações que acontecem no mundo real. Como o objetivo é fazer o computador executar isso, as rotinas e as informações precisam ser identificadas e corretamente programadas para serem executadas dentro de um programa. É ai que entra a OOP com a sua filosofia de organizar todas estas rotinas e dados em entidades denominadas Objetos.  Dentro deste contexto, eu resolvi então escrever este artigo para discutir e resumir as diretrizes mais básicas e iniciais que devem ser consideradas e digeridas por qualquer pessoa que deseje aplicar com sucesso a OOP dentro de seu projeto de software.

Filosofia OO

Muitas pessoas ainda não perceberam que vivem em um mundo que é orientado a objetos. Indiretamente elas sabem disso, mas nunca pararam para raciocinar em cima da questão. Pare e pense… veja a sua volta. Responda as seguintes questões:

  1. Um cachorro é um ser humano?
  2. Uma pessoa pode voar?
  3. Uma caneta tem uma tampa ou a tampa tem uma caneta?

Todas as pessoas podem responder estas perguntas provando que qualquer um sabe lhe dar com os princípios da orientação a objetos, mas poucas podem tecnicamente explicá-las. Segue as respostas com algumas explicações bem simples, sem entrar em muitos detalhes ou variantes:

1. Não é porque o cachorro não aparenta ser e não se comporta como um ser humano – Objetos são classificados de acordo com sua aparência (propriedades) e comportamentos (métodos) que expressam o que este determinado objeto pode realizar. Já as classificações são agrupadores de objetos usados para definir aparência e comportamento geral para um conjunto de objetos e neste caso, o termo “Humano” é usado como uma classificação no qual estamos tentando colocar cachorro.

2. Não porque uma pessoa no mundo real não possui este comportamento – Objetos são capacitados de comportamentos individuais que refletem o que eles podem fazer. O que defini os comportamentos de um objeto é justamente a classificação na qual ele se encaixa e que neste caso, a pessoa no mundo real pode pertencer a varias delas, mas nenhumas delas expressa este comportamento.

3. Uma caneta tem uma tampa – Objetos existem para ser relacionar entre si e assim conseqüentemente gerar um comportamento maior. Este é o caso da maioria dos objetos existente do mundo real que nada mais é um aglomerado de objetos correlacionados entre si, gerando outro objeto maior composto. No mundo real, vemos que uma caneta não é um objeto, mas sim um ajuntamento de objetos menores, que poderíamos descrever como CANETA = TUBO + BICO + REFIL + TAMPA.

Veja que poderíamos até entrar em mais detalhes nesta análise de objetos ou abordar outras questões relacionados, mas meu único interesse é enfatizar que para se construir um programa OO é necessário visualizar as rotinas e os dados da automatização como se eles fossem objetos que acontecem no mundo real. Cada um precisa assimilar a idéia da filosofia no qual o paradigma se baseia, para que possa se desenvolver positivamente com sucesso.

 

Identificação de Objetos

Consiste na tarefa de identificar quais serão os objetos e suas responsabilidades do mundo real que serão automatizados para dentro do programa de computador. A palavra identificar foi destacado na frase acima porque tem alguns significados subliminares como: descobrir, abstrair, visualizar etc.… Também muito conhecido como Modelagem de Objetos que consiste no uso sistemático de algumas técnicas e metodologias comprovadas que podem ser usadas para se identificar os objetos na determinada solução. É aqui que a coisa pega, sendo que é o lugar de maior problema por que um projeto OO se torna inconsistente quando os objetos implementados na solução não refletem a realidade das ocorrências no mundo real. Craig Larman em seu livro Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process escreveu a seguinte frase:

A habilidade mais importante em um projeto OO é de atribuir responsabilidade a um objeto… por que ela influencia drasticamente a robustez, facilidade de manutenção e a reusabilidade de um componente de software.

Na prática, os projetos reais começam a ficar engessados e inflexíveis entrando no caminho da baixa manutenção devido às definições/implementações de objetos inconsistentes com o mundo real da solução. Exemplificando o caso, seria como se no mundo real existissem dois objetos interagindo entre si e na implementação desta aplicação, foi abstraído e implementado apenas um. Ou vice-versa, no mundo real existe apenas um objeto assumindo certa responsabilidade no qual o responsável do sistema implementou separado em dois ou mais objetos diferentes. Resumindo, o responsável pela modelagem do sistema OO não conseguiu por algum motivo visualizar e entender claramente as ocorrência dos objetos da solução. Depois da solução implementada, o sistema poderá funcionar lindo e maravilhoso sem nenhum problema no ponto de vista do usuário final, mas sua evolução e manutenção poderão estar comprometidas devido a sua estrutura de modelagem.

Algo que eu gostaria ressaltar neste tópico é que as aplicações OO estão em constantes evoluções à medida do tempo. Isso quer dizer que o um sistema não precisa implementar 100% da ocorrência do mundo real, em uma primeira versão. Ele precisa na verdade, passar por varias refinações incrementais, várias versões diferentes mas que todas elas sempre atendam duas necessidades básicas:

1. Requisitos do Cliente –  a versão do sistema precisa fazer o que ele foi proposto a fazer, resolver algum problema ou automatizar algum procedimento/tarefa.
2. Arquitetura Manutenível – a versão do sistema deve possuir uma estrutura de objetos que expresse flexibilidade para sua próxima evolução.

Infelizmente o mais comum que encontramos nas empresas são sistemas que cumprem os requisitos do cliente sem modelagem nenhuma de objetos. Quem já passou pela péssima experiência em evoluir sistemas assim é que realmente pode dizer. Na OO existe uma pratica pouco divulgada nas instituições de ensino que é chamado de Principio da Responsabilidade Única que na minha opinião resolve a maioria destes problemas de identificação de objetos. Resumidamente a pratica diz que um objeto só pode existir para encasular apenas uma única responsabilidade que justifica a sua existência na modelagem. Ou seja, um objeto não pode fazer duas ou mais coisas  por que fará com que varias implementações de responsabilidades diferentes/relacionadas coexistem misturadas/costuradas na mesma unidade de implementação. Em outras palavras, se um objeto esta responsável por fazer duas coisas, quando uma destas sofrer manutenção, a outra terá como resultados efeitos colaterais de manutenção.

Identificação dos Relacionamentos

Juntamente com o levantamento dos objetos, surge à necessidade de identificar quais serão os relacionamentos existentes entre eles. Para a felicidade de todos, existem apenas três tipos:

Herança – relação de “paternidade/filiação” aonde objetos podem ser estabelecidos como filhos de outros objetos pais.
Associação – relação de “usabilidade independente” aonde objetos podem usar outros objetos sem nenhuma dependência entre eles. Também conhecido como agregação simples.
Agregação – relação de “usabilidade dependente” aonde objetos podem usar outros objetos, estabelecendo dependência entre eles. Também conhecido como agregação por composição.

Filosoficamente dizendo, poderíamos visualizar como se tivéssemos no mundo real estes três tipos de relacionamento. Então para se descobrir qual destes selecionar na implementação de um caso OO, é necessário primeiramente entender as suas particularidades especificas que eu deixarei de fora deste artigo. E assim, posteriormente olhar para mundo real da solução e verificar qual destes se encaixa melhor nas abstrações em modelagem. Um complicador de peso nos relacionamentos é que eles dependem das corretas definições dos objetos. Ou seja, se os objetos foram modelados inconsistentemente, os relacionamentos também apresentarão inconsistências.

Na prática, os projetos reais começam a caminhar no sentido da inflexibilidade devido a uma inversão de valores nos relacionamentos. Ou seja, aonde era para existir uma agregação, foi inconsistentemente colocado uma herança, e assim por diante. Cada decisão errada faz o projeto ir evoluindo gradativamente para o engessamento, uma vez que uma decisão arquitetural inconsistente vira fundamento para outras posteriores.

Conclusão

A construção de um sistema OO consiste na tradução de todos os dados e procedimentos do mundo real para unidades de execuções denominados de objetos com seus relacionamentos. A questão que pega é

“Será que conseguiremos traduzir e transpor o mundo real em automação de forma que reflita a realidade das coisas ?“

Implementar um programa OO é fácil, o complicado é modelar o sistema de tal forma que reflita o negócio em questão de forma que expresse uma estrutura de projeto flexível e reutilizável. O que eu gostaria de enfatizar é eu percebo uma inversão de valores, onde vejo os profissionais perdendo mais tempo escrevendo código dos sistemas que na verdade, deveríamos gastar mais tempo/esforços modelando as abstrações.

Você gostaria de aprender OOP e a implementar em Java? Veja nosso curso de JSE M1 no qual abordamos conceitos e implementação OOP em Java.

“Que aproveita ao homem ganhar o mundo inteiro e perder a sua alma?” Marcos 8:36

Um pensamento sobre “Filosofia Orientação Objetos

  1. Pingback: Links da Semana (6/6/16 – 17/6/16) | Rocktto

Os comentários estão desativados.