Contract Programming /ou: Assinando contratos...

Lendo sobre Eiffel, uma das primeiras linguagens a usar a infra-estrutura .Net, encontrei um conceito interessante: Contract Programming ou Design by Contract (TM).

Com Contract Programming você detalha as interfaces de comunicação entre os componentes.

Traduzindo na prática: hoje, em C#, você tem algo como tipagem forte, assinatura de métodos, etc. Com Contract Programming, você ainda diz o que o seu método espera de entrada e força regras de saída, com verificação em compiler-time e run-time.

Um exemplo em Eiffel:



Forçando a barra, é possível fazer um "Argument Validation" dos parâmetros do método em .Net, usando ArgumentException, mas garantias de outputs ficam mais complicadas e é ai que o compilador do Eiffel quebra um galhão.

Eiffel não é a única linguagem a usar Contract Programming nativo. A linguagem "D" também o faz:



Essa história de escrever os requisitos no código não lhe parece familiar? Isso mesmo: TDD (ou BDD, como queira). Mas existe uma diferença básica. No TDD, "precondition" e "poscondition" são de responsabilidade do código de teste, enquanto em Contract Programming a responsabilidade é sempre do código que implementa a funcionalidade. Além disso, o TDD testa apenas algumas condições. Com Contract Programming as condições são verificadas todas as vezes que a função for executada.

Em vez de LINQ no C#, que vai trazer mais problemas que solução, eu prefiro algo que me ajude de verdade. Contract Programming entrou pra lista....