Os princípios e as técnicas de engenharia de software possuem diversos objetivos, como padronização, organizar componentes, separação de responsabilidades, como também extensibilidade e composição.

Há muito tempo que se buscam soluções, que permitam que sejam construídos sistemas que sejam fáceis de modificar, mas que também possam ser estendidos com facilidade. O fluxo de mudanças em determinados tipos de negócios tem uma variação muito grande e os softwares que visam atender os mesmos, caso não sejam fáceis de serem estendidos, adicionando funcionalidades facilmente, certamente irão fracassar.

Atualmente, se vê no cenário mundial de arquitetura de software, um esforço grande em tornar real este desejo de softwares que sejam fáceis de estender. Ou seja, sistemas que sejam como um “lego”, em que peças são adicionadas com facilidade ao mesmo. Martin Fowler, em seu livro “Padrões de Arquitetura de Aplicações Corporativa”, apresenta um pattern chamado PlugIn Pattern, que tem a descrição da seguinte forma:

“Conecta classes durante a configuração em vez de na compilação.”

Esta frase simples sobre o pattern nos mostra a ideia central. O Plugin, como seu próprio nome diz, tem o objetivo de em tempo de execução, conectar objetos que respeitem um determinado contrato de serviço, e que os mesmos possam ser carregados em tempo de execução. O Plugin pattern é uma das formas que podemos utilizar para ter uma arquitetura extensível.

Extensibilidades e Contratos de Serviço

É necessário entender que, precisamos estender o que muda e o que varia. Ou seja, utilizar a extensibilidade com sabedoria. Para conseguir ter um software extensível, precisamos enxergar os pontos que terão um maior fluxo de mudança e definir contratos de serviço ou uma interface de comunicação. Um contrato de serviço ou interface de comunicação é um contrato em que serão especificadas regras a serem respeitadas.E isso é justamente o essencial para aquele contrato e que também pode ter complementos diferentes, como por exemplo, Login, Tratamento de Exceções e outras questões. Vejamos um exemplo no diagrama abaixo:

O contrato de serviço ou interface de comunicação propriamente dito:

Veja que é definido um contrato, alguém que calcule os juros, pois quando um financiamento é realizado, uma instituição financeira está por trás e cada instituição tem seu modo de calcular os juros.

O cálculo dos juros é um ponto de extensão, um ponto em que se faz necessário trabalhar com a extensibilidade. Poderíamos também, já partindo para a parte de infraestrutura, tornar extensível a parte do sistema que trata de Log de informações, seja ela log de erro ou de transação. Veja o outro exemplo:

No caso de tornar o mecanismo de efetuar logs extensível, temos um contrato de serviço que define o que um “logger” precisa fazer. Além disso, temos as classes concretas que efetuam log de diversas maneira, como banco de dados, arquivo XML, Log no Event Viewer do windows.

No Log de banco de dados, a classe aponta para uma abstração de um repositório
que, sendo abstrato, também define um contrato de serviço. Sendo assim, se hoje
o log é feito no banco de dados em um servidor SQL Server, por exemplo, amanhã,
se passar a ser feito no Oracle, a mudança não causará impacto no mecanismo de
login.

Veja como a extensibilidade faz com que o software seja como um “lego”, em que o contrato de serviço é como se fosse a parte em que será feito o “encaixe”. E a implementação concreta age como o “pino” de encaixe, havendo assim uma arquitetura flexível e de fácil manutenção e evolução.

Em breve abordaremos tecnologias para auxiliar na criação de Arquiteturas flexíveis como o MEF, por exemplo .

Abraços e até a próxima.