A Note Regarding Supplemental Files

Chapter 9. Iterating and Testing: The Software is Still for the Customer

It’s time to show the customer how much you really care. Nagging bosses? Worried clients? Stakeholders that keep asking, “Will it be done on time?” No amount of well-designed code will please your customers; you’ve got to show them something working. And now that you’ve got a solid OO programming toolkit, it’s time to learn how you can prove to the customer that your software works. In this chapter, we learn about two ways to dive deeper into your software’s functionality, and give the customer that warm feeling in their chest that makes them say, Yes, you’re definitely the right developer for this job!

Your toolbox is filling up

We’ve learned quite a bit so far, and our toolbox of analysis and design tools is getting pretty full. We even added some OO programming techniques in the last chapter:

But you’re still writing your software for the CUSTOMER!

All the tools and techniques you’ve been learning are terrific... but none of them matter if you don’t use them to produce great software that makes your customer happy.

And most of the time, your customer won’t care about all the OO principles and diagrams you create. They just want the software to work the way that it’s supposed to.

Joe: Yeah, maybe we shouldn’t have spent all this time on so many diagrams, and all this architecture stuff. We’ve got nothing to show Gary except a bunch of ovals with things like “Play Game” written inside them.

Frank: Come on guys, we’ve got a lot more done than that. It’s going to be simple to finish up the Board class, because we’ve already got a start on writing a lot of that functionality.

Jill: Well, sure, but that’s the only class we’ve written any code for. How are we supposed to show that to Gary?

Joe: Well, I guess we could write the Unit class pretty easily, since we did that class diagram. So it wouldn’t take a lot more time to write the code for that class.

Frank: Exactly. And, really, we know how to write all of these classes. We can just take each class, or even an entire package, and apply all those OO principles and analysis and design techniques to each chunk of functionality.

Jill: But we’ve got to work on functionality now. We don’t have time for a bunch more big-picture analysis and design.

Frank: But that’s just the thing, Jill: we don’t need to change what we’re doing, we just need to iterate deeper.

Joe: Iterate deeper? What does that mean?

Frank: It just means we keep doing analysis and design, but now on each individual part of Gary’s game system framework.

Jill: And as we build up the application, we’ll have lots of pieces working that we can show to Gary, right?

Joe: And we get to use all these tools we’ve got to make sure the software is well-designed, too, right?

Frank: Exactly. But first, we’ve got a choice to make...

You write great software iteratively.
Work on the big picture, and then iterate over pieces of the app until it’s complete.

Iterating deeper: two basic choices

When it comes to developing software, there is more than one way to iterate into specific parts of your application. You’ve got to take on smaller pieces of functionality, but there are two basic approaches to figuring out which small pieces to work on—and even what a “small piece” means in terms of your application.

You can choose to focus on specific features of the application. This approach is all about taking one piece of functionality that the customer wants, and working on that functionality until it’s complete.

Both approaches to iterating are driven by good requirements.

Feature Ahead

Feature driven development

...is when you pick a specific feature in your app, and plan, analyze, and develop that feature to completion.

Because requirements come from the customer, both approaches focus on delivering what the customer wants.

You can also choose to focus on specific flows through the application. This approach takes a complete path through the application, with a clear start and end, and implements that path in your code.

Note

Use case driven development

...is when you pick a scenario through a use case, and write code to support that complete scenario through the use case.

You’ll often see the terms “flow” and “scenario” used interchangeably.

Feature driven development

When you’re using feature driven development, you work on a single feature at a time, and then iterate, knocking off features one at a time until you’ve finished up the functionality of an application.

Use case driven development

With use case driven development, you work on completing a single scenario through a use case. Then you take another scenario and work through it, until all of the use case’s scenarios are complete. Then you iterate to the next use case, until all your use cases are working.

Two approaches to development

There’s just one basic way to write code, isn’t there? Well, there are actually a ton of different ways to go about iterating deeper and finishing up parts of your application. Most of these different approaches fall into the two basic categories we’ve been looking at, though. So how do you decide which to use?

What’s the difference between feature driven and use case driven development?

Feature driven development is more granular	Use case driven development is more “big picture”

Works well when you have a lot of different features that don’t interconnect a whole lot.	Works well when your app has lots of processes and scenarios rather than individual pieces of functionality.
Allows you to show the customer working code faster.	Allows you to show the customer bigger pieces of functionality at each stage of development.
Is very functionality-driven. You’re not going to forget about any features using feature driven development.	Is very user-centric. You’ll code for all the different ways a user can use your system with use case driven development.
Works particularly well on transactional systems, where the system is largely defined by lengthy, complicated processes.	Works particularly well on systems with lots of disconnected pieces of functionality.

Welcome to Name That Approach! Below are several statements, and each one is about a particular approach to iterating over parts of your system. Your job is to figure out which approach each statement refers to. Note that sometimes, a statement might apply to both approaches.

	Use Case Driven	Feature Driven
