The Law of the Leaky Abstraction

Algum tempo atrás, buscando conteúdo interessante na internet, me deparei com o excelente artigo “The law of the leaky abstraction”. (lei da abstração sujeita a vazamentos em uma tradução livre – por falta de termos mais adequados, decidi usar a expressão na língua inglesa ao longo do texto.) Gostei tanto, que resolvi fazer dele tema do primeiro post no Java.lang.Blog.

Recomendo a todos que leiam o artigo, mas resumidamente, ele chama atenção para o fato de que as abstrações que criamos no mundo da informática, cujo objetivo em geral é encapsular determinada complexidade, acabam deixando, sobre determinadas circunstâncias, esta complexidade “vazar”, ou seja, acabamos tendo que lidar com a complexidade anyway. 

Desta forma, o autor propõe a law of the leaky abstraction, enunciada da seguinte forma:

“Toda abstração não trivial é, em certo grau, sujeita a vazamentos”

Não vou entrar aqui nas inúmeras abstrações das quais fazemos uso no ambiente da computação. De fato, o artigo faz isso muito bem (Não deixem de ler!). Gostaria, no entanto, de convidar os leitores a refletir sobre as abstrações que temos na plataforma JEE. Seriam elas também vítimas da law of the leaky abstraction?

Penso que sim. E para ilustrar, vou citar exemplos em duas tecnologias chaves da especificação JEE: JSF e EJB. Além disso, tenho certeza que o leitor será capaz de identificar outros “vazamentos” na plataforma JEE.

“Vazamentos” e Java Server Faces (JSF)

Como a maioria dos frameworks web, JSF tenta abstrair “detalhes” pertinentes ao desenvolvimento deste tipo de aplicações, como submissão de formulários e conversão de tipos. O framework quer nos fazer crer , por exemplo, que é possível simplesmente associar um método ou uma propriedade em um managed bean (server-side) ao clique de um botão ou valor de um input na interface (client-side).

Apesar de louvável, esta abstração é sujeita a “vazamentos”. O que acontece quando a propriedade no managed bean não é uma String? Alguma conversão é necessária. E se esta conversão falhar por algum motivo? Se o usuário resolver digitar “a#4%fg” em um input associado a uma propriedade Integer no managed bean? A não ser que o desenvolvedor tenha instruído o framework como notificar este tipo de falha, o usuário permanecerá clicando no botão e a página seguirá sendo re-exibida pelo browser. Nenhum método de nenhum managed bean é chamado no server-side. Perceberam o “vazamento”?

O desenvolvedor agora deverá infiltrar-se no complexo ciclo de vida JSF e entender, neste contexto potencialmente novo, como o framework processa conversões e como lidar com possíveis falhas.

“Vazamentos” e Enterprise Java Beans (EJB)

Apesar de ter saído de voga nos últimos tempos, uma das questões centrais da tecnologia, EJB é o suporte a sistemas distribuídos. Ainda que estejam rodando em uma máquina remota, clientes EJB são capazes de fazer chamadas a estes componentes como se fossem locais. A complexidade envolvida na chamada de método remota (RMI) é, portanto, abstraída pela tecnologia.

Essa abstração, no entanto, também é sujeita a "vazamentos" – e de uma forma bastante sutil: parâmetros as chamadas dos métodos de um EJB remoto devem ser serializable. Isso porque estes objetos deverão trafegar pela rede, sendo reconstruídos na máquina remota que abriga, de fato, o componente EJB. Desta forma, o fato que o componente EJB é remoto transparece na necessidade dos parâmetros de seus métodos serem obrigados a ser serializable, caracterizando o "vazamento".

Vale lembrar que este "vazamento" era mais visível nas primeiras versões da especificação, quando o cliente de um EJB era obrigado a tratar exceções checadas relacionadas a chamadas remotas (RemoteException e subclasses). Esse aspecto foi melhorado a partir da versão 3.0, substituindo as exceções checadas por equivalentes não checadas.

Consequências

Algumas consequências da law of the leaky abstraction:

1) Abstrações não nos ajuda tanto como imaginamos. Em uma ambiente onde se recorre tão constantemente a este recurso, isso é algo importante de se ter em mente.

2) Paradoxalmente, quanto mais camadas de abstração são criadas visando simplificar o desenvolvimento, mais difícil se torna a tarefa de se tornar um desenvolvedor proficiente. Esta talvez seja a consequência mais intrigante. Será que os esforços no sentido de simplificar o desenvolvimento na plataforma Java estariam tendo o efeito oposto do esperado?

3) Desconfie de ferramentas que prometem, como em um passe de mágica, simplificar o desenvolvimento e multiplicar a produtividade da equipe (alguém falou em geradores de código ai?). As abstrações nas quais estas ferramentas se baseiam certamente iram "vazar", e quando isto acontece, muitas vezes o custo é bastante alto.