O grande questão a se responder é, estas tecnologias são suficientes para resolver os problemas que temos atualmente? Java e C# com suas implementações de Orientação a Objetos são suficientes para resolver nossos problemas como desenvolvedores?

Em uma apresentação na TSS Barcelona, Martin Fowler e Neal Ford propõem uma nova abordagem para construção de software.Em vez de utilizarmos as técnicas de modelagem padrão de hoje, baseadas em hierarquias de objetos, o principal mecanismo de abstração seria a própria linguagem.  Eles acreditam que nossa atual camada de abstração (baseada hierarquias para modelar o mundo) tem falhado em alguns momentos.  E é justamente nestas falhas que utilizamos coisas que aumentam ainda mais a complexidade,  e nesta apresentação eles citam aspectos como exemplo. Se o fato de construir software é justamente tentar controlar a complexidade, por que estamos adicionando mais complexidade para resolver nossos problemas?

Se olharmos para trás, vamos reparar que nossa camada de abstração tem evoluído várias vezes. No início assembly era utilizado para construir programas de computador, mas atualmente, ninguém escreve mais nada em assembly, isto porque ela tem um baixo nível de abstração.Este fato faz com que a construção de qualquer coisa seja demorada. Os mecanismos de abstração servem para facilitar nosso trabalho como desenvolvedores de software, e é natural que sempre tentamos encontrar um nível de abstração mais adequado. Os paradigmas de desenvolvimento atuais tentam fazer isso. Orientação a Objetos ocupa um lugar muito importante atualmente e a idéia não é criar um novo paradigma, mas sim dar um passo adiante e focar na linguagem.

Já não é novidade que estamos sempre preocupados com a clareza e objetividade no momento da escrita de um código. Esta necessidade não é do compilador, esta é uma necessidade nossa como desenvolvedores. Fowler diz que a verdadeira arte de escrever programas de computador não é comunicar com a máquina, mas comunicar com outros programadores que precisam ler nosso código o tempo todo. Se observarmos, o tempo todo estamos preocupados (ou deveríamos estar, rs) com os nomes de variáveis, de métodos e de classes, que expressem de maneira mais clara possível nossa intenção.  Estes nomes formam um vocabulário.
Quando nós conversamos com outra pessoa, nós utilizamos um vocabulário, mas se não pensarmos em uma forma de combinar as palavras, é possível que esta pessoa não nos entenda.
É esta forma de combinar as palavras que é o foco da nova camada de abstração baseada na linguagem, sugerida por Fowler e Neal Ford.

Se pensarmos em palavras soltas, elas podem até significar algo, mas semanticamente não querem dizer muita coisa. Vamos imaginar o seguinte exemplo:

Autor Livro Assunto

Da forma como está escrito, estas palavras podem ser utilizadas de várias formas, em várias combinações.

Um Autor escreve um Livro com Assunto política.

Esta frase já tem algum sentido. Repare como combinamos as palavras para expressar nossas idéias.  Esta é a forma como nós comunicamos.

Quando utilizamos orientação a objetos para modelar o mundo, nós conseguimos montar um vocabulário. Autor, Livro, Assunto, são exemplos de palavras que fazem parte deste vocabulário. Mas OO não nos ajuda a criar uma gramática sobre este vocabulário, e é aí que entram as DSLs. O que Fowler e Ford sugerem é parar de pensar unicamente no vocabulário e passar a ter a noção de linguagem, que combina vocabulário com gramática.

A justificativa para a utilização da linguagem como mecanismo de abstração é a falta de contexto. Quando programamos não temos a noção de contexto. Contexto é um conceito muito importante na nossa comunicação. Quando você fala com um amigo: “Fluminense vai contratar Ronaldinho”, vc não precisar dizer pra ele que Fluminense é um time de futebol, e que Ronaldinho é um grande jogador de futebol e ainda que times de futebol contratam bons jogadores. Isto está implícito. É diferente quando precisamos dizer isto para alguma API no nosso código. Vou tentar exemplificar:

Time fluminense     = new Time(“Fluminense”);
Jogador ronaldinho = new Jogador(“Ronaldinho”);
Ronaldinho.setQualidade(“Excelente”);
Contratacao contrato = new Contrato();
contrato.setTime(fluminense);
contrato.setJogador(ronaldinho);
contrato.setValor(10.000.000,00);

Bom não sei se foi o melhor exemplo, mas reparem que todas as vezes precisamos explicitamente dizer: Fluminense é um time; Ronaldinho é um jogador; Ronaldinho tem uma qualidade excelente; Existe um contrato entre fluminense e Ronaldinho. Isto porque quando falamos com uma api e frameworks eles não tem qualquer noção de contexto, temos que começar no mais baixo nível possível para explicar em detalhes o que queremos que eles façam.
Agora vamos tentar utilizar a linguagem para escrever este mesmo código:

      AlgumTime(“fluminense”)
                     .estabeleceUmContratoCom(“Ronaldinho”)
                     .noValorDe(10.000.000,00);

Observem, fizemos uma combinação de palavras (vocabulário) com uma gramática, o que forneceu para o leitor deste código (apesar do ruído da sintaxe da linguagem) uma expressão bem mais clara do que a anterior. No código acima o contexto (Contratação de jogador) está implícito, com isso evitamos repetir o código de configuração dos objetos, tornando muito mais legível e expressivo.

É importante destacar que nós não vamos desenvolver um sistema todo utilizando DSLs, provavelmente você vai utilizar uma linguagem como java ou c# e várias DSLs . Na minha opinião, esta técnica deverá ser utilizada na construção de APIs e Frameworks. Uma API disponibiliza um vocabulário, as DSLs adicionam a gramática formando assim uma linguagem, que é muito mais expressiva e legível.

Existem algumas técnicas para construção de DSLs, mas isso vai ficar para um próximo post.

Até mais..
Luiz Costa