This approach deals with really small pieces of your application at a time.
This approach lets you focus on just a part of your application at a time.
This approach is all about a complete process in your application.
Using this approach, you can always test to see if you’ve completed the part of the application you’re working on.
When you use this approach, your focus is on a diagram, not a list.

	Use Case Driven	Feature Driven
This approach deals with really small pieces of your application at a time.
This approach lets you focus on just a part of your application at a time.
This approach is all about a complete process in your application.
Using this approach, you can always test to see if you’ve completed the part of the application you’re working on.
When you use this approach, your focus is on a diagram, not a list.

Let’s use feature driven development

Since Gary’s losing patience, let’s go with feature driven development. We can take just a single feature and work it through to completion, and it shouldn’t take as much time as it would to write the code to support an entire use case.

Anytime you’ve got a customer impatient to see results, you should consider feature driven development, and starting with a feature you’ve already done some work on.

Brain Power

If you decided to go with use case driven development, what would you start working on first?

Analysis of a feature

Once you’ve decided on a feature to start with, you’ve got to do some more analysis. Let’s start with what we had written down on the feature list:

3. The framework supports multiple types of troops or units that are game-specific

Note

Here’s what we’ve got so far... but this is still a pretty generic description of what we need to code.

We also have the start of a class diagram, from Chapter 7:

It looks like we’ve got everything we need to start coding, right? To help us make sure we haven’t forgotten anything, let’s go back to using some textual analysis.

We don’t have a use case to analyze, but we can revisit the vision statement for Gary’s games, and see if we’re covering everything that Gary wanted his units to do.

Gary’s Games provides frameworks that game designers can use to create turn-based strategy games. Unlike arcade-style shoot-’em-up games and games that rely on audio and video features to engage the player, our games will focus on the technical details of strategy and tactics. Our framework provides the bookkeeping details to make building a particular game easy, while removing the burden of coding repetitive tasks from the game design.

Note

Here’s Gary’s vision statement, from way back in Chapter 6.

The game system framework (GSF) will provide the core of all of Gary’s Games. It will be delivered as a library of classes with a well-defined API that should be usable by all board game development project teams within the company. The framework will provide standard capabilities for:

Defining and representing a board configuration
Defining units and configuring armies or other fighting units
Moving units on the board
Determining legal moves
Conducting battles
Providing unit information

The GSF will simplify the task of developing a turn-based strategic board game so that the users of the GSF can devote their time to implementing the actual games.

Compare the class diagram for Unit with this vision statement. Are there things missing from our class diagram?

What else might Gary expect to see when you say, “I’m done with writing code for the units in your framework?”

Fleshing out the Unit class

In our class diagram, all we’ve really figured out is how to represent the properties of a unit. But in Gary’s vision statement, he’s expecting his game system framework to support a lot more than just those game-specific properties.

Note

This makes sense, because the key feature we were focusing on in Chapter 7 was not the entire Unit class, but just game-specific properties of a Unit.

Here are the things we came up with that Gary is expecting units in his framework to do:

Each unit should have properties, and game designers can add new properties to unit types in their own games.
Note
Our class diagram is focused on this particular aspect of the Unit class right now.
Units have to be able to move from one tile on a board to another.
Note
You should have some ideas about how to handle this from our work on a related key feature back in Chapter 7.
Units can be grouped together into armies.
Note
These new features are all pulled straight from Gary’s vision statement.

Showing off the Unit class

We worked on supporting game-specific units, and how to store the properties of a Unit, back in Chapter 7. But Gary wants more than a class diagram before he’s convinced you’re getting any work done.

Your customers want to see something that makes sense to them

Your customers are used to seeing computer programs run on a computer. All those diagrams and lists may help you get on the same page with them in terms of requirements and what you’re supposed to build, but you’re going to need more than that before they think you’ve built anything useful.

You need to come up with some test scenarios that you can show to your customer, which will prove that your code works, and that it behaves like your customer expects it to.

Writing test scenarios

Note

Be careful... this “scenario” isn’t the same as the “scenario” we’ve been talking about in a use case scenario.

Test cases don’t have to be very complex; they just provide a way to show your customer that the functionality in your classes is working correctly.

For the properties of a unit, we can start out with a simple test scenario that creates a new Unit, and adds a property to the unit. We could just show our customer a running program that displays output like this:

Scenario #2: Changing property values

We decided to test setting, and then changing, the value of a property. If the hitPoints property is set, for example, and then set again, getting the value of hitPoints should return the most recent value for that property:

Scenario #3: Getting non-existent property values

For our third scenario, we decided to test what would happen when you tried to retrieve the value of a property that had never been set. Error conditions like this crop up all the time, and we don’t want our program crashing every time a game designer makes a small typo or mistake in their code. Here’s what we did to test this:

You should test your software for every possible usage you can think of. Be creative!
Don’t forget to test for incorrect usage of the software, too. You’ll catch errors early, and make your customers very happy.

