Se você programa em alguma linguagem de programação orientada a objeto, com certeza conhece os termos “Private”, “protected” e “public” e muito provavelmente sabe para que eles servem. Métodos ou membros públicos são aqueles que podem ser acessados por outras classes, os protegidos apenas pelos descendentes e os privados só possuem visibilidade local, ou seja, dentro da própria classe. Parece simples, porém, é muito comum encontrar programadores que parecem não seguir critério algum ao definir o nível de visibilidade dos membros de suas classes, ou então aplicam alguma metodologia aleatória para este fim. Propriedades que eram protegidas são publicadas durante o desenvolvimento de outras classes clientes, conforme a necessidade. Classes “amigáveis” (class friendly) são criadas para permitir acesso a funções protegidas. Práticas como essas acabam por criar uma arquitetura extremamente confusa, com componentes de difícil entendimento, difíceis de serem testados e expandidos. Qual seria então o melhor critério para evitar esse tipo de problema?

Ao desenhar uma classe devemos ter uma ideia bem clara de qual a responsabilidade dela, caso contrário, coloque em dúvida a necessidade de criá-la. O raciocínio é simples: se não sabemos o que a classe deve fazer, então não precisamos dela. Após a definição clara de qual é a responsabilidade da classe, levando em consideração a coesão e nível de acoplamento desejado, devemos pensar sobre a sua interface. Para entender melhor, basta imaginar como a classe deve ser vista por suas classes clientes, ou seja, as classes ou componentes que irão utilizá-las. Apenas métodos e propriedades que permitam acesso e manipulação de dados relacionados à responsabilidade da classe devem ser públicos. Você deve fazer isso não para impedir que outros acessem dados internos de suas classes, mas, principalmente, para garantir que elas sejam mais legíveis, inteligíveis e fáceis de usar. O ideal é que qualquer programador do mundo possa, apenas lendo os métodos públicos de sua classe, dizer qual a responsabilidade dela, e quais métodos chamar, e como chamá-los para conseguir usufruir de suas funcionalidades. Se você não se preocupar em publicar apenas o que for necessário, sua classe corre o risco de ficar confusa demais e difícil de utilizar.

Uma analogia com o mundo real pode ajudá-lo a entender melhor esse raciocínio: imagine um carro onde, junto com os pedais de freio e embreagem, tivessem outros controles estranhos, como um pedal pra regular o nível do óleo e outro para ativar e controlar a bomba de gasolina. Esse carro faria com que o condutor ficasse bem confuso, e tentasse regular o consumo de gasolina manualmente enquanto dirige (um absurdo, não?).

Voltando ao mundo dos bits, por exemplo, se sua classe possuir uma coleção de itens, seria bom deixar claro se ela é dona deles e apenas ela deve poder removê-los ou incluí-los em seu container. Para isso, não disponibilize em sua interface métodos que dão acesso direto a lista, procurando sempre usar o encapsulamento onde for necessário e disponibilizando um iterador.

Se ela exigir passagem de parâmetros de inicialização, providencie construtores personalizados, onde a classe cliente possa passar os parâmetros necessários. Esse tipo de design facilita a leitura e entendimento de quem a for utilizar.

Tenha sempre esse conceito em mente: as classes clientes visualizam apenas os métodos publicados, e devem – apenas se baseando no que enxergam – entender a responsabilidade e como usar os recursos da classe servidora. Algumas ferramentas muito importantes, como o TDD (desenvolvimento orientado a testes) são extremamente eficazes e – se usadas corretamente – funcionam automaticamente como guias forçando o desenvolvedor a escrever uma interface simples e fácil de usar. Pretendo escrever um artigo sobre esse tema relacionado ao TDD em breve. Até lá.

Se você e sua equipe são adeptos do scrum ou outra metodologia ágil provavelmente devem conhecer ou utilizar testes unitários, mas não necessariamente o desenvolvimento orientado a testes (TDD). O teste unitário consiste basicamente em validar dados válidos e inválidos via entrada e saída, já o TDD utiliza teste unitário como parte de sua metodologia cujo principal objetivo não é testar as unidades (é um dos objetivos, mas não o único).

