Head First Object-Oriented Analysis and Design

Chapter 1. Well-Designed Apps Rock: Great Software Begins Here

So how do you really write great software? It’s never easy trying to figure out where to start. Does the application actually do what it’s supposed to? And what about things like duplicate code—that can’t be good, can it? It’s usually pretty hard to know what you should work on first, and still make sure you don’t screw everything else up in the process. No worries here, though. By the time you’re done with this chapter, you’ll know how to write great software, and be well on your way to improving the way you develop applications forever. Finally, you’ll understand why OOA&D is a four-letter word that your mother actually wants you to know about.

Rock and roll is forever!

There’s nothing better than the sound of a killer guitar in the hands of a great player, and Rick’s Guitars specializes in finding the perfect instrument for his discerning customers.

Just a few months ago, Rick decided to throw out his paper-based system for keeping track of guitars, and start using a computer-based system to store his inventory. He hired a popular programming firm, Down and Dirty Coding, and they’ve already built him an inventory management app. He’s even had the firm build him a new search tool to help him match up a customer to their dream instrument.

Rick’s shiny new application...

Here’s the application that the programming firm built for Rick... they’ve put together a system to completely replace all of Rick’s handwritten notes, and help him match his customers with the perfect guitar. Here’s the UML class diagram they gave Rick to show him what they did:

New to Objectville?

If you’re new to object oriented programming, haven’t heard of UML before, or aren’t sure about the diagram above, it’s OK! We’ve prepared a special Welcome to Objectville care package for you to get you started. Flip to the back of the book, and read Appendix B—we promise you’ll be glad you did. Then come back here, and this will all make a lot more sense.

Here what the code for Guitar.java looks like

You’ve seen the class diagram for Rick’s application on the last page; now let’s look at what the actual code for Guitar.java and Inventory.java look like.

And Inventory.java...

But then Rick started losing customers...

It seems like no matter who the customer is and what they like, Rick’s new search program almost always comes up empty when it looks for good guitar matches. But Rick knows he has guitars that these customers would like... so what’s going on?

Sharpen your pencil

How would you redesign Rick’s app?

Look over the last three pages, showing the code for Rick’s app, and the results of running a search. What problems do you see? What would you change? Write down the FIRST thing you’d do to improve Rick’s app in the blanks below.

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

What’s the FIRST thing you’d change?

It’s obvious that Rick’s app has problems, but it’s not so obvious what we should work on first. And it looks like there’s no shortage of opinion:

What would you do first?

How do you write great software, every time?

Good question... and there are lots of different answers:

Sharpen your pencil

What do you think “great software” means?

You’ve seen what several different types of programmers think great software is... so who is right? Or do you have your own definition of what makes an application great? It’s your turn to write down what you think makes for great software:

Great software is... more than just one thing

It’s going to take more than just a simple definition to figure out exactly what “great software” means. In fact, all of the different programmers in What’s the FIRST thing you’d change? talked about a part of what makes software great.

First, great software must satisfy the customer. The software must do what the customer wants it to do.

Win your customers over

Customers will think your software is great when it does what it’s supposed to do.

Building software that works right is great, but what about when it’s time to add to your code, or reuse it in another application? It’s not enough to just have software that works like the customer wants it to; your software better be able to stand the test of time.

Second, great software is well-designed, well-coded, and easy to maintain, reuse, and extend.

Make your code as smart as you are

You (and your co-workers) will think your software is great when it’s easy to maintain, reuse, and extend.

Great software in 3 easy steps

Note

It may not seem easy now, but we’ll show you how OOA&D and some basic principles can change your software forever.

Remember Rick? Remember his lost customers?

Let’s put our ideas about how to write great software to the test and see if they hold up in the real world. Rick’s got a search tool that isn’t working, and it’s your job to fix the application, and turn it into something great. Let’s look back at the app and see what’s going on:

So let’s apply our 3 steps

Frank: Sure, that would fix the problem Rick’s having now, but I think there’s probably a better way to make this work than just calling toLowerCase() on a bunch of strings all over the place.

