Bret Schuchert, da Object Mentor (a empresa de Uncle Bob), criou uma série de screencasts em que ele ensina conceitos de TDD, refatoração e design emergente enquanto desenvolve uma calculadora pós-fixada (do estilo da HP) em Java.
A série é muito boa. Bret é muito bem-humorado e tem bons insights de design durante os vídeos.
Abaixo está o primeiro vídeo e alguns pontos que achei interessantes.
Uma das partes que achei mais interessantes é quando ele renomeia a classe RpnCalculator deixando os nomes muito mais claros:
public class RpnCalculator {
@Test
public void NewCalculatorHas0InItsAccumulator { ... }
@Test
public void NewAccumulatorShouldAllowItsAccumulatorToBeSet { ... }
}
vira
public class ANewlyCreatedRpnCalculatorShould {
@Test
public void Have0InItsAccumulator { ... }
@Test
public void AllowItsAccumulatorToBeSet { ... }
}
Bret diz que a inspiração para a mudança de nome vem do BDD, metodologia que se preocupa muito com a maneira como as coisas são representadas no código. Realmente ajuda bastante.
Na mesma linha de raciocínio, há uma mudança muito interessante que Bret faz em um código que caminha na direção de um assert por teste e remove duplicação do código.
public class ANewlyCreatedRpnCalculatorShould {
private RpnCalculator calculator;
@Before
public void init(){
calculator = new RpnCalculator();
}
@Test
public void Have0InItsAccumulator{ ... }
@Test
public void AllowItsAccumulatorToBeSet{ ... }
@Test
public void AllowMultipleValuesToBeStored(){
BigDecimal value = new BigDecimal(42);
BigDecimal value2 = new BigDecimal(2);
BigDecimal value3 = new BigDecimal(3);
calculator.setAccumulator(value);
calculator.enter();
calculator.setAccumulator(value2);
calculator.enter();
calculator.setAccumulator(value3);
assertEquals(value3, calculator.getAccumulator());
calculator.drop();
assertEquals(value2, calculator.getAccumulator());
calculator.drop();
assertEquals(value, calculator.getAccumulator());
}
}
vira
public class ACalculatorWithThreeValuesShould{
private RpnCalculator calculator;
BigDecimal value = new BigDecimal(42);
BigDecimal value2 = new BigDecimal(2);
BigDecimal value3 = new BigDecimal(3);
@Before
public void init(){
calculator = new RpnCalculator();
calculator.setAccumulator(value);
calculator.enter();
calculator.setAccumulator(value2);
calculator.enter();
calculator.setAccumulator(value3);
}
@Test
public void HaveTheLastValueEnteredInItsAccumulator(){
assertEquals(value3, calculator.getAccumulator());
}
@Test
public void HaveTheSecondToLastValueAfterASingleDrop{
calculator.drop();
assertEquals(value2, calculator.getAccumulator());
}
@Test
public void HaveTheFirstValueEnteredAfterTwoDrops(){
calculator.drop();
calculator.drop();
assertEquals(value, calculator.getAccumulator());
}
@Test
public void Have0AfterThreeDrops(){
calculator.drop();
calculator.drop();
calculator.drop();
assertEquals(BigDecimal.ZERO, calculator.getAccumulator());
}
}
Ao mover um código que testava três coisas ao mesmo tempo para uma classe específica, Bret pôde fazer um único método que criou as fixtures para os demais testes. Assim, foi possível separar cada assert em um método com uma responsabilidade bem específica e melhorou bastante o design e a clareza do código.
Um outro momento interessante é quando Bret identifica inveja de funcionalidades na classe RpnCalculator em relação à classe Stack do Java. Esse mal-cheiro de código o faz discutir se a classe RpnCalculator está com responsabilidades demais. Então, Bret extrai a classe OperandStack (com os devidos testes antes), que fica responsável por utilizar a classe Stack.
Em um vídeo posterior, Bret adiciona as funções de adição, subtração e fatorial, sempre mudando a classe RpnCalculator para implementar essas operações. Ele diz que isso viola o princípio Open/Closed, que diz que entidades de software tem que ser abertas para extensão e fechadas para modificação. Para implementar uma operação de divisão na RpnCalculator, por exemplo, teríamos que modificar o código da classe. Então, Bret usa o pattern Strategy, e define uma interface chamada MathOperator para as operações e classes Add, Subtract e Factorial que implementam essa interface. É interessante notar que, ao invés de definir operandos diferentes para cada uma das operações, a interface recebe a pilha de números armazenados. Isso evita problemas na definição de uma mesma interface para operadores unários (fatorial) e binários (adição e subtração).
É interessante ver o ciclo red/green/refactor em ação. A parte mais rica, onde o aprendizado de software design mais acontece, é na refatoração. Mas sem o red/green, a refotaração não seria uma atitude responsável a ser tomada.
Mente de Iniciante 