Em um cenário de desenvolvimento ágil, sem uso de TDD, o programador geralmente não conta com um modelo de classes em forma de diagramas – como outras metodologias pesadas. Por isso é comum a modelagem ser feita apenas mentalmente, em algum outro formato (rascunho em papel de pão?) ou até mesmo diretamente no código. As classes, operações e atributos vão surgindo conforme a necessidade, e são constantemente alterados e implementados até a conclusão da tarefa associada. Eventualmente, alguns testes de unidade são implementados baseando-se nas classes já prontas.

Este tipo de abordagem implica em alguns problemas, entre eles:

• o programador não tem segurança em saber quando uma implementação acabou;
• o programador não precisa implementar a classe de forma que ela fique desacoplada das demais;
• o programador tende a não desenvolver para a interface e sim para a implementação;
• métodos não coesos (fazem mais ou menos do que deveriam fazer);
• nomes de atributos e operações não representam adequadamente a funcionalidade.

O TDD pretende resolver todas as deficiências citadas acima e várias outras. Mas, o que é o TDD? TDD ou Test Driven Development pode ser considerada uma metodologia de design de software, onde escrevemos primeiro um teste e depois o código necessário para o teste passar. A idéia é que o desenho das classes seja guiado pelos testes. O TDD força o desenvolvedor a pensar primeiro em o que ele precisa, e em como fazer, via teste unitário, para testar se a implementação a ser feita fará o que deve, nada mais e nada menos. Com isso, se ganha em vários aspectos:

• as classes devem ser desacopladas, senão o teste não pode ser executado;
• os métodos são bem coesos, ou seja, fazem somente o necessário para o teste passar;
• o programador sabe exatamente quando concluiu uma implementação, pois o teste passou;
• o programador consegue validar rapidamente uma alteração que pode ter causado um impacto em outras unidades, apenas rodando um conjunto de testes;
• operações e atributos possuem nomes claros e representam exatamente o que fazem.

O workflow do TDD pode ser descrito basicamente em cinco passos básicos:

1. Crie a classe de teste e o primeiro teste
   1. Nesse ponto o programador deve pensar em como será a assinatura do método testado. O fato de ter que escrever um teste para o método, faz com que, tanto o nome quanto os parâmetros de entrada e saída sejam bem claros e coesos.
2. Compile o teste
   1. O teste não vai compilar. Neste momento, crie a classe e a declaração do método. Recompile e rode o teste. O teste deve falhar, pois o método testado ainda não está implementado.
3. Implemente o código testado de modo que o teste falhe
   1. O objetivo do teste é detectar defeitos, e essa fase é importante para averiguar se o teste está cumprindo seu papel. Geralmente codificar para que o método testado retorne um valor errado é o suficiente. Rode o teste e veja o teste falhar.
4. Agora corrija o código, de forma que o teste passe
   1. Implemente o suficiente para o teste passar. Você deve garantir que o teste exija o suficiente. Se precisar implementar mais do que o necessário para o teste passar, provavelmente seu teste não está bom o suficiente, ou seu método não está coeso. Neste caso, refaça o teste ou corrija a implementação do código testado.
5. Faça alguma refatoração necessária e reexecute os testes
   1. Na fase anterior nos preocupamos apenas em fazer o teste passar. Nessa etapa, faça uma revisão no código e veja se precisa de alguma refatoração. Em seguida rode todos os testes construídos até agora para certificar-se de que a refatoração não quebrou algum outro código.

Antes que me perguntem: TDD não é burocrático e demorado?.  Não. Usar TDD não implica em aumentar o tempo de desenvolvimento. Desconsiderando o tempo de adaptação de sua equipe, a tendência é que o desenvolvimento com TDD aumente consideravelmente a produtividade, e, consequentemente, a segurança e qualidade dos produtos desenvolvidos. Essa é a experiência de quase toda equipe de aderiu ao TDD, e provavelmente sua equipe só vai se sentir confortável com a idéia quando efetivamente aplicar os conceitos da metodologia.

Neste artigo não abordei as ferramentas de teste unitário, pois não é o foco do TDD, porém praticamente todos os ambientes de desenvolvimento moderno possuem algum framework de testes unitários. Posso citar alguns: NUnit (C#), DUnit (Delphi) e JUnit (Java). Escolha o que melhor se adequar a sua realidade.