Joe: Yeah, I was thinking the same thing. I mean, all that string comparison seems like a bad idea. Couldn’t we use constants or maybe some enumerated types for the builders and woods?

Jill: You guys are thinking way too far ahead. Step 1 was supposed to be fixing the app so it does what the customer wants it to do. I thought we weren’t supposed to worry about design yet.

Frank: Well, yeah, I get that we’re supposed to focus on the customer. But we can at least be smart about how we fix things, right? I mean, why create problems we’ll have to come back and fix later on if we can avoid them from the start?

Jill: Hmmm... I guess that does make sense. We don’t want our solution to this problem creating new design problems for us down the road. But we’re still not going to mess with the other parts of the application, right?

Frank: Right. We can just remove all those strings, and the string comparisons, to avoid this whole case-matching thing.

Joe: Exactly. If we go with enumerated types, we can ensure that only valid values for the builder, woods, and type of guitar are accepted. That’ll make sure that Rick’s clients actually get to look at guitars that match their preferences.

Jill: And we’ve actually done a little bit of design at the same time... very cool! Let’s put this into action.

Don’t create problems to solve problems.

Ditching String comparisons

The first improvement we can make to Rick’s guitar search tool is getting rid of all those annoying String comparisons. And even though you could use a function like toLowerCase() to avoid problems with uppercase and lowercase letters, let’s avoid String comparisons altogether:

There are no Dumb Questions

Q:	Q: I’ve never seen an enum before. What is that, exactly?
A:	A: Enums are enumerated types. They’re available in C, C++, Java version 5.0 and up, and will even be a part of Perl 6. Enumerated types let you define a type name, like Wood, and then a set of values that are allowed for that type (like COCOBOLO, SITKA, and MAHOGANY). Then, you refer to a specific value like this: Wood.COCOBOLO.
Q:	Q: And why are enumerated types so helpful here?
A:	A: The cool thing about enums is that methods or classes that use them are protected from any values not defined in the enum. So you can’t misspell or mistype an enum without getting a compiler error. It’s a great way to get not only type safety, but value safety; you can avoid getting bad data for anything that has a standard range or set of legal values.
Q:	Q: I’m using an older version of Java. Am I stuck?
A:	A: No, not at all. Visit the Head First Labs web site at http://www.headfirstlabs.com, where we’ve posted a version of Rick’s Guitars that doesn’t use enums, and will work with older JDKs.

Let’s take a look at the big picture:

So what have we really done here?

We’ve gotten a lot closer to completing step 1 in building great software. Rick’s problem with searches coming up empty when he’s got a matching guitar in his inventory is a thing of the past.

1. Make sure your software does what the customer wants it to do.

Even better, we’ve made Rick’s application less fragile along the way. It’s not going to break so easily now, because we’ve added both type safety and value safety with these enums. That means less problems for Rick, and less maintenance for us.

Note

Code that is not fragile is generally referred to as robust code.

Sharpen your pencil

Apply Step 1 to your own project.

It’s time to see how you can satisfy your own customers. In the blank below, write a short description of the current project you’re working on (you can also use a project you finished recently):

_____________________________________________________________________

_____________________________________________________________________

Now, write down the first thing you did when you started working on this project. Did it have anything to do with making sure your code did what the customer wanted it to?

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

If you started out focusing on something other than the customer, think about how you might have approached things differently if you knew about the 3 steps to building great software. What would have been different? Do you think your application would be any better or worse than it is right now?

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

There are no Dumb Questions

Q:	Q: So it’s OK to do a little design when I’m working on Step 1, right?
A:	A: Yeah, as long as your focus is still on the customer’s needs. You want the basic features of your application in place before you start making big design changes. But while you’re working on functionality, you can certainly use good OO principles and techniques to make sure your application is well designed from the start.
Q:	Q: That diagram over in Note is a class diagram right? Or is it class diagrams, since it’s more than one class?
A:	A: It is a class diagram, and a single diagram can have multiple classes in it. In fact, class diagrams can show a lot more detail than you’ve seen so far, and we’ll be adding to them in the next several chapters.
Q:	Q: So we’re ready to move on to Step 2, and start applying OO principles, right?
A:	A: Not quite... there’s one more thing Rick would like us to help him with before we’re ready to start analyzing our code for places we might be able to improve it. Remember, our first job is to please the customer, and then we really focus on improving our OO design.

