Design By Contract! Afinal de contas isso ajuda?

“A confiança entre as pessoas é como um fio de cabelo ao encontro de uma navalha.”

Não é de hoje que vejo muitos desenvolvedores de software discutirem sobre Design By Contract (DBC) e se realmente é necessário sua utilização. Até mesmo entre meus estimados amigos de profissão quando temos nossas conversas filosóficas regadas de muito chopp e salgadinhos em algum bar perto do trabalho, vem à tona esse tema bastante popular ou impopular dependendo da perspectiva do observador. Já ouvi muitas pessoas dizerem que utilizar DBC é pura perda de tempo, pois não ajuda em nada e apenas atrapalha o desenvolvimento do software delegando atribuições a outras pessoas onde a própria pessoa que criou um método poderia estar fazendo. Outros dizem que não gostam de seguir os conceitos do DBC porque não confiam no outro desenvolvedor (tornando a frase inicial uma verdade) e que ele provavelmente fará besteira, ou seja, não validará a pré-condição e o sistema de alguma forma poderá ficar inconsistente.

Mas com todo esse blá blá blá, afinal de contas DBC ajuda ou não? Para responder essa questão é necessário que voltemos aos princípios/conceitos da orientação a objetos que prega que um objeto/método deve ser altamente coeso, com baixíssimo acoplamento para com isso promover um altíssimo reuso. Bem, sabemos que para atingirmos um alto grau de coesão precisamos que o objeto/método faça exatamente aquilo que ele foi criado para fazer e nada mais e para atingirmos um baixo grau de acoplamento devemos dividir as responsabilidades de determinadas tarefas entre os objetos/métodos (Padrão GRASP).

Além dos conceitos expostos acima, temos o princípio da Não-Redundância que prega que não deve existir repetição no tratamento de determinada situação, ou seja, em um método existente ou a condição dos parâmetros e do estado (atributos) do objeto está expressa em pré-condição ou deve ser tratada pelo próprio método, mas nunca em ambas. Infelizmente eu já me deparei com códigos exatamente assim, cuja equipe de desenvolvimento não utilizava DBC. Um método criado por um desenvolvedor criticava todos os parâmetros de entrada com as possíveis situações que não poderiam acontecer para o método funcionar e os métodos que chamavam esse método e que foram criados por outros desenvolvedores também faziam a crítica para não passar valores inválidos para os parâmetros. Dessa forma existiam os seguintes problemas: códigos redundantes, perda de tempo dos desenvolvedores por codificarem algo que já existia, os métodos deixaram de ser coesos, pois faziam coisas que não deveriam, o grau de acoplamento era maior do que deveria e o reuso desses métodos ficou prejudicado.

Muitos desenvolvedores ao se depararem com essa situação dão a desculpa de que o problema é resolvido com um refactory do código, mas a verdade é que desenvolvimento baseado em refactory pressupõe que o refactory exista devido as iterações e dos incrementos que foi exigido durante o processo de desenvolvimento (desenvolvimento iterativo e incremental) e não do refactory existir por causa de código que não segue as boas práticas do desenvolvimento.

Com os princípios/conceitos e problemas expostos acima, posso responder a pergunta e dizer que de fato DBC ajuda e muito. Humm ok, mas no que ajuda? Bem vamos lá de novo. Utilizando a pré-condição determinamos de quem é a responsabilidade de efetuar a crítica tanto dos parâmetros quanto do estado dos objetos antes da execução do método. Com isso temos como ganho métodos mais coesos, menos acoplados e com um alto grau de reuso e sem redundância de código. Utilizando a pós-condição damos a garantia para o método cliente de que todo o processamento será realizado sem problemas e o resultado será o mesmo que o esperado (firmado no contrato do DBC). E estabelecer esses contratos é de grande importância quando estamos lidando com o mundo corporativo, principalmente em projetos com arquitetura orientada a serviços (SOA) onde não existe mais aquela visão de aplicação monolítica e sim de serviços dos mais variados níveis trabalhando em conjunto para executarem um processo de negócio (Leia aqui sobre SOA). Esses serviços devem ser muito coesos, sem acoplamento entre eles e com o máximo de reuso dentro do negócio do cliente e DBC ajudará em muito nessa tarefa.

Outra ajuda muito importante que o DBC nos dá é sobre manter a invariante da classe que é outro conceito de orientação a objeto. A invariante é a verdade absoluta e imutável de uma classe durante toda sua existência e como exemplo podemos utilizar o objeto Quadrado. Sabemos que um quadrado é feito de quatro lados de tamanhos iguais e isso é imutável, ou seja, essa é sua invariante. Então podemos utilizar a pré-condição para que não seja passado nenhum valor que torne a invariante falsa e utilizar a pós-condição para garantir que a invariante permaneça verdadeira após a execução do método.

Porém, muitos já me perguntaram como é possível controlar se a pré-condição está realmente sendo validada, se todos os desenvolvedores de uma equipe estão fazendo as críticas necessárias? Para essa questão devemos utilizar de TDD (Test-Driven Development) exaustivamente, pois se uma pré-condição/pós-condição/invariante está sendo quebrada é porque o código contém erros e com o TDD será possível descobrir e consertar esses erros. Note que a validação do uso de DBC com TDD tem grandes chances de sucesso em um cenário (que chamo de DBC Inside Project) onde os desenvolvedores são da mesma equipe. Existe outro cenário (que chamo de DBC Outside Project) onde é muito complicado ter DBC no seu máximo uso, que é quando existe equipes diferentes de consultorias diferentes para projetos corporativos que se comunicam.

Muitos defendem a idéia de que é quase impossível colocar pré-condição e esperar que ela seja validada por quem deveria. De que nesse caso seria melhor criticarmos dentro do próprio método para não deixarmos o sistema/serviço ou até mesmo uma base de dados inconsistente. Esse é um cenário que ainda não tenho resposta, apenas digo que o bom senso é sempre bem vindo, ou seja, utilizar DBC sempre que possível porque com certeza ajuda e muito.

“Jolan True.”