Básico 6 - Por Que Componentes?
Como viemos comentando em outros artigos que muitas das idéias atuais sobre componentes tiveram suas origens nas tecnologias orientadas a objetos, e que estas trouxeram inúmeras vantagens à reutilização de software, é natural nos questionarmos aonde a orientação a objetos pura revelou-se insatisfatória.
Segundo Herzum e Sims [Herzum+2000], a abordagem de orientação a objetos possui algumas limitações que são críticas para sistemas em larga escala. A primeira delas é a reutilização apenas em tempo de desenvolvimento, a qual está restrita basicamente a classes, objetos e frameworks. Embora esse tipo de atividade melhore muito o desempenho da equipe, existem outras necessidades igualmente importantes, como a reutilização em tempo de implantação e em tempo de execução. Outro problema, segundo os mesmos autores, está na pouca interoperabilidade e portabilidade disponíveis, fazendo com que o sistema fique amarrado a apenas uma tecnologia e apenas uma plataforma.
A linguagem java surgiu, mais tarde, como uma solução para esse problema de portabilidade.
Como conseqüência, a orientação a objetos não resolveu muito a situação dos sistemas legados, já que temos apenas dois caminhos na maioria dos casos: reescrevê-los totalmente nas técnicas orientadas a objetos ou deixá-los sem integração direta com as novas soluções. A possibilidade de adotarmos parcialmente essas tecnologias e combiná-las com antigos sistemas não é algo trivial.
Existe ainda uma terceira questão mal resolvida: as técnicas orientadas a objetos mudaram apenas a forma de se desenvolver software. Quanto a forma com que o software é entregue ao usuário, esta não sofreu muitas mudanças. Isso significa que as aplicações desenvolvidas ainda são blocos monolíticos com acesso restrito a partes substituíveis e reutilizáveis. Por mais que a equipe elabore uma boa arquitetura e crie separações funcionais bem definidas dentro do código, cada parte dificilmente conseguirá ser aproveitada em outras aplicações sem exigir um esforço razoável dos desenvolvedores.
Agora que a utilidade dos componentes está ficando mais clara, precisamos lembrar que as tecnologias orientadas a objetos não foram as vilãs dessa história. Muito pelo contrário, elas tiveram uma participação fundamental na elaboração de idéias e soluções focadas em componentes. O que é imprescindível a partir desse ponto é termos uma disciplina específica para essa área, que seja independente de qualquer tecnologia e que trate satisfatóriamente de todos os assuntos envolvidos no desenvolvimento completo de aplicações nessa linha. Essa disciplina vem sendo chamada de Engenharia de Software Baseada em Componentes.
Já que comentamos a revolução que os componentes causaram em nossas vidas, podemos aproveitar o contexto dessa palavra para aprender um pouco mais sobre os benefícios de se utilizar componentes em aplicações de software. Estamos nos referindo à forma com que verdadeiros revolucionários e espiões normalmente se organizam para aumentar as chances de sucesso em uma revolução.
A parte interessante dessa história é o fato de que esses agentes freqüentemente se organizam em grupos chamados células, e que indivíduos de uma mesma célula se conhecem, mas não conhecem os integrantes de outras células. Se uma das células for descoberta pelo inimigo, poucas informações são reveladas. Por eliminar as interações entre as células, todo o grupo torna-se mais protegido.
Você sabia que esse mesmo princípio também pode ser aplicado ao desenvolvimento de software? Nesse caso, as células em questão são os nossos componentes e, ao limitar a interação entre eles, conseguimos proteger o software mais eficientemente. Se um dos componentes tornar-se comprometido, podemos substituí-lo sem grandes impactos na arquitetura.
Além da substituição de componentes, precisamos olhar também pelo lado das constantes mudanças que ocorrem nos requisitos ao longo do ciclo de vida do software. Para estarmos preparados para isso, não temos muitas opções além da construção de sistemas que sejam fáceis de adaptar. Caso esse caminho não seja seguido, perceberemos que a nossa aplicação irá se tornar rapidamente desatualizada e cada vez mais difícil de ser mantida.
É neste sentido que o uso de componentes também se revela promissor, permitindo que aplicações possam ser desenvolvidas de forma flexível e configurável. Como as regras e estratégias de negócio são muito mais propícias a mudar do que qualquer outro aspecto do projeto, possuir uma aplicação desacoplada e flexível é uma vantagem de valor inestimável. Assim como documentado pelo cientista Charles Darwin (em A Origem das Espécies - 1859), espécies que não se adaptam morrem. Qual a sua conclusão para software que não se adapta?
Observar o software como um conjunto de partes independentes traz ainda muitas outras vantagens. Uma delas é a possibilidade de atribuirmos cada componente a uma equipe diferente, paralelizando as atividades do projeto e reduzindo a interação entre cada grupo de trabalho. Outra questão é a melhor capacidade de distribuir o processamento em diferentes máquinas, ajustando cada solução em função do volume de processamento desejado.
As vantagens trazidas pelos componentes ainda não param por aí. Uma das contribuições mais promissoras desse conjunto de idéias está na forma com que os componentes são especificados separadamente de suas implementações, o que significa que um mesmo componente pode existir em diversas tecnologias e, principalmente, avançar junto com elas ao longo dos anos sem a necessidade de reprojetá-lo ou traduzir cegamente seu código de linguagem para linguagem.
Referências
[Herzum+2000] Peter Herzum e Oliver Sims. Business Component Factory: A Comprehensive Overview of Component-Based Development for the Enterprise. John Wiley & Sons (OMG Press) 2000.