Rick’s customers want choices!

Rick’s come up with a new requirement for his app: he wants his search tool to return all the guitars that match his client’s specs, not just the first one in his inventory.

Code Magnets

Let’s continue with Step 1, and make sure we’ve got the app working right. Below is the code for the search() method in Rick’s inventory tool, but it’s up to you to fill in the missing pieces. Use the code magnets at the bottom of the page to return all the matching guitars from Rick’s inventory.

Code Magnets

Let’s keep on with Step 1, and make sure we’ve got the app working right. Below is the code for the search() method in Rick’s inventory tool, but it’s up to you to fill in the missing pieces. Use the code magnets at the bottom of the page to return all the matching guitars from Rick’s inventory.

There are no Dumb Questions

Q:	Q: So I’m not done with the first step until the application works like my customer wants it to?
A:	A: Exactly. You want to make sure that the application works like it should before you dive into applying design patterns or trying to do any real restructuring of how the application is put together.
Q:	Q: And why is it so important to finish Step 1 before going on to Step 2?
A:	A: You’re going to make lots of changes to your software when you’re getting it to work right. Trying to do too much design before you’ve at least got the basic functionality down can end up being a waste, because a lot of the design will change as you’re adding new pieces of functionality to your classes and methods.
Q:	Q: You seem sort of hung up on this “Step 1” and “Step 2” business. What if I don’t code my apps that way?
A:	A: There’s nothing that says you have to follow these steps exactly, but they do provide an easy path to follow to make sure your software does what it’s supposed to, and is well-designed and easy to reuse. If you’ve got something similar that accomplishes the same goals, that’s great!

Test drive

We’ve talked a lot about getting the right requirements from the customer, but now we need to make sure we’ve actually got those requirements handled by our code. Let’s test things out, and see if our app is working like Rick wants it to:

Back to our steps

Now that Rick’s all set with our software, we can begin to use some OO principles and make sure the app is flexible and well-designed.

Looking for problems

Let’s dig a little deeper into our search tool, and see if we can find any problems that some simple OO principles might help improve. Let’s start by taking a closer look at how the search() method in Inventory works:

Brain Power

Is anything wrong here? What problems might there be with Rick’s search tool?

Hint: Think about what each object is named, and compare that to its function. Anything seem odd?

Analyze the search() method

Let’s spend a little time analyzing exactly what goes on in the search() method of Inventory.java. Before we look at the code, though, let’s think about what this method should do.

1. The client provides their guitar preferences.

   Note

   The client can specify only general properties of an instrument. So they never supply a serial number or a price.

   Each of Rick’s clients has some properties that they’re interested in finding in their ideal guitar: the woods used, or the type of guitar, or a particular builder or model. They provide these preferences to Rick, who feeds them into his inventory search tool.

2. The search tool looks through Rick’s inventory.

   Once the search tool knows what Rick’s client wants, it starts to loop through each guitar in Rick’s inventory.

3. Each guitar is compared to the client’s preferences.

   For each guitar in Rick’s inventory, the search tool sees if that guitar matches the client’s preferences. If there’s a match, the matching guitar is added to the list of choices for the client.

   Note

   All the general properties, like the top wood and guitar builder, are compared to the client’s preferences.

4. Rick’s client is given a list of matching guitars.

   Finally, the list of matching guitars is returned to Rick and his client. The client can make a choice, and Rick can make a sale.

Use a textual description of the problem you’re trying to solve to make sure that your design lines up with the intended functionality of your application.

The Mystery of the Mismatched Object Type

In the better-designed areas of Objectville, objects are very particular about their jobs. Each object is interested in doing its job, and only its job, to the best of its ability. There’s nothing a well-designed object hates more than being used to do something that really isn’t its true purpose.

