As I mentioned in an earlier post, I believe in continually honing my programming skills through practice. My problem of choice is a database layer, code that allows for easy persistence of domain objects. I’ve built one of these several times, and each time it comes out quite a bit differently. It’s a good exercise in maturing a design through TDD.

Over the next umpteen blogs I’ll deliver on rebuilding this layer one more time. I don’t have a real application in mind, yet, so I’ll start with some simple presumptions. In lieu of an application, I’ll build specific persistence for a “user” object (a name and a password). Then I’ll add some complexity and repetitious application needs in order to flesh out a generalized solution.

First things first, I need a User class. Building that is simple enough. I usually drive crummy data classes through a quick creation test:

    import junit.framework.*;
    
    public class UserTest extends TestCase {
       private static final String name = "a";
       private static final String password = "b";
       private User user;
       
       protected void setUp() {
          user = new User(name, password);
       }
       
       public void testCreate() {
          assertEquals(name, user.getName());
          assertEquals(password, user.getPassword());
       }
    }

The implementation for that is easy enough. In trying to keep this and future blog posts short, I’ll always make the entire codebase available (once I get the project set up in CVS). The post will capture only key points and just enough code to make those points.

The next step is to design in the interface that drives persistence. Here’s a simple start:

       public void testPersist() {
          user.save();
          User retrievedUser = User.find(name);
          assertEquals(name, retrievedUser.getName());
          assertEquals(password, retrievedUser.getPassword());
       }

This brings up one of those age-old questions: do the save and find methods belong in the User class or elsewhere? Please drop your comments; I’m not going to worry about the answer until I have a second class that requires persistence services.

I can get this test to work by storing a saved user in a static-side User collection. Or, obnoxiously, since I only have one User, I can use the Monostate pattern (all state variables are static), and derive the retrieved user from the static fields. Either one is perfectly acceptable, and in the spirit of the “you ain’t gonna need it” mantra that XP diehards babble.

But I’m not going to do that. Or rather, I ain’t gonna do that. I have a specific business need, namely, real persistence. The story is, “data is not lost when the server restarts.” Good enough for me. I need persistence, and I can imagine there’s a story about reliability that suggests an RDBMS is the best place to start.

This is where I break from the XP purists: inevitable architectural decisions don’t always need to be test-driven. Yes, there’s some value to finding out where the tests and associated zealot refactoring will lead you. And sometimes, you’ll end up in a different spot, not even needing an RDBMS. But on rare occasions, you just know.

Enough for today, I’ve got to get the CVS project set up. Next I’ll work on getting my persistence test to pass.

Share your comment