Clique aqui para ler este artigo em pdf 
Clique aqui para ler todos os artigos desta edição
Rica OOP, Pobre OOP
por Mauro Sant’Anna
A OOP (Programação Orientada a Objetos) foi anunciada no início dos anos 90 como a solução para muitos problemas que rondavam o desenvolvimento de software.
Em primeiro lugar, a OOP era ideal para criar “application frameworks” e bibliotecas para gerenciamento de janelas nas então recém-lançadas “GUI” (Interfaces Gráficas com Usuário). Naquela época, apareceram diversas implementações bem-sucedidas de “frameworks”, como o ”OWL” da Borland o e “MFC” da Microsoft. Pode-se dizer que hoje a própria “.NET Framework” é um bom exemplo de uma biblioteca de classes baseada em OOP. As vantagens da OOP para a criação de “Application Frameworks” são inquestionavelmente óbvias, tanto que os principais ambientes de desenvolvimento e execução atuais – Java e .NET – usam este modelo.
Contudo, a OOP também foi usada em outras situações, embora com resultados menos espetaculares. Uma das situações para as quais a OOP prometia enormes resultados era a “componentização” dos sistemas. Nesse cenário, os aplicativos eram quebrados em “componentes” (na verdade, classes) que “conversavam” entre si. Esses componentes sequer precisavam residir no mesmo computador; eles poderiam estar em máquinas separadas e haveria um mecanismo de “invocação remota” via rede. Seria possível escrever diferentes aplicativos apenas “colando” componentes diferentes – ou pelo menos essa era a teoria.
Surgiram então dois padrões concorrentes: o COM/DCOM/COM+, da Microsoft, e o CORBA, dos concorrentes da Microsoft. Apesar de ferrenhos inimigos, o COM e o CORBA são incrivelmente parecidos: ambos os programas são baseados em classes que implementam “interfaces” definidas em uma linguagem especial (“IDL”). Os componentes armazenam dados dentro deles, ou seja, têm estado – afinal este é um dos marcos da OOP: juntar dados com comportamentos no mesmo lugar.
Depois de vários anos lutando com a componentização baseada em classes, descobriu-se que havia alguns problemas, como por exemplo:
· A manutenção de estado nos componentes dificultava a distribuição de carga (“load balancing”) e a tolerância a falhas (“fail-over”). Passou-se a recomendar que os componentes NÃO mantivessem estado, algo meio irônico na medida em que essa era uma das “vantagens” da OOP;
· A chamada remota dos métodos dependia de protocolos que não se adequavam aos padrões de segurança de conexão via Internet, principalmente no que se referia ao uso de portas TCP e autenticação;
· Os sistemas eram muito dependentes de versões dos componentes e frágeis quando haviam mudanças;
· Não havia nenhuma garantia de interoperabilidade entre o COM e o CORBA e, às vezes, nem mesmo entre diferentes versões de diferentes fornecedores do CORBA.
Surgiram então os Web Services, um padrão simples mas eficaz de interconexão de computadores. Embora usualmente implementados em linguagens orientadas a objeto (como C#, VB.NET ou Java), os Web Services são baseados em mensagens relativamente simples no formato XML, e não em um padrão OOP sem previsão para preservar estado.
Recentemente, temos ouvido falar muito no SOA (Arquiteturas Orientadas a Serviços). Os “serviços” são mais simples que as “classes” e, de modo geral, definem apenas o padrão de mensagens trocadas entre os serviços e seus clientes. Nada de IDL, OOP ou coisas parecidas. Evidentemente, os Web Services são perfeitos para implementar esse tipo de arquitetura. A próxima versão do Windows Server, o “Longhorn, virá com um excelente suporte a SOA em seu componente “Índigo” (Camada de Comunicação e Conectividade).
Resumindo: a OOP é boa para implementar bibliotecas de classes, algo que sabemos há muito tempo, mas revelou-se um fracasso na componentização de sistemas. Ela tende a ser substituída por um modelo muito mais simples, baseado em mensagens em vez de objetos.
