Infelizmente a maioria dos programadores que conheço nunca ouviram falar sobre ortogonalidade no desenvolvimento de software, embora este seja um principio fundamental para se escrever código de qualidade.

Em desenvolvimento de software, o termo ‘ortogonalidade’ passou a significar uma espécie de independência ou dissociação. A ideia é que componentes que conceitualmente não estão relacionados devem ser construídos de forma a não possuírem nenhuma dependência entre si. Adicionar um novo atributo a um objeto do ActiveRecord (na maioria das vezes) não deveria exigir uma alteração na interface com o usuário, por exemplo.

Em linguagens orientadas a objetos é muito fácil acrescentar dependências ao código. Em Ruby basta um simples ‘require‘ e seu projeto passa a depender de uma ou várias bibliotecas. Talvez devido a essa simplicidade este tende a se tornar um problema viral, já que nos estimula a estarmos sempre adicionando mais e mais dependências em nossos sistemas.

Queremos projetar componentes auto-suficientes e com um único propósito bem definido. Sistemas não ortogonais são difíceis de alterar. Em projetos onde seus componentes dependem uns dos outros não existem correções pontuais. Uma correção pode levar a um ou mais problemas em outra parte. E isto pode se tornar um ciclo sem fim.

Por outro lado, em sistemas onde os componentes são isolados uns dos outros, desde que você não mude a sua interface pública, você sabe que pode alterar um deles sem se preocupar com os outros.

Os ganhos em produtividade ao colocar em prática este principio são imensos. Uma abordagem ortogonal promove a reutilização. Como seus componentes serão bem específicos e com responsabilidades bem definidas é fácil reaproveitá-los em outros sistemas. Outro fator importante é que por possuírem apenas o código necessário para cumprir uma única tarefa, obviamente estas bibliotecas serão menores e mais simples de serem projetadas, implementadas, testadas e dificilmente precisaremos revisita-las para adicionar novas funcionalidades ou fazer correções.

O fato de serem componentes menores e com menos código também simplifica a criação de testes. E mesmo que um bug passe despercebido ele não será tão critico, pois o tempo de resolução será menor e a chance de o problema se espalhar por todo o sistema são mínimas, o que diminui os riscos.

Vamos considerar como exemplo o desenvolvimento de um e-commerce. O requisito original previa apenas uma interface web simples, mas as exigências foram alteradas para também contemplar uma interface web para telefones celulares e para compras através de uma central telefônica. Em um sistema projetado ortogonalmente, você precisaria alterar apenas os módulos associados com a interface do usuário para lidar com isso. Se o seu sistema foi bem estruturado, você deveria ser capaz de suportar todas essas interfaces com o mesmo código criado inicialmente para realizar as vendas. O paradigma MVC utilizado no Ruby on Rails funciona bem nestas situações.

Testes unitários são uma ótima forma de verificar a ortogonalidade de um componente. Se para realizar o teste é necessário carregar ou acessar uma grande quantidade de outras bibliotecas, então você encontrou um módulo que não está bem dissociado do resto do sistema. Outra forma menos interessante de realizar esta avaliação é ao corrigir bugs. Quando você faz uma alteração, outros problemas surgem misteriosamente? Esta é uma evidência de que seu código não é ortogonal.

Ortogonalidade está intimamente relacionado com o princípio DRY (veja mais aqui e aqui). Enquanto DRY visa minimizar a duplicação dentro de um sistema, com a ortogonalidade você reduz a interdependência entre os componentes do sistema. Utilizar estes dois princípios combinados tornará nossos projetos muito mais flexíveis e fáceis de manter.

---

Este artigo é descaradamente ‘baseado’ no capítulo de mesmo nome do livro The Pragmatic Programmer.