Unfortunately, it’s come to our attention that this is exactly what is happening in Rick’s inventory search tool: somewhere, an object is being used to do something that it really shouldn’t be doing. It’s your job to solve this mystery and figure out how we can get Rick’s application back in line.

To help you figure out what’s gone amiss, here are some helpful tips to start you on your search for the mismatched object type:

1. Objects should do what their names indicate. If an object is named Jet, it should probably takeOff() and land(), but it shouldn’t takeTicket()—that’s the job of another object, and doesn’t belong in Jet.

2. Each object should represent a single concept. You don’t want objects serving double or triple duty. Avoid a Duck object that represents a real quacking duck, a yellow plastic duck, and someone dropping their head down to avoid getting hit by a baseball.

3. Unused properties are a dead giveaway. If you’ve got an object that is being used with no-value or null properties often, you’ve probably got an object doing more than one job. If you rarely have values for a certain property, why is that property part of the object? Would there be a better object to use with just a subset of those properties?

What do you think the mismatched object type is? Write your answer in the blank below:

___________________________________

What do you think you should do to fix the problem? What changes would you make?

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

Frank: Hey, that’s right, Joe. I hadn’t thought about that before.

Jill: So what? Using a Guitar object makes it really easy to do comparisons in the search() method.

Joe: Not any more than some other object would. Look:

Joe: It really doesn’t matter what type of object we’re using there, as long as we can figure out what specific things Rick’s clients are looking for.

Frank: Yeah, I think we should have a new object that stores just the specs that clients want to send to the search() method. Then they’re not sending an entire Guitar object, which never seemed to make much sense to me.

Jill: But isn’t that going to create some duplicate code? If there’s an object for all the client’s specs, and then the Guitar has all its properties, we’ve got two getBuilder() methods, two getBackWood() methods... that’s not good.

Frank: So why don’t we just encapsulate those properties away from Guitar into a new object?

Joe: Whoa... I was with you until you said “encapsulate.” I thought that was when you made all your variables private, so nobody could use them incorrectly. What’s that got to do with a guitar’s properties?

Frank: Encapsulation is also about breaking your app into logical parts, and then keeping those parts separate. So just like you keep the data in your classes separate from the rest of your app’s behavior, we can keep the generic properties of a guitar separate from the actual Guitar object itself.

Jill: And then Guitar just has a variable pointing to a new object type that stores all its properties?

Frank: Exactly! So we’ve really encapsulated the guitar properties out of Guitar, and put them in their own separate object. Look, we could do something like this...

Encapsulation allows you to hide the inner workings of your application’s parts, but yet make it clear what each part does.

Note

New to encapsulation? Flip ahead to Appendix B, read that short introduction to Objectville, and then come back here and keep reading.

Sharpen your pencil

Create the GuitarSpec object.

Below, you’ll see the class diagram for Guitar, and the new GuitarSpec object that Frank, Jill, and Joe have been discussing. It’s your job to add all the properties and methods that you think you’ll need to GuitarSpec. Then, cross out anything you don’t need anymore in the Guitar class. Finally, we’ve left you some space in the Guitar class diagram in case you think you need to add any new properties or methods. Good luck!

* If you get stuck, think about the things that are common between the Guitar object and what a client would supply to the search() method.

Sharpen your pencil answers

Create the GuitarSpec object.

Below you’ll see the class diagram for Guitar, and the new GuitarSpec object that Frank, Jill, and Joe have been discussing. It’s your job to add all the properties and methods that you think you’ll need to GuitarSpec. See if you made the same changes that we did.

Now update your own code

With this class diagram, you should be able to add the GuitarSpec class to your application, and update the Guitar class as well. Go ahead and make any changes you need to Inventory.java so that the search tool compiles, as well.

There are no Dumb Questions

