Rodrigo Kumpera Weblog

Parece que configuração programática ficou em voga esses tempos na comunidade Java. A razão não me é muito clara, afinal, todo bom framework deve permitir ser usado de tal forma, porém não de maneira restritiva. Posso ter a opinião viciada nesse caso, mas acredito que configuração deve possuir sua DSL própria e a parte programática tem sentido apenas quando seu uso automatiza novas tarefas ou, de alguma forma, melhora sua usabilidade pelos desenvolvedores.

O maior argumento contra utilizar arquivos de configuração nunca foi muito o formato, seja xml ou qualquer outro, mas sim a quantidade abusiva de informação necessária para satisfazer o framework. Convenhamos, boa parte do tempo vamos usar apenas um conjunto pequeno dos recursos oferecidos e de uma maneira comum. Essas funcionalidades e interações recorrentes, devem possuir uma notação mais sucinta – o configuração deve ser ser otimizada para o uso comum. Para esse comportamento temos por uso de valores padrão inteligentes.

Porem, pode ser feito ainda mais. Neste caso, o framework assume que uma série de interações e padrões de uso serão utilizados e o usuário apenas configura aquilo que for diferente. Por esta maneira de trabalho, temos aquilo que chamamos por configuração por convenção. Juntando com valores padrão inteligentes, configuração deixa de ser uma preocupação, um martírio, para ser apenas um detalhe do projeto – que é seu devido lugar.

Em um cenário como esse, existe valor em expor uma extensa camada programática de acesso à configuração? Pelo resultado encontrado em vários projetos, sim, definitivamente existe, mas longe de ser uma boa ferramenta para substituir os arquivos. Primeiro, acho importante definir quais tipos de configuração existe em um framework e como isso afeta o valor ao abrir as portas para demais programadores.

Temos a Configuração de Inicialização, que pode ser vista como uma receita de bolo, que depois de utilizada, é descartada. O Hibernate é um bom exemplo, a configuração informada é utilizada para construir a SessionFactory e depois jogada fora. Outra forma de configuração é o Repositório de Parâmetros, onde toda configuração é armazenada de maneira que possa ser consultada em tempo de execução, o exemplo aqui fica por conta do Struts2, que transforma toda sua configuração em um modelo de objetos que representam os elementos envolvidos no processamento de uma requisição.

Das utilidades para configuração programática, destaco transformação, pois é aplicável no caso de Configuração de Inicialização. Transformação, como o nome sugere, altera a configuração já existente em algo mais útil, como colocar todas collections com lazy-loading; ou a partir de dados externos cria novos elementos, por exemplo, mapeando automaticamente todo um pacote de classes.

Quando existe um repositório, as possibilidades são maiores, o mecanismo de transformação pode ser aplicado na inicialização ou durante a execução. Para estender o comportamento do repositório utilizasse normalmente o padrão de projeto Plugin, para a descoberta do interessado, caso sejam muito, utiliza-se Chain-of-Responsibility para coordenar as transformações. O Struts2 funciona desta forma, é possível contribuir plugins que são responsáveis por instanciar as actions ou recuperar o mapeamento de um path. É possivel, por exemplo, descobrir quais actions existem no sistema e criar o mapeamento automaticamente.

Configuração programática é muito útil, porém não deixa de ser apenas uma ferramenta e, como tal, não deve ser o principal valor que um framework tem a oferecer, pois, a rigor, não trata do problema proposto a ser resolvido. Um framework MVC, por exemplo, deve ter como valores auxiliar no desenvolvimento de sites, dos quais configuração não é uma benéfice, mas sim um ardor maior ou menor para seu usuário.