1. Introdução

Nos últimos anos verificou-se o grande aumento da utilização da tecnologia de orientação a objetos. Desde o início da década de 90 tem-se acompanhado, a princípio na comunidade acadêmica e após nas empresas, a crescente adoção da Orientação a Objetos para o desenvolvimento de aplicativos. Este aumento deve-se, principalmente, às soluções propostas por esta tecnologia, as quais vêm a amenizar os efeitos dos problemas gerados pela Crise de Software. No começo, algumas empresas viam com ressalvas os benefícios trazidos pela orientação a objetos, devido à pouca produtividade inicial conseguida por seus desenvolvedores; entretanto, passados agora alguns anos, não existem mais dúvidas quanto à sua adoção, sendo apenas uma questão de tempo para sua completa utilização de seus princípios.

Como conseqüência da adoção da metodologia Orientada a Objetos para desenvolvimento de aplicativos, tivemos uma explosão de métodos, linguagens e ferramentas que implementam, de uma forma ou outra, todos os conceitos apresentados por esta tecnologia. Hoje existe uma tentativa de se padronizar uma linguagem para especificação de sistemas orientados a objetos, a UML. Esta linguagem é baseada em um conjunto de métodos já utilizados e adotados em diversos lugares do mundo, os quais são OMT e Booch. No campo das linguagens de programação, também temos uma série delas, cada qual mais apropriada para um objetivo; só para citar alguns casos, temos C++, SmallTalk, e mais recentemente Java.

Uma vez que a Orientação a Objetos é uma realidade, e métodos e linguagens são abundantes no mercado, a discussão volta-se agora para outra direção. A simples adoção dos conceitos não é o suficiente, para a construção de aplicativos com qualidade, mesmo que acompanhados das melhores ferramentas. Incluam-se aí as linguagens de programação. A discussão agora é como projetar, mas como projetar da melhor maneira possível.

1.1 Desenvolvimento Orientado a Objetos.

Desenvolver software orientado a objetos é difícil, por mais que todos digam que é fácil, não é. É difícil, ainda mais quando o desenvolvedor vem com uma bagagem de desenvolvimento semi-estruturado e estruturado. Agora, desenvolver software orientado a objetos e que seja reusável é infinitamente mais difícil.

Talvez, num futuro não muito distante, venham nos perguntar: "Como era possível desenvolver aplicativos sem utilizar objetos ?"; da mesma maneira que hoje perguntamos: "Como era possível desenvolver software de maneira não estruturada ?".

É claro que o primeiro projeto é sempre o mais crítico, já que existe a necessidade de se desenvolver tudo, a partir do nada. No segundo, alguns objetos que foram pensados para o primeiro podem ser utilizados, com algumas adequações. No terceiro, podem ser utilizados objetos do primeiro e do segundo; assim, conforme vamos desenvolvendo mais projetos Orientados a Objeto mais fácil para os desenvolvedores vai se tornando, uma vez que muito do que foi elaborado anteriormente pode ser utilizado para desenvolvimentos futuros. Em conseqüência da reutilização de código, os projetos, em si, vão ficando melhores e mais bem acabados, uma vez que os objetos neles utilizados já são completamente funcionais.

Isto deve-se porque, normalmente, todos os projetos envolvem a resolução de problemas recorrentes; e quantas vezes não nos pegamos com a sensação de já termos resolvido um problema semelhante em algum momento do passado. Este conhecimento, de como se resolver um determinado problema, acumulado durante os anos, é o que chamamos de experiência, e esta experiência está ligada diretamente aos responsáveis pela resolução carregada apenas pelos desenvolvedores que um dia resolveram aquele problema. Mas como podemos armazenar esta experiência para outros usos, ou então para o auxílio de outros desenvolvedores.

Este ponto é importante, um desenvolvedor experiente nunca começa a desenvolver um sistema realmente do zero. Ele aproveita desenvolvimentos anteriores que deram certo e que foram sendo refinados com o tempo, como ponto de partida para um novo sistema.

Se pudéssemos catalogar esta experiência anterior em uma forma que qualquer pessoa, seja experiente ou não, conseguisse realmente utilizar para resolver seus problemas de desenvolvimento, conseguiríamos um grande aumento na qualidade dos projetos e uma redução sistemática nos tempos de desenvolvimento dos sistemas.

Um dos principais motivos levantados para a catalogação da experiência é fazer com que desenvolvedores novatos possam agir como se fossem desenvolvedores especialistas, sem a necessidade de passar anos ganhando experiência.

O principal problema da orientação objeto, é que por ser uma tecnologia nova não existem meios seguros de estimar o término e o cronograma do projeto. Não existem ferramentas para estimar este término.

Integrar a tecnologia Orientada a Objetos em uma corporação implica em mudar vários comportamentos culturais e muito cuidado deve ser usado para treinar as pessoas nesse novo paradigma. Muitos problemas podem advir do treinamento quando as pessoas começam a lidar com objetos e devemos ajudar as pessoas a lidar com esse medo.

O problema do treinamento é bem significativo, a curva de aprendizado da OO e bem acentuada, exige-se muito estudo para entendermos o básico.

Deve-se também manipular as expectativas, pois muitas vezes os usuários acham que todos os seus problemas serão resolvidos com a OO e isso não acontece se não houver uma interação e treinamento intensivo em todos os níveis da organização.

Em relação a aspectos da programação a OO é uma programação de mais alto nível que as tradicionais, isso quer dizer que ela esconde bastante código do programador, logo, se o problema inicial que foi adotado ganhar mais complexidade teremos mais problemas.

Para lidarmos com o código, resolvermos bugs, é mais difícil que as linguagens estruturadas, pois existem muitos objetos, pequenos as vezes, que fazem interações imprevisíveis.

Finalmente podemos citar que o modelo de orientação a objetos e incompatível com o ponto de vista procedural de administração e estratégia trazendo muitos problemas de comunicação e conversão.