Q:	Q: I understand why we need an object for the client to send specs to search()... but why are we using that object to hold properties for Guitar, too?
A:	A: Suppose you just used GuitarSpec to hold client specs for sending to the search() method, and you kept the Guitar class just the same as it was. If Rick started carrying 12-string guitars, and wanted a numStrings property, you’d have to add that property—and code for a getNumStrings() method—to both the GuitarSpec and Guitar classes. Can you see how this would lead to duplicate code? Instead, we can put all that (potentially) duplicate code into the GuitarSpec class, and then have Guitar objects reference an instance of it to avoid any duplication. Anytime you see duplicate code, look for a place to encapsulate!
Q:	Q: I still am confused about how this is a form of encapsulation. Can you explain that again?
A:	A: The idea behind encapsulation is to protect information in one part of your application from the other parts of your application. In its simplest form, you can protect the data in your class from the rest of your app by making that data private. But sometimes the information might be an entire set of properties—like the details about a guitar—or even behavior—like how a particular type of duck flies. When you break that behavior out from a class, you can change the behavior without the class having to change as well. So if you changed how properties were stored, you wouldn’t have to change your Guitar class at all, because the properties are encapsulated away from Guitar. That’s the power of encapsulation: by breaking up the different parts of your app, you can change one part without having to change all the other parts. In general, you should encapsulate the parts of your app that might vary away from the parts that will stay the same.

Update the Inventory class

Now that we’ve encapsulated away the specifications of a guitar, we’ll need to make a few other changes to our code.

Getting ready for another test drive

You’ll need to update the FindGuitarTester class to test out all these new changes:

Get online

You can download the current version of Rick’s search tool at http://www.headfirstlabs.com. Just look for Head First OOA&D, and find “Rick’s Guitars (with encapsulation)”.

Why DO I Matter?

You’ve learned a lot about writing great software, and there’s still more to go! Take a deep breath and think about some of the terms and principles we’ve covered. Connect the words on the left to the purposes of those techniques and principles on the right.

Flexibility	Without me, you’ll never actually make the customer happy. No matter how well-designed your application is, I’m the thing that puts a smile on the customer’s face.
Encapsulation	I’m all about reuse and making sure you’re not trying to solve a problem that someone else has already figured out.
Functionality	You use me to keep the parts of your code that stay the same separate from the parts that change; then it’s really easy to make changes to your code without breaking everything.
Design Pattern	Use me so that your software can change and grow without constant rework. I keep your application from being fragile.

Answers in Why DO I Matter?.

There are no Dumb Questions

Q:	Q: Encapsulation isn’t the only OO principle I can use at this stage, is it?
A:	A: Nope. Other good OO principles that you might want to think about at this stage are inheritance and polymorphism. Both of these relate to duplicate code and encapsulation though, so starting out by looking for places where you could use encapsulation to better your design is always a good idea. We’ll talk about a lot more OO programming principles throughout this book (and even see a few sing in Chapter 8), so don’t worry if you are still getting a handle on things at this point. You’ll learn a lot more about encapsulation, class design, and more before we’re done.
Q:	Q: But I don’t really see how this encapsulation makes my code more flexible. Can you explain that again?
A:	A: Once you’ve gotten your software to work like it’s supposed to, flexibility becomes a big deal. What if the customer wants to add new properties or features to the app? If you’ve got tons of duplicate code or confusing inheritance structures in your app, making changes is going to be a pain. By introducing principles like encapsulation and good class design into your code, it’s easier to make these changes, and your application becomes a lot more flexible.

Getting back to Rick’s app...

Let’s make sure all our changes haven’t messed up the way Rick’s tool works. Compile your classes, and run the FindGuitarTester program again:

Brain Power

Can you think of three specific ways that well-designed software is easier to change than software that has duplicate code?

Design once, design twice

Once you’ve taken a first pass over your software and applied some basic OO principles, you’re ready to take another look, and this time make sure your software is not only flexible, but easily reused and extended.

Let’s make sure Inventory.java is (really) well-designed

We’ve already used encapsulation to improve the design of Rick’s search tool, but there are still some places in our code where we could get rid of potential problems. This will make our code easier to extend when Rick comes up with that next new feature he wants in his inventory search tool, and easier to reuse if we want to take just a few parts of the app and use them in other contexts.

Note

