3.2.1 Arcabouços e Bibliotecas de Classe
Apesar de um arcabouço geralmente fornecer uma boa biblioteca de classes, esta biblioteca não é a sua principal justi cativa. O que realmente importa é o modelo de interação e uxo de controle entre seus objetos. Além disso, o uxo de controle em um arcabouço é invertido quando comparado ao uxo de controle em um aplicativo que faça uso de uma biblioteca de classes, conforme discutido anteriormente.
Aprender um arcabouço é sempre mais difícil do que aprender uma biblioteca de classes, pois não se pode considerar uma classe do arcabouço de cada vez, nem usá-la separada de seu contexto. Um arcabouço é sempre utilizado no seu todo, não em partes. Mais ainda, em um arcabouço as classes principais são abstratas, o que torna necessário a implementação de certos comportamentos.
3.2.2 Arcabouços e Componentes
De certa forma, arcabouços podem ser vistos como componentes, pois uma aplicação pode usar diferentes arcabouços, obtidos junto a diferentes desenvolvedores. A principal diferença, no entanto, reside no fato de que arcabouços são muito mais customizáveis do que componentes, servindo para uma gama maior de situações. Nesta questão, faz-se um compromisso entre aplicabilidade e facilidade de uso. Por um lado, arcabouços são muito mais poderosos do que componentes. Por outro lado, o uso de um arcabouço exige um aprendizado maior do que o exigido para se usar um componente.
Uma abordagem melhor consiste em considerar arcabouços e componentes como tecnolo- gias distintas. Apesar de distintas, estas tecnologias cooperam entre si. Arcabouços fornecem um contexto reutilizável para componentes, de modo que a forma como estes componentes gerenciam erros, trocam dados e invocam operações uns sobre os outros se torna padronizada. Uma outra forma de cooperação entre arcabouços e componentes pode ser visto no fato de arcabouços faciltarem o desenvolvimento de novos componentes. Arcabouços permitem que estes novos componentes sejam construídos a partir de componentes menores, já existentes, além de fornecer especi cações e modelos de implementação para os mesmos.
3.2.3 Arcabouços e Padrões de Projeto
Um padrão de projeto descreve um problema a ser resolvido, uma solução e o contexto onde esta solução é implementada. De forma geral, padrões de projeto têm se tornado populares entre os desenvolvedores de aplicações orientadas por objetos. Um padrão nomeia uma técnica testada e consagrada pelo seu uso, e descreve os custos e benefícios em se adotar esta técnica em particular. Os devenvolvedores que usam os mesmos padrões também compartilham um vocabulário comum para conversarem sobre seus projetos e explicitarem decisões sobre os mesmos.
Segundo Johnson, como arcabouços foram implementados várias vezes, estes de certa forma se constituem um tipo de padrão [Joh97a, Joh97b]. A diferença é que um arcabouço também possui código, ao passo que um padrão é apenas uma idéia.
Outro ponto de relacionamento entre arcabouços e padrões é que muitos padrões surgiram do exame cuidadoso de arcabouços com o objetivo de encontrar elementos representativos de sua reusabilidade. Um arcabouço contém geralmente muitos padrões diferentes, de forma que um arcabouço é algo maior do que um padrão. Um padrão é mais abstrato que um arcabouço, ou seja, ambos estão em níveis diferentes de abstração.
Gamma et alii [GHJV95] apresenta três diferenças cruciais entre padrões de projeto e arcabouços:
• Padrões de projeto são mais abstratos que arcabouços Arcabouços podem ser representa- dos por meio de código, mas apenas exemplos de padrões podem ser representados por código. Uma das vantagens de um arcabouço é que ele pode ser escrito em uma lingua- gem, de forma que sua especi ação não é apenas passível de ser estudada mas também de ser executada e reusada diretamente. Em contraste, padrões de projeto devem ser implementados cada vez que são utilizados.
• Padrões de projeto são elementos arquiteturais menores do que arcabouços Um arcabouço típico contém vários padrões, embora o contrário nunca seja verdadeiro.
• Padrões de projeto são menos especializados que arcabouços Um arcabouço sempre tem um domínio de aplicação bem especí co. Em contraste, padrões de projeto podem ser usados em praticamente qualquer tipo de aplicação.
3.2.4 Arcabouços e Outras Formas de Reúso
Segundo Johnson [Joh97a], arcabouços são semelhantes a outras formas de reúso de código, tais como templates e esquemas. A principal diferença é que arcabouços são expressos em uma linguagem de programação, ao passo que estas outras formas de reúso de alto nível usualmente usam uma notação especial de projeto e freqüentemente se apóiam em ferramentas especiais de software. O fato de um arcabouço ser um programa facilita o seu uso. Ao mesmo tempo, limita uma implementação de um arcabouço especí co àquela linguagem em que este foi escrito. Exceções são possíveis, embora limitadas em quantidade. Por exemplo, um programa Java pode invocar funções e métodos em C e C++ via JNI - Java Native Interface [Lia99].
Arcabouços também são semelhantes a geradores de aplicações. Um gerador de aplicações se baseia em uma linguagem de alto nível de domínio especí co que é compilada para uma arquitetura padrão. Um arcabouço também é uma arquitetura padrão. Desta forma, à exceção da sintaxe e do fato que o tradutor de um gerador de aplicações pode realizar otimizações, as
de usar do que um projeto iniciado da estaca zero. Esta última proposta é, no entanto, mais exível e aplicável. Ao se comparar um arcabouço com técnicas que reusam tanto código quanto projeto, tais como geradores de aplicações e gabaritos (templates), sua princpal vantagem é que um arcabouço pode ser implementado sob qualquer linguagem orientada por objetos, sem necessidade de ferramentas especiais.
Apesar das várias vantagens de se utilizar arcabouços, a reusabilidade não é gratuita. Ar- cabouços são difíceis de se desenvolver e de se aprender. Usar um arcabouço requer que um mapeamento da estrutura do problema a ser resolvido na estrutura do arcabouço, o que di- culta a tarefa de projetar um arcabouço, pois este deve ser o mais genérico possível, mas sempre observando o compromisso assumido entre generalidade e facilidade de uso. A di cul- dade também aparece do lado do usuário do arcabouço, que deve fazer este mapeamento entre o problema existente e o arcabouço disponível. Esta tarefa é facilitada pela presença de uma boa documentação do arcabouço, cuja tarefa consiste em explicar o propósito de arcabouço, como usá-lo e como este realiza a sua tarefa.
Arcabouços são e cientes para se expressar projetos reutilizáveis. Suas vantagens, citadas anteriormente, justi cam a maior di culdade em implementá-los. Cabe ao cliente do arcabouço avaliar se um arcabouço especí co atende às suas necessidades e se este realiza os compromissos adequados entre poder e simplicidade.