Q:
Q: We don’t have any code written yet. Aren’t we doing things a bit backwards by worrying about tests right now?
A:
A: Not at all. In fact, if you know what tests you’re going to use before you write your code, it’s easy to figure out what code you’re going to need to pass those tests. With the three test scenarios we just developed, it should be pretty simple to write the Unit class, and the tests tell us exactly how our code should behave.
Q:
Q: Isn’t this just test driven development?
A:
A: For the most part, yes. Formally, test driven development focuses on automated tests, and usually involves a testing framework like JUnit. But the idea of writing test cases, and then writing the code that will pass the test, is the core idea behind test driven development.
Q:
Q: So are we using test driven development or feature driven development? I’m confused...
A:
A: Both. In fact, most good software analysis and design mixes lots of different approaches. You might start with a use case (use case driven development), and then choose just a small feature in that use case to start working on (which is really a form of feature driven development). Finally, you might use tests to figure out how to implement that feature (feature driven development).
Q:
Q: Why are the tests so simple? I expected something a little fancier.
A:
A: You want to keep your tests simple, and have them test just a small piece of functionality at a time. If you start testing multiple things at once, it’s hard to tell what might have caused a particular test to fail. You may need a lot more tests, but keep each one focused on a very specific piece of functionality.
Q:
Q: And each test makes sure a single method in the class works correctly, right?
A:
A: No, each test really focuses on a single piece of functionality. That might involve one method, or several methods. For example, you can’t test setting a property’s value (which uses setProperty()) without getting that property’s value as well (using getProperty()). So it’s one piece of functionality—setting a property—but it takes two methods.
Q:
Q: Can you explain why you tested getting a property that you didn’t set? Isn’t that testing the wrong way to use the Unit class?
A:
A: Testing incorrect usage of your software is usually at least as important as testing it when it’s used properly. Game designers could easily mistype a property name, or write code that expects some other piece of a game to set a property and asks for a property that doesn’t exist. It’s your job to know what will happen in these situations.
Q:
Q: Now that we’ve got our tests planned out, we can finally start coding the Unit class, right?
A:
A: Well, there’s one more bit of design we need to think about first...

Test driven development focuses on getting the behavior of your classes right.

Joe: What do you mean? We figured out that all properties in a Unit have a name and a value. So we decided to use a Map to store them all.

Frank: And game designers can add any new properties they want by just creating new property names, and sticking name/value pairs in the Map with the setProperty() method.

Jill: Right. But then, we also added a type property, since all units will have a type. And that’s something common for all units...

Joe: Sure. See, we did do the commonality analysis right.

Jill: ...but we also now know that units can be assembled into groups, like armies or fleets or whatever. So what happens if we have two units of the same type in the same group... how can we tell the difference between them?

Frank: You think we need some sort of ID, don’t you?

Jill: Yeah, maybe. Or at least a name... but even then, you can’t really prevent duplication with a name property, can you?

Joe: OK, but that still doesn’t mean we need to change our design. We can just add the ID property into our property Map. So we’ve got a nice, uniform way to access all those properties, using the getProperty() method.

Frank: He’s right, Jill. And since we encapsulate away the details about property names into the properties Map, we could even change from using an ID to a name, or something totally different, and code using the Unit class wouldn’t have to change much... you’d just need to use the new property name in getProperty(). That’s a pretty slick design!

Jill: But what about commonality? If ID is really common to all types of Unit, shouldn’t it be moved out of the Map, sort of like we did with the type property?

Joe: Whoa... encapsulation or commonality. That’s tough... it seems like we can’t do one without screwing up the other.

Refine your commonality analysis.

Before we close the book on dealing with Unit properties, there are a few things you still need to think through. Below are several properties that different units might have, and two sheets of paper. Write down on the Commonality sheet the properties that you think all units, regardless of their type, would have; on the Variability sheet, write down properties you think only specific types of units might have.

Potential Unit Properties
name	weapon	allegiance	gear
type	hitPoints	wingspan	lastName
strength	weight	landSpeed	id
speed	intelligence	experience	groundSpeed
stamina	firstName	weapons	hunger

Now update the Unit class diagram.

With the details from your revised commonality analysis in Sharpen your pencil, you (might) need to update the Unit class diagram, shown below. Make any changes that might improve the design of the Unit class below, and add notes to remind yourself what the purpose of any additions you’ve made are going to be used for.

Refine your commonality analysis.

In Sharpen your pencil, we showed you several properties that different units might have. Your job was to write down on the Commonality sheet the properties that you think all units, regardless of their type, would have; on the Variability sheet, you should have written down properties you think only specific types of units might have.

Relax

You may have a different idea about what makes a good game.

You might have played different games than we have, and come up with different common properties. That’s OK—just focus on how and why you made your own decisions. We’re going to use our choices in the rest of the chapter, so you should be comfortable with how we made our choices, too.