Now that you’ve made Rick a working search tool, you know he’s gonna call you back when he wants changes made to the tool.

Sharpen your pencil

What would you change about this code?

There’s a big problem with the code shown above, and it’s up to you to figure it out. In the blanks below, write down what you think the problem is, and how you would fix it.

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

See what we said in Sharpen your pencil answers.

How easy is it to make this change to Rick’s application?

Take a look at the class diagram for Rick’s application, and think about what you would need to do to add support for 12-string guitars. What properties and methods would you need to add, and to what classes? And what code would you need to change to allow Rick’s clients to search for 12-strings?

How many classes did you have to modify to make this change? Do you think Rick’s application is well designed right now?

Guitar
serialNumber: String
price: double
spec: GuitarSpec
getSerialNumber(): String
getPrice(): double
setPrice(float)
getSpec(): GuitarSpec

Sharpen your pencil

Annotate Rick’s class diagram.

Rick wants to be able to sell 12-string guitars. Get out your pencil, and add notes to the class diagram showing the following things:

1. Where you’d add a new property, called numStrings, to store the number of strings a guitar has.

2. Where you’d add a new method, called getNumStrings(), to return the number of strings a guitar has.

3. What other code you think you’d need to change so that Rick’s clients can specify that they want to try out 12-string guitars.

Finally, in the blanks below, write down any problems with this design that you found when adding support for 12-string guitars.

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

Note

Here’s a hint: you should get an answer here related to what you wrote down in the blanks back in Let’s make sure Inventory.java is (really) well-designed.

GuitarSpec
builder: Builder
model: String
type: Type
backWood: Wood
topWood: Wood
getBuilder(): Builder
getModel(): String
getType(): Type
getBackWood(): Wood
getTopWood(): Wood

Inventory
guitars: List
addGuitar(String, double, Builder, String, Type, Wood, Wood)
getGuitar(String): Guitar
search(GuitarSpec): List

Brain Power

What’s the advantage of using a numStrings property instead of just adding a boolean property to indicate if a guitar is a 12-string?

Sharpen your pencil answers

Annotate Rick’s class diagram.

Rick wants to be able to sell 12-string guitars. Get out your pencil, and add notes to the class diagram showing the following things:

1. Where you’d add a new property, called numStrings, to store the number of strings a guitar has.

2. Where you’d add a new method, called getNumStrings(), to return the number of strings a guitar has.

3. What other code you think you’d need to change so that Rick’s clients can specify that they want to try out 12-string guitars.

Finally, in the blanks below, write down any problems with this design that you found when adding support for 12-string guitars.

That’s right—we need to encapsulate the guitar specifications and isolate them from the rest of Rick’s guitar search tool.

Even though you’re adding a property only to the GuitarSpec class, there are two other classes that have to be modified: Guitar and Inventory. The constructor of Guitar has to take an additional property now, and the search() method of Inventory has to do an extra property comparison.

Design Puzzle

It’s not enough to know what’s wrong with Rick’s app, or even to figure out that we need some more encapsulation. Now you need to actually figure out how to fix his app so it’s easier to reuse and extend.

The problem:

• Adding a new property to GuitarSpec.java results in changes to the code in Guitar.java and Inventory.java. The application should be restructured so that adding properties to GuitarSpec doesn’t affect the code in the rest of the application.

Your task:

1. Add a numStrings property and getNumStrings() method to GuitarSpec.java.

2. Modify Guitar.java so that the properties of GuitarSpec are encapsulated away from the constructor of the class.

3. Change the search() method in Inventory.java to delegate comparing the two GuitarSpec objects to the GuitarSpec class, instead of handling the comparison directly.

   Note

   Not sure what delegation is? Check this out...

4. Update FindGuitarTester.java to work with your new classes, and make sure everything still works.

   Note

   All you should have to do here is update your code that creates a sample inventory to use the new Guitar constructor.

5. Compare your answers with ours in Design Puzzle Solution, and then get ready for another test drive to see if we’ve finally got this application finished.

There are no Dumb Questions

