Table of Contents for

Head First Object-Oriented Analysis and Design

A nice piña colada to sip on, the sun shining down on you, a roll of hundred dollar bills stuffed into your swim trunks... this is the life of a programmer who’s just made Doug’s Dog Doors a successful venture. The door you built for Todd and Gina was a huge success, and now Doug’s selling it to customers all across the world.

You: Oh, has something gone wrong?

Todd and Gina: No, not at all. The door works just like you said it would.

You: But there must be a problem, right? Is the door not closing quickly enough? Is the button on the remote not functioning?

Todd and Gina: No, really... it’s working just as well as the day you installed it and showed everything to us.

You: Is Fido not barking to be let out anymore? Oh, have you checked the batteries in the remote?

Todd and Gina: No, we swear, the door is great. We just have a few ideas about some changes we’d like you to make...

You: But if everything is working, then what’s the problem?

Time to get working on fixing up Todd and Gina’s dog door again. We need to figure out a way to open the door whenever Fido barks. Let’s start out by...

The customer is always right

Even when requirements change, you’ve got to be ready to update your application and make sure it works like your customers expect. When your customer has a new need, it’s up to you to change your applications to meet those new needs.

Okay, what’s the one thing you can always count on in writing software?

No matter where you work, what you’re building, or what language you are programming in, what’s the one true constant that will always be with you?

(use a mirror to see the answer)

No matter how well you design an application, over time the application will always grow and change. You’ll discover new solutions to problems, programming languages will evolve, or your friendly customers will come up with crazy new requirements that force you to “fix” working applications.

Exercise

Add bark recognition to Todd and Gina’s dog door.

Update the diagram, and add an alternate path where Fido barks, Doug’s new bark recognizer hears Fido, and the dog door automatically opens. The remote control should still work, too, so don’t remove anything from the diagram; just add another path where Fido’s barking opens the door.

Exercise Solutions

Doug’s invented hardware to recognize barks, but it’s up to you to figure out how to use his new hardware in the dog door system.

Here’s how we solved Todd and Gina’s problem, and implemented their bark-recognizing dog door. See if you made similar additions to the diagram.

If a use case is confusing to you, you can simply rewrite it. There are tons of different ways that people write use cases, but the important thing is that it makes sense to you, your team, and the people you have to explain it to. So let’s rewrite the use case from page 121 so it’s not so confusing.

Excellent idea!

The main path should be what you want to have happen most of the time. Since Todd and Gina probably want the bark recognizer to handle Fido more than they want to use the remote, let’s put those steps on the main path:

With all the alternate paths in the new use case, there are lots of different ways to get Fido outside to use the bathroom, and then back in again. Here’s one particular path through the use case:

Sharpen your pencil

How many scenarios are in Todd and Gina’s use case?

How many different ways can you work your way through Todd and Gina’s use case? Remember, sometimes you have to take one of multiple alternate paths, and sometimes you can skip an alternate path altogether.

Check out our answers on the next page

Sharpen your pencil answers

How many scenarios are in Todd and Gina’s use case?

How many different ways can you work your way through Todd and Gina’s use case? Remember, sometimes you have to take one of multiple alternate paths, and sometimes you can skip an alternate path altogether.

Now that our use case is finished up, and we’ve figured out all the possible scenarios for using the dog door, we’re ready to write code to handle Todd and Gina’s new requirements. Let’s figure out what we need to do...

Any time you change your use case, you need to go back and check your requirements.

Remember, the whole point of a good use case is to get good requirements. If your use case changes, that may mean that your requirements change, too. Let’s review the requirements and see if we need to add anything to them.

So we need to handle the two new alternate paths by adding a couple extra requirements to our requirements list. We’ve gone ahead and crossed off the steps that our requirements already handle, and it looks like we need a few additions to our requirements list:

With new requirements comes new code. We need some barking, a bark recognizer to listen for barking, and then a dog door to open up:

We need some software to run when Doug’s hardware “hears” a bark. Let’s create a BarkRecognizer class, and write a method that we can use to respond to barks:

First, let’s make sure we’ve taken care of Todd and Gina’s new requirements for their door:

Use cases, requirements, and code have all led up to this. Let’s see if everything works like it should.

In our new version of the dog door, the door doesn’t automatically close!

In the scenarios where Todd and Gina press the button on the remote control, here’s the code that runs:

But in BarkRecognizer, we open the door, and never close it:

What do YOU think about Doug’s idea?

Duplicate code is a bad idea. But where should the code that closes the door go?

Let’s have the dog door close automatically all the time.

Since Gina never wants the dog door left open, the dog door should always close automatically. So we can move the code to close the door automatically into the DogDoor class. Then, no matter what opens the door, it will always close itself.

Let’s take the code that closed the door from the Remote class, and put it into our DogDoor code:

You’ll need to take this same code out of Remote now, since the dog door handles automatically closing itself:

You’ve made a lot of changes to Todd and Gina’s dog door since they first called you up. Let’s test things out and see if everything works. Make the changes to Remote.java and DogDoor.java so that the door closes itself, compile all your classes again, and run the simulator:

Sharpen your pencil

Write your own design principle!

You’ve used an important design principle in this chapter related to duplicating code, and the dog door closing itself. Try and summarize the design principle that you think you’ve learned:

You’ve learned a lot in this chapter, and now it’s time to add what you’ve picked up to your OOA&D toolbox. Review what you’ve learned on this page, and then get ready to put it all to use in the OOA&D cross on the next page.

OOA&D Cross

The puzzles keep coming. Make sure you’ve gotten all the key concepts in this chapter by working this crossword. All the answer words are somewhere in this chapter.

Across

Down

2. We made this responsible for closing the dag door. 4. This is what you follow in a use case most of the time. 5. When your use case changes, these often changes as well. 6. Requirements always change over ______. 8. We had to add this to our dog door to satisfy Tadd and Gina. 10. When your system changes, you should always update this before writing code. 11. Use cases often have __________ Scenarios. 12. Many real-world applications involve both software and this. 13. The one constant in software analysis and design.

1. If a step is optional, use this in your use case. 2. Always avoid ____________ code. 3. A set of steps that don’t always occur in your use case. 7. Do this to things that vary. 9. The main path is also called this. 10. Every scenario in a use case shares the same _____ _____.

Exercise Solutions