Q:
Q: I didn’t have anything on the Commonality list except for “type”. Where did I go wrong?
A:
A: You didn’t go wrong at all. Analysis and design are all about making choices, and sometimes you’re going to make a different choice than another programmer. There’s nothing wrong with that, as long as you have good, well thought out reasons for the decision you made.
Q:
Q: But won’t different choices at least result in different code and design implementations?
A:
A: Yes, they sure will. But OOA&D, and software development, aren’t about making a particular decision, since many times there isn’t an exactly “right” or exactly “wrong” choice. They’re about writing well-designed software, and that can happen in a lot of different ways.
In fact, even if two programmers made the same decision about commonality and variability in this exercise, it can lead to totally different design decisions when it comes to actually writing your classes. Let’s assume for a moment that two developers both came up with the answers for commonality and variability shown here, and then tried to revise the Unit class to reflect what they figured out...

Solution #1: Emphasizing Commonality

In this solution, all game designers can directly access the id, name, and weapons properties, instead of having to use getProperty() and work through the more generic properties Map.

The emphasis is on keeping the common properties of a Unit outside of the properties Map, and leaving properties that vary inside the properties Map.

Design decisions are always a tradeoff

Sam chose to emphasize the things that are common across all types of Units. But there are some negatives to Sam’s design, too:

Note

We’re repeating ourselves

Now there are two different ways to access properties: through the getId(), getName(), and property-specific methods, and the getProperty() method. Two ways to access properties is almost certainly going to mean duplicate code somewhere.

Maintenance is a problem

Note

When you see the potential for duplicate code, you’ll almost always find maintenance and flexibility issues, as well.

Now you’ve got property names, like id and name, hard-coded into the Unit class. If a game designer doesn’t want to use those, or wants to change them, it’s going to be a real hassle, and require changes to the Unit class. This is usually where encapsulation would help, and that leads us to Randy’s design choice...

Solution #2: Emphasizing Encapsulation

This solution focuses on encapsulating all the properties for a Unit into the properties Map, and providing a standard interface—the getProperty() method—for accessing all properties. Even properties that apply to all units, like type and id, are accessed through the properties Map in this solution.

The emphasis is on encapsulation, and a flexible design. Even if the names of common properties change, the Unit class can stay the same, since no property names are hardcoded into the class itself.

Tradeoffs with this decision, too...

Randy’s solution is more resistant to changes, and uses a lot more encapsulation, but there are tradeoffs with this design, as well. Here are a few of the downsides to Randy’s design:

We’re ignoring commonality Randy encapsulated all of the properties into the properties Map, but now there’s nothing to indicate that type, name, id, and weapons are intended to be properties common to all Unit types.

Lots of work at runtime getProperty() returns an Object, and you’re going to have to cast that into the right value type for each different property, all at runtime. That’s a lot of casting, and a lot of extra work that your code has to do at runtime, even for the properties that are common to all Unit types.

Brain Power

Which developer’s solution do you think is best? Are there times where you think one solution might be the best choice, and other times where the other might work better?

Let’s go with the commonality-focused solution

For Gary’s game system framework, let’s use Sam’s solution, which pulls the common properties of a Unit out into their own properties and methods, and leaves unit-specific properties in a separate Map.

Q:
Q: I thought the other design, that focused on encapsulation, was better. Is that OK?
A:
A: Absolutely. Both design choices have positives, and either one might work well. The only thing you cannot do is be unwilling to change your design—whichever one you start with—if it turns out to not work well down the line. At each stage of iterating through your app, you need to reevaluate your design decisions, and make sure they’re still solid.
Q:
Q: So how do I know when I need to change my design? My code won’t just stop working, so what should I look out for?
A:
A: Iteration is really the key point here. Lots of design decisions look great at one stage of your development, but then turn out to be a problem as you get deeper into a particular part of your app. So once you make a decision, stick with it, and iterate deeper into your application. As long as your design is working, and you’re able to use good OO principles and apply design patterns, you’re in good shape. If you start running into trouble with a decision, though, don’t ever be afraid to change designs and rework things.
Q:
Q: What happens when I can’t decide between a couple of good design choices?
A:
A: You always have to make a choice, even if you’re not 100% sure if it’s the right one. It’s always better to take your best guess, and see how things work out, rather than spend endless hours debating one choice or another. That’s called analysis paralysis, and it’s a sure way to not get anything done. It’s much better to start down one path, even if you’re not totally sure it’s the right one, and get some work done, than to not make a choice at all.

Good software is built iteratively. Analyze, design, and then iterate again, working on smaller and smaller parts of your app.
Each time you iterate, reevaluate your design decisions, and don’t be afraid to CHANGE something if it makes sense for your design.

Match your tests to your design

We’ve got test scenarios we want to show Gary, and a design for the Unit class. The last thing we need to do before coding is to make sure our design for Unit will allow us to code a solution that passes all the tests.

Let’s write the Unit class

It’s been two chapters in coming, but we’re finally ready to write the code for the Unit class. Here’s how we did it:

Test cases dissected...

We’ve talked a lot about test cases, but so far, you haven’t seen how to actually write one. Let’s examine a test case up close, and see exactly what makes up a good test.