Q:	Q: You said I should “delegate” comparisons to GuitarSpec. What’s delegation?
A:	A: Delegation is when an object needs to perform a certain task, and instead of doing that task directly, it asks another object to handle the task (or sometimes just a part of the task). So in the design puzzle, you want the search() method in Inventory to ask GuitarSpec to tell it if two specs are equal, instead of comparing the two GuitarSpec objects directly within the search() method itself. search() delegates the comparison to GuitarSpec.
Q:	Q: What’s the point of that?
A:	A: Delegation makes your code more reusable. It also lets each object worry about its own functionality, rather than spreading the code that handles a single object’s behavior all throughout your application One of the most common examples of delegation in Java is the equals() method. Instead of a method trying to figure out if two objects are equal, it calls equals() on one of the objects and passes in the second object. Then it just gets back a true or false response from the equals() method.
Q:	Q: And what does delegation have to do with code being more reusable?
A:	A: Delegation lets each object worry about equality (or some other task) on its own. This means your objects are more independent of each other, or more loosely coupled. Loosely coupled objects can be taken from one app and easily reused in another, because they’re not tightly tied to other objects’ code.
Q:	Q: And what does loosely coupled mean again?
A:	A: Loosely coupled is when the objects in your application each have a specific job to do, and they do only that job. So the functionality of your app is spread out over lots of well-defined objects, which each do a single task really well.
Q:	Q: And why is that good?
A:	A: Loosely coupled applications are usually more flexible, and easy to change. Since each object is pretty independent of the other objects, you can make a change to one object’s behavior without having to change all the rest of your objects. So adding new features or functionality becomes a lot easier.

The Scholar’s Corner

delegation. The act of one object forwarding an operation to another object, to be performed on behalf of the first object.

Design Puzzle Solution

It’s not enough to know what’s wrong with Rick’s app, or even to figure out that you need some more encapsulation. Now we need to actually figure out how to fix his app so we can test it out.

The problem:

• Adding a new property to GuitarSpec.java results in changes to the code in Guitar.java and Inventory.java. The application should be refactored so that adding properties to GuitarSpec doesn’t affect the code in the rest of the application.

Your task:

1. Add a numStrings property and getNumStrings() method to GuitarSpec.java.

   

2. Modify Guitar.java so that the properties of GuitarSpec are encapsulated away from the constructor of the class.

   

3. Change the search() method in Inventory.java to delegate comparing the two GuitarSpec objects to the GuitarSpec class, instead of handling the comparison directly.

   

One last test drive (and an app ready for reuse)

Wow, we’ve done a lot of work since Rick showed us that first version of his guitar app. Let’s see if the latest version still works for Rick and his clients, and manages to satisfy our own goal of having a well-designed, easily maintainable application that we can reuse.

Congratulations! You’ve turned Rick’s broken inventory search tool into a well-designed piece of great software.

What we did

Let’s take a quick look back at how we got Rick’s search tool working so well:

Remember this poor guy?

He just wanted to write great software. So what’s the answer? How do you write great software consistently?

You just need a set of steps to follow that makes sure your software works and is well designed. It can be as simple as the three steps we used in working on Rick’s app; you just need something that works, and that you can use on all of your software projects.

Object-Oriented Analysis & Design helps you write great software, every time

Note

We call this OOA&D for short.

All this time that we’ve been talking about the three steps you can follow to write great software, we’ve really been talking about OOA&D.

OOA&D is really just an approach to writing software that focuses on making sure your code does what it’s supposed to, and that it’s well designed. That means your code is flexible, it’s easy to make changes to it, and it’s maintainable and reusable.

OOA&D is about writing great software, not doing a bunch of paperwork!

Customers are satisfied when their apps WORK. We can get requirements from the customer to make sure that we build them what they ask for. Use cases and diagrams are helpful ways to do that, but it’s all about figuring out what the customer wants the app to do.

Note

We’ll talk all about requirements in Chapter 2.

Customers are satisfied when their apps KEEP WORKING. Nobody is happy when an application that worked yesterday is crashing today. If we design our apps well, then they’re going to be robust, and not break every time a customer uses them in unusual ways. Class and sequence diagrams can help show us design problems, but the point is to write well-designed and robust code.

