PauloMotta.pro

Uma das características mais interessantes da ciência da computação (ou informática, depende do gosto do leitor) é a constante e rápida evolução. Isso é uma característica da área até porque suas evoluções permitem suportar pesquisas em outras áreas. E quando paramos para pensar sobre isso uma das coisas que nos vem a mente é, mas o que é que move essas pesquisas, essas evoluções?

Bom, existem várias respostas para essa pergunta, mas com certeza a mais interessante é a que diz respeito a demanda do usuário. Não vou falar sobre como surge a demanda do usuário por sistemas propriamente, mas é entender que em algum momento o usuário percebe um interesse por um sistema. Até aí tudo bem, o “problema” começa na verdade quando o usuário começa a aumentar a lista de necessidades, porque do ponto de vista puramente abstrato (característica do software) tudo é possível fazer, porém quando tentamos “concretizar” a necessidade do usuário em software essa tarefa em alguns casos se torna mais difícil do que deveria ser. Isso acontece porque quando vamos ampliando os horizontes dos sistemas vamos chegando aos limites que as nossas técnicas comportam. Um dos limites mais importantes é o de gerenciar abstrações de mais alto nível, ou seja, quando chegamos nas fronteiras do desenvolvimento de sistemas não conseguimos mais gerenciar adequadamente as abstrações necessárias para desenvolver os sistemas que atendem as novas demandas dos usuários.

Isso acontece e fica claro quando pensamos na programação estruturada de forma comparada com a programação orientada a objetos. Essas duas formas de visão (ou paradigmas) não são contrárias entre si, apenas fornecem métodos de modelagem diferentes. Costumo dizer que a mudança está no foco, enquanto a programação estruturada trabalha com o foco nas funções do sistema, a programação orientada a objetos tem o foco nos dados, ou mais precisamente nos tipos abstratos de dados e isso é uma diferença fundamental.

O impacto dessa mudança de foco está no fato de que fica mais fácil de se comunicar com o usuário uma vez que estaremos trabalhando com as entidades ou conceitos que são usados diariamente, sejam eles Produto, Compra, OrdemDeVenda, ItemDePedido, Fornecedor entre outras. Com isso gastamos (ou deveríamos gastar) mais tempo com a análise, projetando um sistema mais coerente com as abstrações do próprio usuário e torna-se (ou deveria se tornar) possível construir sistemas maiores, com uma complexidade menor. Na prática surge uma dificuldade diferente que é conseguir lidar com um nível maior de abstração, mas isso se deve muito mais a falta de prática (e/ou vontade de realmente aprender a técnica) do que a mudança de foco em si.

Uma outra característica importante e interessante é o fato de que a programação orientada a objetos contém a programação estruturada, ao contrário do que as pessoas pensam que teram que simplesmente jogar tudo fora e aprender novamente. O ponto é que agora não dá para ir só aglutinando funções, o que gera as dependências, é necessário pensar onde as coisas entram, de quem é a responsabilidade por executar um certo código. Os métodos (o equivalente as funções) precisam fazer parte de uma classe, então não acontece (ou não deveria acontecer) de termos uma classe Recibo com um método imprime porque o Recibo não deveria mesmo conhecer o sistema de impressão, ao invés disso, essa classe fica responsável por aglutinar os dados de um Recibo de forma que seja mais claro e simples carregar essa informação. Por outro lado a classe ServicoDeImpressao pode ter acesso a classe ModeloDeImpressao para preencher com os dados e executar a impressão propriamente dita. O que conseguimos com isso é ter uma separação clara entre classes de dados e classes de controle, além disso, como efeito colateral, temos uma organização do sistema que nos permite achar de forma mais simples e ágil onde estão os códigos que realizam cada tarefa.

É claro que junto com um novo paradigma vem um conjunto de novas formas de pensar o sistema, então torna-se necessário aprender a fazer a análise de forma adequada para poder fornecer para o programador todas as informações necessárias à construção do sistema. Enquanto na programação estruturada quase sempre partíamos diretamente para a codificação, na programação orientada a objetos é muito difícil que essa abordagem funcione de forma satisfatória porque é necessário pensar onde as coisas vão se encaixar.

“Ah, mas se eu colocar em qualquer lugar e fizer a chamada não vai funcionar?” Bem, a resposta é sim, vai funcionar, só que não teremos nenhum benefício de usar a orientação a objetos se não fizermos as coisas como devem ser feitas. Muitas vezes vemos nas empresas sistemas feitos em Java, C++ e C# que, embora usem linguagens orientadas a objetos, são programados de forma estruturada. “Mas isso é possível?” Sim, o fato de usar uma linguagem orientada a objetos não quer dizer que o seu sistema esteja orientado a objetos, de fato é possível até mesmo construir um sistema orientado a objetos com uma linguagem estruturada como C (só que isso é muito mais difícil.)

Isso nos leva a entender que os paradigmas estruturado e orietado a objetso são apenas formas de trabalhar, o uso de uma linguagem que dá suporte a um ou outro não nos obriga a usá-lo. No entanto se estamos escolhendo trabalhar com uma linguagem que suporta o paradigma orientado a objetos (salvo situaçõe puramente de modismo) é porque estamos interessados nos benefícios que esse paradigma pode nos oferecer, quando não gastamos o tempo necessário para aplicar as técnicas estamos jogando fora uma possibilidade de escrever sistemas mais claros e com maior durabilidade (considerando que o usuário tenha interesse no sistema durante um longo período.) Essencialmente, um sistema deveria durar o tempo suficiente para que o usuário perca o interesse ou a necessidade nos serviços prestados no sistema de forma que ele seja substitído. Enquanto o usuário não precisar de um sistema novo, deveria ser possível aplicar evoluções no sistema em uso, muitas vezes isso não é possível porque devido ao uso incorreto das ferramentas o sistema tem tantas dependências entre módulos que quebra. Nesse tipo de situação o usuário ainda tem interesse no mesmo serviço, mas é obrigado a trocar o sistema  por não ser possível mais evoluir e adaptar as dinâmicas diárias.