thoughts on software construction

I can’t remember what bizzare series of clicks lead me there, but I just discovered an online copy of the original C-64 manual.  I flipped through it and relived all the emotions of entering and running every single one of the programs in it. I was 10 years old. One of my favorites was the bouncing ball program in Section 4 - Animation on pg. 30.

http://www.scribd.com/doc/40437/Commodore-64-Users-Guide

I’ve always thought that the ideal web development platform would be comprised of a dynamically typed language in the presentation tier supported by a statically typed language where the business and persistence logic lives. It just never made sense to me to use a statically typed language for building web user-interfaces considering that there’s very little gain to be had from type-safety.

The news today that Sun hired two key Python programmers makes me hopeful that they’re thinking what I’m thinking.

Dustin Bartlett, one of the developers on the team here at Point2, was just in my office asking me about Mock testing. It turned into an interesting discussion about when to use Mock objects and when not to. 

Ultimately I suggested he take a look at some of the material at xunitpatterns.com, a site developed by Gerard Meszaros while he was authoring the book xUnit Test Patterns. I was fortunate enough to be mentored by Gerard on several projects I worked on in Calgary, and have a tremendous amount of respect for him and his knowledge when it comes to testing software.

After looking at xunitpatterns.com Dustin and I realized the real question was what type of Test Double should be used. For the problem at hand, we decided to go with a Configurable Test Double. If you are stuck on a testing problem, or just want to improve your testing skills, I strongly recommend looking at Gerard’s site and picking up his book.

I just have to say, “I love Python!”

public void printPowers() {
    for (int r = 0; r < 100; r++) {
        int x = Math.pow(r, r);
        System.out.print(x);
        System.out.print(",");
    }
}

In Java - *with class definition and formatting left out

[r**r for r in range(100)]

In Python

Another thing I didn’t mention: The java implementation won’t work because int can’t store 99^99, but Python takes care of handling arbitrarily large numbers for you. It’s great.

Overview

Extract method is probably the refactoring I use most frequently. It is covered in detail in The Refactoring Book, so I’ll leave out many of the details here that the book covers. I strongly encourage anyone interested in refactoring to read this book and keep it close by as a reference. The intent of this post and of this series of daily refactorings is to introduce a set of commonly used refactorings and to spark discussion about concrete real-world experience with them.

I want to get people thinking about the importance of refactoring and how it impacts how we think about upfront design vs just-in-time design and the ways in which refactoring can help us avoid over engineering.

What is Extract Method?

A refactoring that moves code out of a method by creating a new method and delegating to it.

To illustrate, let’s start with some code that could benefit from applying extract method:

public BigDecimal calculateTotal(List<item> items) {
 
	// calculate sub total
	BigDecimal subTotal = new BigDecimal("0.00");
	for (Item i : items) {
		subTotal.add(i.getAmount());
	}
 
	// calculate tax
	BigDecimal taxRate = TaxRateHelper.getTaxRateForState(_user.getState());
	BigDecimal taxAmount = subTotal.multiply(taxRate);
 
	BigDecimal total = taxRate + taxAmount;
	total.setScale(2, BigDecimal.ROUND_HALF_EVEN);
 
	return total;
}

This code isn’t terrible by any stretch but it could be cleaned up by applying extract method. It’s easy to see that more than one thing is being done in this method. It is calculating a sub-total, tax amount, and total. Let’s extract these out as separate methods:

public BigDecimal calculateTotal(List<item> items) {
	BigDecimal subTotal = calculateSubTotal(items);
	BigDecimal taxAmount = calculateTaxAmount(subTotal);
	BigDecimal total = taxRate + taxAmount;
	total.setScale(2, BigDecimal.ROUND_HALF_EVEN);
	return total;
}
 
public BigDecimal calculateSubTotal(List<item> items) {
	BigDecimal subTotal = new BigDecimal("0.00");
	for (Item i : items) {
		subTotal.add(i.getAmount());
	}
	return subTotal;
}
 
public BigDecimal calculateTaxAmount(BigDecimal amount) {
	BigDecimal taxRate = TaxRateHelper.getTaxRateForState(_customer.getState());
	BigDecimal taxAmount = subTotal.multiply(taxRate);
	return taxAmount;
}

What impact did this refactoring have? What were some of the benefits?

• The original calculateTotal method is more cohesive and sticks to doing one thing.
• The comments that described what the different sections of code were doing are no longer required because the method name clearly documents what the code does.
• Each of the methods calculateTaxAmount and calculateSubTotal are no longer tightly coupled to calculateTotal and can be called independently.

Of all the benefits provided perhaps the one that I think has the most impact is that extract method increases cohesiveness and decreases coupling. The benefits of having a loosely coupled, highly cohesive system are well-worth the effort it takes to perform extract method, especially considering most modern development tools (such as ReSharper, IntelliJ, and Eclipse) support this refactoring.

Can you see any other refactorings that this code could benefit from?