Guilherme Chapiewski

Segundo dia de QCon e hoje foi a vez de Martin Fowler e Neal Ford falarem sobre Domain Specific Languages.

Com dois profissionais desse nível dá pra imaginar como o tutorial foi espetacular! O Fowler é sem sombra de dúvidas o melhor palestrante que já tive a oportunidade de ver. O ritmo que ele impõe é sensacional e a paixão com que ele fala do assunto é contagiante!

Para melhorar ainda mais o dia começou com uma ótima notícia: o Fowler está escrevendo neste momento um novo livro sobre DSLs. O livro já está no forno há um ano e já tem muita coisa escrita. Toda a apresentação de hoje foi baseada no seu novo livro e inclusive tivemos acesso a todo o material da sua pesquisa e o primeiro draft do livro! Está sensacional! O Neal também está escrevendo um livro sobre Ruby e DSLs, porém pelo que eu entendí está num estágio bem menos avançado.

Como o material da apresentação fará parte desse novo livro a distribuição foi proibida. Já que não dá para colocar o material aqui vou falar resumidamente sobre os assuntos abordados durante o dia, que foi dividido em três grandes partes.

Na primeira parte os dois apresentaram um introdução sobre o que são DSLs e como elas podem ser úteis. Eles criaram um framework imaginário (uma máquina de estados) e começaram a mostrar todos os problemas de quando este framework é desenvolvido como uma API. Em seguida eles criaram uma “casca” em torno dessa API (uma Fluent Interface) para facilitar o uso da mesma.

A partir daí eles definiram os conceitos de DSL interna e externa. DSLs internas são como as Fluent Interfaces, que são escritas na linguagem do sistema (Java, por exemplo). DSLs externas são escritas em qualquer outra linguagem separada da linguagem do sistema e precisam de um compilador ou interpretador para serem executadas.

Os benefícios mais notáveis de construir DSLs são a melhoria na produtividade do desenvolvimento (porque o código da lógica de negócio é mais limpo e mais fácil de ser evoluído) e a melhoria na comunicação com os especialistas do domínio (porque as regras de negócio são escritas numa linguagem conhecida pelo especialista, facilitando o entendimento do código).

No entanto também existem uma série de problemas. É necessário ter muito cuidado para criar um design bom que possa ser evoluído ao longo do tempo. DSLs algumas vezes são extremamente complicadas de serem implementadas mas o impacto é muito positivo. Um exemplo real pode ser visto em um post que fiz há algumas semanas sobre uma Fluent Interface que implementei em um projeto, que trouxe vários benefícios interessantes.

Uma das formas mais comuns de se criar DSLs é o padrão que eles chamaram de “Framework Out-Language In”, onde você começa com a construção de um framework e em seguida define uma DSL em volta dele (como um Façade). Utilizar técnicas de Domain-Driven Design pode ajudar bastante pois evoluindo a Ubiquitous Language você enriquece a comunicação/vocabulário do sistema, que fatalmente irá colaborar para a criação de DSLs mais ricas e que refletem melhor ainda o domínio.

Não é nem preciso dizer que eles bateram muito forte na questão dos testes. Como a programação de DSLs é complexa, é essencial testar muito bem cada pequena parte e variação possível! Além disso técnicas de Test-Driven Development certamente ajudarão a criar DSLs mais fáceis de serem usadas (porque se não for fácil de usar você fez alguma coisa errada).

Na segunda parte da apresentação o Neal Ford apresentou um tutorial prático de como criar DSLs internas em Java, Groovy e Ruby.

Essa apresentação foi bem mão-na-massa e ensinou várias técnicas para criação de DSLs internas. Ele mostrou vários exemplos utilizando encadeamento e aninhamento de métodos fazendo wrappers em coisas conhecidas como Log4J e java.util.Calendar.

Na terceira e última parte o Fowler apresentou um tutorial sobre como projetar e quais ferramentas podem ser utilizadas para a criação de DSLs externas. Essa apresentação foi bem mais teórica que a do Neal.

Ele mostrou como fazer para criar um parser de sintaxe, que consiste em um “lexer” (um tokenizador de texto), um parser (analisador sintático que organiza os tokens em uma árvore), um analisador semântico (que checa as regras de construção das frases) e a produção de alguma saída (que significa produzir qualquer coisa útil, como popular certos objetos e fazer certas operações).

Domain Specific Languages é uma técnica muito antiga. Muito antes do próprio Fowler começar a escrever e estudar sobre o assunto várias DSLs já existiam por aí (o melhor e mais clássico exemplo é a linguagem SQL utilizada em bancos de dados).

A opinião dos dois é que DSLs realmente prometem trazer várias melhorias no desenvolvimento de software, especiamente no que diz respeito a programação das regras de negócio e interação com os especialistas de domínio. No entanto eles acham que não existirá um dia em que os programadores serão desnecessários e que tudo será feito a base de DSLs, tampouco que este seja um assunto que terá um boom enorme e que mudará a vida de todo mundo. Eles acham que trata-se simplesmente de mais uma técnica útil para desenvolver software de qualidade.