Each test case should have an ID and a name.
Note
Try not to refer to tests as test1, test2, etc. Use descriptive names whenever possible.
The names of your test cases should describe what is being tested. Test names with nothing but a number at the end aren’t nearly as helpful as names like testProperty() or testCreation(). You should also use a numeric ID, so you can easily list your tests cases out (something we’ll do on the next page).
Each test case should have one specific thing that it tests.
Note
One piece of functionality may involve one method, two methods, or even multiple classes... but to start with, focus on very simple pieces of functionality, one at a time.
Each of your test cases should be atomic: each should test only one piece of functionality at time. This allows you to isolate exactly what piece of functionality might not be working in your application.
Each test case should have an input you supply.
Note
If you’re setting hitPoints to 15, then “15” becomes the input you supply to your test case.
You’re going to give the test case a value, or a set of values, that it uses as the test data. This data is usually then used to execute some specific piece of functionality or behavior.
Each test case should have an output that you expect.
Note
This is what you want the program to output. So if you set type to “infantry”, and then call getType(), your expected output is “infantry”.
Given your input, what should the program, class, or method output? You’ll compare the actual output of the program with your expected output, and if they match, then you’ve got a successful test, and your software works.
Most test cases have a starting state.
Note
There’s not much starting state for the Unit class. We do need to create a new Unit, but that’s about it.
Do you need to open a database connection, or create a certain object, or set some values before running your test? If so, that’s all part of the starting state of the test case, and needs to be handled before you run the actual test.

Q:
Q: How did our three test scenarios turn into four test cases?
A:
A: Because the first test case really tested two things: setting and retrieving a common property, which has its own variable and access method (like getType()), and setting a retrieving a unit- or game-specific property, which is accessed through getProperty() (like hitPoints). That’s two pieces of functionality, so two different test cases are required.
Q:
Q: And all these tests will let us know that our software works like it should, right?
A:
A: It’s a good start on that, yes, but remember, we started out writing the tests so that we could prove to the customer that the software we’ve been writing actually will work. Our test cases let the customer see some code actually running, as well as help us find bugs in our code before we get too far along in our development cycle.

Now that you know what test cases are, and have several written up in table form, you’re ready to code a test class to show your customer that your software works, and prove to yourself that there aren’t any bugs in the code that you’ve written.

The problem:

Gary wants to know that you’re making progress on supporting units in his game system framework, and you want to be sure that the code you’ve written for Unit.java works properly.

Your task:

Create a new class called UnitTester.java, and import the Unit class and any related classes into it.
Add a new method for each test case you figured out from the table in Sharpen your pencil answers. Be sure to use descriptive names for the test methods.
Each test method should take in an instance of Unit with any starting state already set, and any other parameters you think you’ll need to run the test and compare an input value with an expected output value.
The test method should set the supplied property name and property value on the provided Unit, and then retrieve the expected output property value using the expected output property name.
If the provided input value and expected output value match, the method should print out “Test passed”; if they don’t match, the method should print “Test failed”, along with the mismatched values.
Write a main() method that sets up the starting state for each test, and then runs each test.

Bonus Credit:

There are several things in Unit.java that are not being tested by the scenarios in Sharpen your pencil answers. Identify what each of these are, and create a test method for each.
Run these tests from your main() method as well.

And now for some bonus credit...

We added three new test cases to our table, to handle the three properties common to all units that aren’t tested in UnitTester. You should be able to write three additional test methods based on this table. Did you figure these out on your own?

Prove yourself to the customer

With a Unit class and a set of test cases, you’re ready to show Gary some working code, and prove that you’re on the right track to building his game system framework just the way he wants it. Let’s show him the test class running:

Let’s change the programming contract for the game system

When you’re writing software, you’re also creating a contract between that software and the people that use it. The contract details how the software will work when certain actions are taken—like requesting a non-existent property on a unit.

If the customer wants an action to result in different behavior, then you’re changing the contract. So if Gary’s framework should throw an exception when a non-existent property is queried, that’s fine; it just means that the contract between game designers and the framework has changed.

When you program by contract, you and your software’s users are agreeing that your software will behave in a certain way.
Note
Want to know more about what this means? Turn the page to find out more...

We’ve been programming by contract so far

You probably didn’t notice, but we’ve been doing something called programming by contract in the Unit class so far. In the Unit class, if someone asks for a property that doesn’t exist, we’ve just returned null. We’ve been doing the same thing in getWeapons(); if the weapons list isn’t initialized, we just return null there, too:

This is the contract for Unit

The Unit class assumes that people using it are competent programmers, and that they can handle null return values. So our contract states something like this:

Programming by contract is really all about trust

When you return null, you’re trusting programmers to be able to deal with null return values. Programmers are basically saying that they’ve coded things well enough that they won’t ask for non-existent properties or weapons, so their code just doesn’t worry about getting null values back from the Unit class:

And we can always change the contract if we need to...