Note

You’ve learned a bit about fragile apps already.

Customers are satisfied when their apps can be UPGRADED. There’s nothing worse than a customer asking for a simple new feature, and being told it’s going to take two weeks and $25,000 to make it happen. Using OO techniques like encapsulation, composition, and delegation will make your applications maintainable and extensible.

Note

Want more on delegation, composition, and aggregation? We’ll talk about all of these in detail in Chapter 5, and then again in Chapter 8.

Programmers are satisfied when their apps can be REUSED. Ever built something for one customer, and realized you could use something almost exactly the same for another customer? If you do just a little bit of analysis on your apps, you can make sure they’re easily reused, by avoiding all sorts of nasty dependencies and associations that you don’t really need. Concepts like the Open-Closed Principle (OCP) and the Single Responsibility Principle (SRP) are big time in helping here.

Note

You’ll get to see these principles really strut their stuff in Chapter 8.

Programmers are satisfied when their apps are FLEXIBLE. Sometimes just a little refactoring can take a good app and turn it into a nice framework that can be used for all sorts of different things. This is where you can begin to move from being a head-down coder and start thinking like a real architect (oh yeah, those guys make a lot more money, too). Big-picture thinking is where it’s at.

Note

Chapter 6 and Chapter 7 are all about looking at the big picture, and really developing a good architecture for your applications.

Note

This is ALL OOA&D! It’s not about doing silly diagrams... it’s about writing killer applications that leave your customer happy, and you feeling like you’ve kicked major ass.

Bullet Points

• It takes very little for something to go wrong with an application that is fragile.

• You can use OO principles like encapsulation and delegation to build applications that are flexible.

• Encapsulation is breaking your application into logical parts that have a clear boundary that allows an object to hide its data and methods from other objects.

• Delegation is giving another object the responsibility of handling a particular task.

• Always begin a project by figuring out what the customer wants.

• Once you’ve got the basic functionality of an app in place, work on refining the design so it’s flexible.

• With a functional and flexible design, you can employ design patterns to improve your design further, and make your app easier to reuse.

• Find the parts of your application that change often, and try and separate them from the parts of your application that don’t change.

• Building an application that works well but is poorly designed satisfies the customer but will leave you with pain, suffering, and lots of late nights fixing problems.

• Object oriented analysis and design (OOA&D) provides a way to produce well-designed applications that satisfy both the customer and the programmer.

OOA&D Cross

Let’s put what you’ve learned to use, and stetch out your left brain a bit. All of the words to answer the puzzle below are somewhere in this chapter. Good luck!

Across

Down

4. These help you avoid solving problems sameone else has already solved. 7. Customers focus on this port of your applications. 8. Objects in loosely coupled applications are more ___________ then tightly coupled ones. 9. Flexible applications are usually easy to ________. 10. This is one type of code you don’t want to write. 12. Your applications should be easy to __________. 13. You usually need some sort of process to write great Software __________. 14. Encapsulate what ________. 15. These types of applications satisfy programmers.

1. Once your application works correctly, focus on this. 2. Grouping your application into logical parts. 3. The goal of OOA&D is to help you write this type of Software. 5. Use this to let objects focus on more specific tasks. 6. A good way to avoid duplicate code 7. An application that things can go wrong in easily. 11. This is a four letter word your mom will be proud you know.

Why DO I Matter?

Exercise Solutions

You’ve learned a lot about writing great software, and there’s still more to go! Take a deep breath and think about some of the terms and principles we’ve covered. Connect the words on the left to the purpose of those techniques and principles on the right.

Sharpen your pencil answers

What would you change about this code?

There’s a big problem with the code shown above, and it’s up to you to figure it out. In the blanks below, write down what you think the problem is, and how you would fix it.

Every time a new property is added to GuitarSpec.java, or the methods in GuitarSpec change, the search() method in Inventory.java will have to change, too. We should let GuitarSpec handle comparisons, and encapsulate these properties away from Inventory.______________