Spring: A Developer's Notebook

Chapter 1. Getting Started

I'm a bona fide weekend extremist. I've done some pretty crazy things on a mountain bike, by layman's standards, and I love to kayak. I've been in serious trouble exactly once. I was on a river called the Piedra that I'd never run before, with new equipment and new techniques in my head. In kayaking, simplicity and speed are life, but I was tentative and slow. Instead of attacking the river, it attacked me, and I swam through three distinct class IV rapids, and was very lucky to emerge unscathed.

Note

Spring is the most popular of a new breed of so-called lightweight con-tainers. When you add all of the supporting frame-works, Spring is fairly hefty, but "lightweight" refers to all of the crud that usually accompanies code that you put into the container.

Building Two Classes with a Dependency

Many teachers and consultants write about dependencies like mayonnaise that's been left out in the sun too long, but if your application is to do anything interesting at all, it must have dependencies. The trick is to identify important dependencies, and deal with them in the right way. The way that you manage them will determine whether your application is easy to maintain, extend, and test. In this book, we'll do a mountain bike reservation system. A sports shop could use such a system for bike rentals. We'll start small, with all of the dependencies hardwired, to make sure that our infrastructure works. Then, we'll loosen the coupling with Spring, and progressively add persistence, a web-based presentation layer, declarative transactions, and other services.

For me, Spring style development is iterative. The first couple of labs are all about ramping up our infrastructure slowly. The first example will make sure that we have a working Java environment, and it will start to build our core model. Each of the first few examples ramp up one small part of your environment, making it easy to troubleshoot anything that might go wrong.

How do I do that?

Start with two classes in a single directory. One's a mountain bike, and the other is a registry that holds bikes. Call it a façade. You'll add bikes to the store within the façade constructor, and then print them all out using a third primitive class. (All of the classes shown in the book reside in a single package, com.springbook, unless otherwise specified.)

Example 1-1 shows the bike.

Example 1-1. Bike.java

public class Bike {
    private String manufacturer;
    private String model;
    private int frame;
    private String serialNo;
    private double weight;
    private String status;

    public Bike(String manufacturer, String model, int frame, 
                String serialNo, double weight, String status) {

        this.manufacturer = manufacturer;
        this.model = model;
        this.frame = frame;
        this.serialNo = serialNo;
        this.weight = weight;
        this.status = status;
    }

    public String toString( ) {
        return "Bike : " +
                "manufacturer -- " + manufacturer +
                "\n: model -- " + model +
                "\n: frame -- " + frame +
                "\n: serialNo -- " + serialNo +
                "\n: weight -- " + weight +
                "\n: status -- " + status +
                ".\n";
    }
    
    public String getManufacturer( ) { return manufacturer; }

    public void setManufacturer(String manufacturer) {
        this.manufacturer = manufacturer;
    }

    public String getModel( ) { return model; }

    public void setModel(String model) { this.model = model; }

    public int getFrame( ) { return frame; }

    public void setFrame(int frame) { this.frame = frame; }

    public String getSerialNo( ) { return serialNo; }

    public void setSerialNo(String serialNo) { this.serialNo = serialNo; }

    public double getWeight( ) { return weight; }

    public void setWeight(double weight) { this.weight = weight; }

    public String getStatus( ) { return status; }

    public void setStatus(String status) { this.status = status; }
}

Example 1-2 is the façade.

Example 1-2. RentABike.java

import java.util.*;
public class RentABike {

    private String storeName;
    final List bikes = new ArrayList( );

    public RentABike(String storeName) {
        this.storeName = storeName;
        bikes.add(new Bike("Shimano", "Roadmaster", 20, "11111", 15, 
                           "Fair"));
        bikes.add(new Bike("Cannondale", "F2000 XTR", 18, "22222",12, 
                           "Excellent"));
        bikes.add(new Bike("Trek","6000", 19, "33333", 12.4, 
                           "Fair"));
    }

    public String toString( ) { return "RentABike: " + storeName; }

    public List getBikes( ) { return bikes; }

    public Bike getBike(String serialNo) {
        Iterator iter = bikes.iterator( );
        while(iter.hasNext( )) {
            Bike bike = (Bike)iter.next( );
            if(serialNo.equals(bike.getSerialNo( ))) return bike;
        }
        return null;
    }
}

Finally, Example 1-3 is the view.

Example 1-3. CommandLineView.java

import java.util.*;
public class CommandLineView {
    private RentABike rentaBike;
    public CommandLineView( ) {rentaBike = new RentABike("Bruce's Bikes"); }

    public void printAllBikes( ) {
        System.out.println(rentaBike.toString( ));
        Iterator iter = rentaBike.getBikes( ).iterator( );
        while(iter.hasNext( )) {
            Bike bike = (Bike)iter.next( );
            System.out.println(bike.toString( ));
        }
    }

    public static final void main(String[] args) {
        CommandLineView clv = new CommandLineView( );
        clv.printAllBikes( );
    }
}

Next, you'll compile the application, like this:

C:\RentABikeApp\src> javac -d ../out *.java

Your output directory now contains the compiled class files.

Directory of C:\RentABikeApp\out

07/28/2004  10:12 AM    <DIR>          .
07/28/2004  10:12 AM    <DIR>          ..
07/28/2004  10:10 AM             1,753 Bike.class
07/28/2004  10:10 AM             1,431 RentABike.class
07/28/2004  10:10 AM               940 CommandLineView.class

Run the application like this:

C:\RentABikeApp\out> java CommandLineView

RentABike: Bruce's Bikes
Bike : manufacturer -- Shimano
: model -- Roadmaster
: frame -- 20
: serialNo -- 11111
: weight -- 15.0
: status -- Fair.

Bike : manufacturer -- Cannondale
: model -- F2000 XTR
: frame -- 18
: serialNo -- 22222
: weight -- 12.0
: status -- Excellent.

Bike : manufacturer -- Trek
: model -- 6000
: frame -- 19
: serialNo -- 33333
: weight -- 12.4
: status -- Fair.

What just happened?

Nothing good. The current design is simple, but it's also hardwired. You can immediately see several problems:

• The façade layer (RentABike) statically creates the bikes in the store, so whenever any new bike comes in (yeah!) or a customer totals one on the mountain (boo!), you've got a code change.

• This model will also be difficult to test, because the set of bikes is fixed.

• The user interface and the façade are tightly coupled. You see a hardcoded dependency between the façade layer and the user interface.

Note

The fundamental design pattern in Spring, and all other lightweight containers, is based on the idea of loosening coupling between dependencies.

• The code base is not organized, and the build is not automated.

But we're willing to take some short cuts to get the Java base working, and the underpinnings of the application under way. We'll decouple and automate in the next example.

What about...

...rolling up the whole burrito all at once? You might decide to install Spring, Hibernate, Java, Ant, and JUnit all at the same time. It's been my experience that if you control one variable at a time, you actually save time, especially as you're establishing your foundation. Once you've got all of your tools installed and working, then you can collect many of these steps into one.