Back in Note, we were asked to stop returning null, and throw an exception instead. This really isn’t a big change to the contract; it just means that now game designers are going to have big problems if they ask for non-existent properties or weapons.

But if you don’t trust your users...

But what happens if you don’t think your code will be used correctly? Or if you think that certain actions are such a bad idea that you don’t want to let users deal with them in their own way? In these cases, you may want to consider defensive programming.

Suppose you were really worried that game designers using the Unit class, and asking for non-existent properties, were getting null values and not handling them properly. You might rewrite the getProperty() method like this:

I’m sure you’re great code and all, but I just don’t trust you. I could send you null, and you could totally blow up. So let’s just be safe, and I’ll send you a checked exception that you’ll have to catch, to make sure you don’t get a null value back and do something stupid with it.

-or if they don’t trust you...

Of course, when programmers use your code, they might not trust you either... they can program defensively as well. What if they don’t believe that you’ll only return non-null values from getProperty()? Then they’re going to protect their code, and use defensive programming, as well:

Q:
Q: You said in Programming by contract is really all about trust that we could change the contract to throw an exception, but then you said here that throwing an exception is defensive programming. I’m confused...
A:
A: It’s really not that important what kind of exception is thrown. What’s important is how your customers and clients are involved in that decision. In programming by contract, you work with the client to agree on how you’re going to handle problems; in defensive programming, you make that decision in a way that ensures your code doesn’t crash, regardless of what the client wants to have happen.
When we decided to switch from returning null to throwing an exception, we did that by listening to the client, and agreeing on that particular action as a response to a request for non-existent properties. And we made the exception a RuntimeException, again because the client didn’t want to add lots of try/catch blocks to their code. They could have just as easily asked for a checked exception, and we could have agreed—and still been programming by contract.
Compare that to defensive programming, where we’re not really that interested in what the client wants. In defensive programming, we’re making sure that we aren’t responsible for crashing a program, and we even go out of our way to try and prevent the client from crashing their program.

Fireside Chats

Tonight’s talk: Programming by Contract and Defensive Programming duke it out over trust issues with programmers.

Programming by Contract	Defensive Programming
It’s nice to sit down with you and meet face to face, we really don’t see each other like this very often.	Yeah, I really don’t like to get out much There’s just so much that can go wrong.
What do you mean?
	Well, I could be crossing the street, and slip on some Banana.peel() that hadn’t been garbage collected, or some for loop without a good termination condition could come screaming through the intersection... there’s a lot of bad code out there, you know?
Well, sure, I guess... but you can’t live your whole life in fear of bad code. At some point, you have to just commit to how you’re going to behave, and trust other programmers to use you right.
	Are you kidding me? Have you met most of the programmers writing the code you’re talking about trusting? They’re too busy watching Lost to worry about checking for bugs in their software. If they’d stop gawking at that Kate and her freckles, maybe I wouldn’t have to double-check their work so much.
Boy, it sounds like you have trust issues.
	And you don’t?
No. I trust programmers understand the contract that I provide them.
	Contract? Oh, you still think that if you explain what you’ll do in a certain situation, that a “good” programmer will use you correctly? Boy, what naivete!
Look, my contract explicitly states what I have to do, and what people that use me have to do.
	Haven’t you heard? Over 50% of contracts today end in divorce... or maybe that was a different stat, I’m not sure... anyway, do you really think programmers are paying attention to your little contract?
Look, if programmers and users don’t keep their end of the bargain, I can’t be held responsible for that. If they violate the contract, they deserve what they get. I can’t be held liable.
	Sounds pretty callous to me. I try and help my users, and even protect them from themselves.
With tons of extra code, little “if (value == null)” checks everywhere? What a beating. Sounds like you slow things down more than anything.
	Sure, sometimes I’m not the best performer, but I sure keep everyone safe from disaster. I often like to think of myself... a bit like Superman.
Superman? You did *not* just say that...
	It’s true! Besides, how many times has your code gone up in smoke because of a lazy programmer who ignored your contract?
But that’s the point! I may not be great for lazy programmers, but I’m terrific for programmers who do check their work. They get a performance bump, and their code is shorter when they use me.
	Short code, humph. I’d much rather have good code. Code that keeps programmers and users safe.
And that’s what I provide, just without all the trust issues and baggage you bring along...
	Hey, I’ve got a trust issue for you right here...
I’ll show you safe code, you little...
*...transmission ended... Veuillez nous aider! ... 4 8 15 ...*

Feature Driven Development, Use Case Driven Development, Programming by Contract, and Defensive Programming have all showed up for a masquerade party, but none of them bothered to wear name tags. They’re all a chatty bunch, though, so it’s up to you to listen to what they’re saying, and try and figure out who’s behind the masks. Be careful.... sometimes more than one masked guest could be saying the same thing.

I’m very well-ordered. I prefer to take things one step at a time, until I’ve made it from start to finish.	_____________________________
Well, sure, she said she would call, but how can you really believe anyone anymore?	_____________________________
Oh, absolutely, requirements really get me motivated.	_____________________________
I’m very well-behaved. In fact, I’ve been focusing on all of my own behavior before moving on to anything else.	_____________________________
Really, it’s all about my customer. I just want to satisfy them, after all.	_____________________________
Hey, you’re a big boy. You can deal with that on your own... it’s really not my problem anymore, is it?	_____________________________
As long as you’re good with it, so am I. Who am I to tell you what to do, so long as you know what you can expect from me.	_____________________________

Figure out who is who in Who Am I? Solutions.

Change the programming contract for Unit.

Gary’s clients want Unit to assume they’re using it correctly. That means that if a non-existent property is being queried, then something has truly gone wrong in the game, and an exception needs to be thrown. Your job is to:

Update Unit.java so that requests for a non-existent property result in an exception being thrown. Figuring out the type of exception to use is up to you.
Update UnitTester and the test cases that this contract change affects to reflect this new contract.
Re-run UnitTester and make sure Unit.java still passes all of the tests.

Note

Our answers are on the next page.

Q:
Q: Why are you throwing a RuntimeException, and not a checked exception, like IllegalAccessException?
A:
A: If you used a checked exception, code that calls getProperty() would have to check for that exception, in try/catch blocks. That’s not what the client wanted; we agreed to a contract that would let them code without having to catch for any exceptions. So by using a RuntimeException, no extra worked is required for their client code to use the Unit class.
Q:
Q: What about the get methods for other properties, like weapons, name, and id?
A:
A: id and name are an int and String, respectively, so those aren’t a problem (id is required to create a new Unit, and name will either be null or a String with a value). The weapons property is a List, so if you call getWeapons() when there aren’t any it’s going to result in a null list being returned. You could change that method to throw an exception if the weapons list was empty, although that wasn’t specifically asked for by the clients.

When you are programming by contract, you’re working with client code to agree on how you’ll handle problem situations.
When you’re programming defensively, you’re making sure the client gets a “safe” response, no matter what the client wants to have happen.

Q:
Q: You said that programming by contract resulted in less code, but it seems like we just added a lot of code to Unit.java.
A:
A: That’s because instead of directly returning null, we throw a new RuntimeException. But that’s more of a special case here than the rule. Most of the time, you’ll not have much extra code on the service side, because you’re simply returning objects and values without checking to see if they’re non-null, or within a particular data range.
Q:
Q: I still don’t see why we’re switching to programming by contract here. Why is it so much better?
A:
A: It’s not a matter of being better or worse; it’s a matter of what your customer wants. In fact, you’ll rarely decide on your own if you want to do programming by contract or defensive programming. That’s something that’s usually determined by what your customer wants, and the types of users that will be using the software that you’re writing.

Moving units

We’ve finally finished up unit properties, and can move on to the next item on our list:

Each unit should have properties, and game designers can add new properties to unit types in their own games.
Units have to be able to move from one tile on a board to another.
Note
We’re on to dealing with movement, now.
Units can be grouped together into armies.

Haven’t we been here before?

This should sound pretty familiar... we already dealt with movement in Chapter 7:

Break your apps up into smaller chunks of functionality

We’ve been talking a lot about iterating deeper into your application, and at each stage, doing more analysis and design. So you’re taking each problem, and then breaking it up (either into use cases or features), and then solving a part of the problem, over and over. This is what we’ve been doing in this chapter: taking a single feature, and working on that feature until it’s complete.

But you can still break things up further...

But once you choose a single feature or use case, you can usually break that feature up into even smaller pieces of behavior. For example, a unit has properties and we have to deal with unit movement. And we also need to support groupings of units. So each of these individual pieces of behavior has to be dealt with.

Just like when you broke your app up and began to iterate, you’ll have to do more analysis and design at each step. Always make sure your earlier decisions make sense, and change or rework those decisions if they don’t.

Your decisions can iterate down, too

Lots of times you’ll find that decisions you made earlier save you work down the line. In Gary’s system, we decided that game designers would deal with movement on their own. So now that we’re talking about how to handle unit movement, we can take that decision we made earlier, and apply it here. Since it still seems sensible—there’s no reason to change that decision—we can have game designers worry about handling unit movement, and move on to the next piece of behavior.

Note

Just add a note to your docs for the game designers that movement is up to them.

By now, you should have feature driven development, iteration, analysis, and design down pretty solid. We’re going to leave it up to you to handle the last bit of behavior and finish off the Unit feature of Gary’s game system framework.

The problem:

Gary’s framework needs to support groups of units.

Your task:

Create a new class that can group units together, and both add and remove units to the group.
Fill out the table below with test case scenarios that will test your software, and prove to Gary that the grouping of units works.
Add methods to UnitTester to implement the test scenarios in the table, and make sure all your tests pass.

See how we solved the puzzle in Feature Puzzle Solutions.

The first step in writing good software is to make sure your application works like the customer expects and wants it to.
Customers don’t usually care about diagrams and lists; they want to see your software actually do something.
Use case driven development focuses on one scenario in a use case in your application at a time.
In use case driven development, you focus on a single scenario at a time, but you also usually code all the scenarios in a single use case before moving on to any other scenarios, in other use cases.
Feature driven development allows you to code a complete feature before moving on to anything else.
You can choose to work on either big or small features in feature-driven development, as long as you take each feature one at a time.
Software development is always iterative. You look at the big picture, and then iterate down to smaller pieces of functionality.
You have to do analysis and design at each step of your development cycle, including when you start working on a new feature or use case.
Tests allow you to make sure your software doesn’t have any bugs, and let you prove to your customer that your software works.
A good test case only tests one specific piece of functionality.
Test cases may involve only one, or several, methods in a single class, or may involve multiple classes.
Test driven development is based on the idea that you write your tests first, and then develop software that passes those tests. The result is fully functional, working software.
Programming by contract assumes both sides in a transaction understand what actions generate what behavior, and will abide by that contract.
Methods usually return null or unchecked exceptions when errors occur in programming by contract environments.
Defensive programming looks for things to go wrong, and tests extensively to avoid problem situations.
Methods usually return “empty” objects or throw checked exceptions in defensive programming environments.

And now for the test cases:

Get online

You should be able to write the code for UnitTester using the test case table shown here. If you want to see how your code compares with ours, visit http://www.headfirstlabs.com, click on Head First OOA&D, and look for “UnitGroup Test Cases.”

Lots of new terms in this chapter, so lots of little square boxes to fill in for this chapter’s crossword. Review the chapter and see if you can get them all!

Across	Down
3. Never be afraid to do this in design. 4. This type of programming protects you and focuses on preventing errors and invalid data. 6. You should test your software for this kind of usage. 11. Iterating your development based on specific pieces of functionality. 12. Feature driven development is very __________. 15. Good development is driven by these. 16. Customers just want their software to do this. 17. Developing your software based on scenarios through a system. 18. Getting stuck trying to decide on one design decision or another.	1. This is what you use to prove to the customer that your software works. 2. Program this way when you trust your users, and they trust you. 5. Testing weird and strange usages your code will help you catch errors __________. 7. Use case diagrams and feature lists don’t make sense to the ___________. 8. Design decisions are always a __________. 9. A single test case can focus on this many pieces of functionality 10. Great software is written like this. 13. You write software for the __________. 14. Once you choose a feature or use case, you need to do this again.

Across

Down

3. Never be afraid to do this in design.

4. This type of programming protects you and focuses on preventing errors and invalid data.

6. You should test your software for this kind of usage.

11. Iterating your development based on specific pieces of functionality.

12. Feature driven development is very __________.

15. Good development is driven by these.

16. Customers just want their software to do this.

17. Developing your software based on scenarios through a system.

18. Getting stuck trying to decide on one design decision or another.

1. This is what you use to prove to the customer that your software works.

2. Program this way when you trust your users, and they trust you.

5. Testing weird and strange usages your code will help you catch errors __________.

7. Use case diagrams and feature lists don’t make sense to the ___________.

8. Design decisions are always a __________.

9. A single test case can focus on this many pieces of functionality

10. Great software is written like this.

13. You write software for the __________.

14. Once you choose a feature or use case, you need to do this again.

Previous Chapter

8. Design Principles: Originality is Overrated

Next Chapter

10. The OOA&D Lifecycle: Putting It All Together

Table of Contents for Head First Object-Oriented Analysis and Design

Chapter 9. Iterating and Testing: The Software is Still for the Customer

Your toolbox is filling up

But you’re still writing your software for the CUSTOMER!

Iterating deeper: two basic choices

Feature Ahead

Note

Feature driven development

Use case driven development

Two approaches to development

What’s the difference between feature driven and use case driven development?

Let’s use feature driven development

Brain Power

Analysis of a feature

3. The framework supports multiple types of troops or units that are game-specific

Note

Note

Fleshing out the Unit class

Note

Note

Note

Note

Showing off the Unit class

Writing test scenarios

Note

Scenario #2: Changing property values

Scenario #3: Getting non-existent property values

Relax

Solution #1: Emphasizing Commonality

Design decisions are always a tradeoff

Note

Note

Solution #2: Emphasizing Encapsulation

Tradeoffs with this decision, too...

Brain Power

Let’s go with the commonality-focused solution

Match your tests to your design

Let’s write the Unit class

Test cases dissected...

Note

Note

Note

Note

Note

Prove yourself to the customer

Note

We’ve been programming by contract so far

This is the contract for Unit

Programming by contract is really all about trust

And we can always change the contract if we need to...

But if you don’t trust your users...

-or if they don’t trust you...

Note

Moving units

Note

Haven’t we been here before?

Break your apps up into smaller chunks of functionality

But you can still break things up further...

Your decisions can iterate down, too

Note

Get online

Highlight

Highlight

Table of Contents for
Head First Object-Oriented Analysis and Design