Table of Contents for

Head First Object-Oriented Analysis and Design

So far, we’ve really been concentrating on all the things that you do before you start coding your application. Gathering requirements, analysis, writing out feature lists, and drawing use case diagrams. Of course, at some point you actually are going to have to write some code. And that’s where design principles really come into play.

Note

A design principle is a basic tool or technique that can be applied to designing or writing code to make that code more maintainable, flexible, or extensible.

You’ve already seen a few design principles in earlier chapters:

In this chapter, we’re going to look at several more key design principles, and how each one can improve the design and implementation of your code. We’ll even see that sometimes you’ll have to choose between two design principles... but we’re getting ahead of ourselves. Let’s begin by looking at the first of our design principles.

Our first design principle is the OCP, or the Open-Closed principle. The OCP is all about allowing change, but doing it without requiring you to modify existing code. Here’s how we usually define the OCP:

Note

Open-Closed Principle

Classes should be open for extension, and closed for modification.

Closed for modication...

Suppose you have a class with a particular behavior, and you’ve got that behavior coded up just the way you want it. Make sure that nobody can change your class’s code, and you’ve made that particular piece of behavior closed for modification. In other words, nobody can change the behavior, because you’ve locked it up in a class that you’re sure won’t change.

... but open for extension

But then suppose someone else comes along, and they just have to change that behavior. You really don’t want them messing with your perfect code, which works well in almost every situation... but you also want to make it possible for them to use your code, and extend it. So you let them subclass your class, and then they can override your method to work like they want it to. So even though they didn’t mess with your working code, you still left your class open for extension.

You probably didn’t realize it, but we were using the Open-Closed Principle when we wrote those InstrumentSpec classes for Rick’s Stringed Instruments, back in Chapter 5:

Let’s take what we did back in Chapter 5, and look at in terms of the OCP, one step at a time.

The OCP is about flexibility, and goes beyond just inheritance.

It’s certainly true that inheritance is a simple example of the open-closed principle, but there’s a lot more to it than just subclassing and overriding a method. Anytime you write working code, you want to do your best to make sure that code stays working... and that means not letting other people change that code.

But there are going to be times when that code still needs to be changed, maybe for just one or two particular situations. Rather than just diving into your code and making a bunch of changes, the OCP lets you extend your working code, without changing that code.

There are lots of different ways to accomplish this, and while inheritance is often the easiest to implement, it’s certainly not the only option. In fact, we’ll talk about another great way to achieve this later in the chapter, when we talk about composition.

Next up is the Don’t Repeat Yourself principle, or DRY for short. This is another principle that looks pretty simple, but turns out to be critical in writing code that’s easy to maintain and reuse.

Note

Don’t Repeat Yourself

Avoid duplicate code by abstracting out things that are common and placing those things in a single location.

A prime place to apply DRY...

You’ve seen the DRY principle in action, even if you didn’t realize it. We used DRY back in Chapter 2, when Todd and Gina wanted us to close the dog door automatically after it had been opened.

1. Let’s abstract out the common code

Using DRY, we first need to take the code that’s common between Remote and BarkRecognizer, and put it in a single place. We figured out back in Chapter 2 the best place for it was in the DogDoor class:

3. ...and reference the code from Step #1

The next two steps happen at the same time. Remove all the code that you put in a single place in Step #1, and then reference the code you abstracted out explicitly if you need to:

Abstracting out duplicate code is a good start to using DRY, but there’s more to it than just that. When you’re trying to avoid duplicate code, you’re really trying to make sure that you only implement each feature and requirement in your application one single time.

In the dog door we just looked at, the feature we were trying to implement was automatically closing the door.

Originally, though, we implemented that single feature in two places: Remote.java and BarkRecognizer.java.

By using DRY, we removed the duplicate code. But more importantly, we moved the implementation of this requirement, automatically closing the door, into one place, instead of two places:

There are no Dumb Questions

Q:	Q: So DRY isn’t about duplicate code, and avoiding copy-and-paste?
A:	A: DRY is about avoiding duplicate code, but it’s also about doing it in a way that won’t create more problems down the line. Rather than just tossing code that appears more than once into a single class, you need to make sure each piece of information and behavior in your system has a single, clear place where it exists. That way, your system always knows exactly where to go when it needs that information or behavior.
Q:	Q: If DRY is related to our features and requirements, then shouldn’t we apply it to gathering those features and requirements as well as writing our code?
A:	A: Absolutely, and that’s a great idea! Whether you’re writing requirements, developing use cases, or coding, you want to be sure that you don’t duplicate things in your system. A requirement should be implemented one time, use cases shouldn’t have overlap, and your code shouldn’t repeat itself. DRY is about a lot more than just code.
Q:	Q: And this is all to avoid maintenance problems later, right?
A:	A: Right. But it’s more than just avoiding a need to update code in more than one place. Remember, DRY is about having a single source for a particular piece of information or behavior. But that single source has to make sense! You wouldn’t want the bark recognizer to be the single source for closing the dog door, would you? Do you think the dog door should be asking the recognizer to close itself? So DRY is not just removing duplication, it’s also about making good decisions about how to break up your system’s functionality.

DRY is about having each piece of information and behavior in your system in a single, sensible place.

Design Puzzle

DRY is about a lot more than just finding duplicate code in your system. It also applies to your features and requirements. It’s time to put DRY into action on your own now, and to do it in more than just code.

The problem:

Todd and Gina have come up with yet more features for their dog door. It’s your job to make sure the feature list we’ve assembled doesn’t have any duplication issues, and that each feature is handled once and only once in the system you’re designing for them.

Your task:

1. Read through the requirements and features list on the right. We’ve bolded the requirements and features that have been added since you last worked on the dog door.

2. Look through the new features and requirements, and see if you see any possible duplication in the new things you’d need to build.

3. Annotate the requirements and features list indicating what you think has been duplicated.

4. Rewrite the duplicate requirements at the bottom of the list so that there is no more duplication.

5. Write a new definition for the DRY principle in the space below, and make sure you talk about more than just duplicate code.

Note

Don’t Repeat Yourself

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

Write your own definition for DRY that includes what you’ve learned over the last few pages.

Solutions on the next page.

Design Puzzle Solutions

DRY is about a lot more than just finding duplicate code in your system. It also applies to your features and requirements. Your job was to put DRY into action on your own, in the context of requirements rather than just code.

The problem:

Todd and Gina have come up with yet more features for their dog door. It’s your job to make sure the feature list we’ve assembled doesn’t have any duplication issues, and that each feature is handled once and only once in the system you’re designing for them.

Your task:

1. Read through the requirements and features list on the right. We’ve bolded the requirements and features that have been added since you last worked on the dog door.

2. Look through the new features and requirements, and see if you see any possible duplication in the new things you’d need to build.

3. Annotate the requirements and features list indicating what you think has been duplicated.

4. Rewrite the duplicate requirements at the bottom of the list so that there is no more duplication.

5. Write a new definition for the DRY principle in the space below, and make sure you talk about more than just duplicate code.

The SRP is all about responsibility, and which objects in your system do what. You want each object that you design to have just one responsibility to focus on—and when something about that responsibility changes, you’ll know exactly where to look to make those changes in your code.

Note

Single Responsibility Principle

Every object in your system should have a single responsibility, and all the object’s services should be focused on carrying out that single responsibility.

Most of the time, you can spot classes that aren’t using the SRP with a simple test:

Sharpen your pencil

Apply the SRP to the Automobile class.

Do an SRP analysis on the Automobile class shown below. Fill out the sheet with the class name methods in Automobile, like we’ve described on the last page. Then, decide if you think it makes sense for the Automobile class to have each method, and check the right box.

Sharpen your pencil answers

Apply the SRP to the Automobile class.

Your job was to do an SRP analysis on the Automobile class shown below. You should have filled out the sheet with the class name methods in Automobile, and decided if you think it makes sense for the Automobile class to have each method.

Once you’ve done an analysis, you can take all the methods that don’t make sense on a class, and move those methods to classes that do make sense for that particular responsibility.

SRP Sightings

The SRP has already made a few appearances in our work so far; now that you’re getting familiar with the SRP, it’s time for you to figure out where and how it’s been used. Your task is to look at the page below and figure out how SRP was used, and why.

How do you think the Single Responsibility Principle was used in Todd and Gina’s dog door? Write your answer in the blanks below:

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

Now see if you can find two more instances in the book’s examples so far where we’ve used the SRP to make our design better and more flexible. You can find the SRP in the dog door, Rick’s instrument inventory searcher, or Gary’s game framework. Write down each instance you found, and how you think the SRP is being used.

SRP Sightings Revealed!

Let’s look back on the times that SRP has already shown up in our software. Here are the SRP sightings we came up with; see if your answers are similar.

How do you think the Single Responsibility Principle was used in Todd and Gina’s dog door? Write your answer in the blanks below:

Now see if you can find two more instances in the book’s examples so far where we’ve used the SRP to make our design better and more flexible. You can find the SRP in the dog door, Rick’s instrument inventory searcher, or Gary’s game framework. Write down each instance you found, and how you think the SRP is being used.

First Instance

Example application:

Rick’s Instruments

___ Doug’s Dog Doors

_____ Gary’s Games

How SRP is being used:

Second Instance

Example application:

___Rick’s Instruments

___Doug’s Dog Doors

Gary’s Games

How SRP is being used:

When we used a Map to store properties for all types of units in the Unit class, we were using the SRP. So instead of having game-specific Units have to deal with their properties, and still have the base Unit class dealing with a different set of properties, we moved all property-related functionality into the nit class. So handling the properties feature is taken care of in ONE single place—the Unit class.

Next up in our design principle parade is the Liskov Substitution Principle, or the LSP. It’s definition is as simple as it gets:

The LSP is all about well-designed inheritance. When you inherit from a base class, you must be able to substitute your subclass for that base class without things going terribly wrong. Otherwise, you’ve used inheritance incorrectly!

Suppose that Gary’s Games has a new client who wants to use their game system framework to create World War II air battles. They need to take the basic Board base type, and extend it to support a 3-dimensional board to represent the sky. Here’s what they’ve done:

At first glance, it may seem like subclassing Board and using inheritance is a great idea. But look closer, there are lots of problems that this approach creates:

The 3DBoard class is not substitutable for Board, because none of the methods on Board work correctly in a 3D environment. Calling a method like getUnits(2, 5) doesn’t make sense for 3DBoard. So this design violates the LSP.

We already said that LSP states that a subtype must be substitutable for its base type. But what does that really mean? Technically, it doesn’t seem to be a problem:

But when you start to actually use that instance of 3DBoard like a Board, things can get confusing very fast:

So even though 3DBoard is a subclass of Board, it’s not substitutable for Board... the methods that 3DBoard inherited don’t have the same meaning as they do on the superclass. Even worse, it’s not clear what meaning those methods do have!

It might seem like this isn’t such a big deal, but code that violates LSP can be confusing, and a real nightmare to debug. Let’s think a bit about someone who comes to use the badly designed 3DBoard for the first time.

They probably start out by checking out the class’s methods:

It’s hard to understand code that misuses inheritance.

When you use inheritance, your subclass gets all the methods from its superclass, even if you don’t want those methods. And if you’ve used inheritance badly, then you’re going to end up with a lot of methods that you don’t want, because they probably don’t make sense on your subclass.

So what can you do to avoid this? First, be sure your subclasses can substitute for their base types, which is just following the LSP. Second, learn about some alternatives to using inheritance in your code...

It’s not enough to just know that inheritance isn’t the answer... now we’ve got to figure out what we should have done. Let’s look at the Board and 3DBoard classes again, and see how we can create a 3-dimensional board without using inheritance.

You’ve already seen that delegation is when one class hands off the task of doing something to another class. It’s also just one of several alternatives to inheritance.

Note

Delegation is when you hand over the responsibility for a particular task to another class or method.

Delegation was what we used to solve the 3DBoard problem we’ve been looking at, without resorting to inheritance:

Delegation is best used when you want to use another class’s functionality, as is, without changing that behavior at all. In the case of 3DBoard, we wanted to use the various methods in the Board class:

Since we don’t want to change the existing behavior, but we do want to use it, we can simply create a delegation relationship between 3DBoard and Board. 3DBoard stores multiple instances of Board objects, and delegates handling each individual board-related task.

Sometimes delegation isn’t quite what you need; in delegation, the behavior of the object you’re delegating behavior to never changes. 3DBoard always uses instances of Board, and the behavior of the Board methods always stay the same.

But in some cases, you need to have more than one single behavior to choose from. For example, suppose we wanted to develop a Weapon interface, and then create several implementations of that interface that all behave differently:

Now we need to use the behavior from these classes in our Unit class. One of the properties in our properties Map will be “weapon”, and the value for that property needs to be an implementation of the Weapon class. But a Unit might change weapons, so we don’t want to tie the weapon property to a specific implementation of Weapon; instead, we just want each Unit to be able to reference a Weapon, regardless of which implementation of Weapon we want to use.

When we reference a whole family of behaviors like in the Unit class, we’re using composition. The Unit’s weapons property is composed of a particular Weapon implementation’s behavior. We can show this in UML like this:

Composition is most powerful when you want to use behavior defined in an interface, and then choose from a variety of implementations of that interface, at both compile time and run time.

Note

Composition allows you to use behavior from a family of other classes, and to change that behavior at runtime.

There’s one important point we haven’t mentioned so far about composition. When an object is composed of other objects, and the owning object is destroyed, the objects that are part of the composition go away, too. That’s a little confusing, so let’s take a closer look at what that actually means.

Here’s our Unit class again, which has a composition relationship to the Weapon interface and its implementations:

Suppose we create a new Unit, and assign its weapon property to an instance of Sword:

What happens if this Unit is destroyed? Obviously, the pirate variable is trashed, but the instance of Sword referenced by pirate is also thrown away. It doesn’t exist outside of the pirate object.

What happens when you want all the benefits of composition—flexibility in choosing a behavior, and adhering to the LSP—but your composed objects need to exist outside of your main object? That’s where aggregation comes in.

Note

Aggregation is when one class is used as part of another class, but still exists outside of that other class.

You’ve already used aggregation...

We’ve been using aggregation already, in Rick’s Stringed Instruments, from Chapter 5:

It’s easy to get confused about when you should use composition, and when you should use aggregation. The easiest way to figure this out is to ask yourself, Does the object whose behavior I want to use exist outside of the object that uses its behavior?

If the object does make sense existing on its own, then you should use aggregation; if not, then go with composition. But be careful! Sometimes the slightest change in the usage of your objects can make all the difference.

We started out this section talking about the LSP, and the basic idea that subclasses must be substitutable for their base classes. More importantly, though, now you have several ways to reuse behavior from other classes, beyond inheritance.

Let’s take a quick look back at our options for reusing behavior from other classes, without resorting to subclassing.

Delegation

Delegate behavior to another class when you don’t want to change the behavior, but it’s not your object’s responsibility to implement that behavior on its own.

Composition

You can reuse behavior from one or more classes, and in particular from a family of classes, with composition. Your object completely owns the composed objects, and they do not exist outside of their usage in your object.

Aggregation

When you want the benefits of composition, but you’re using behavior from an object that does exist outside of your object, use aggregation.

Who Am I?

A bunch of classes involved in OO principles, all in full costume, are playing a party game, Who Am I? They give a clue, and you try to guess who they are, based on what they say. Assume they always tell the truth about themselves. If they happen to say something that could be true for more than one of them, choose all for whom that sentence can apply. Fill in the blanks next to the sentence with the names of one or more attendees. The first one’s on us.

Tonight’s attendees:

I’m substitutable for my base type.	___________________________________
I let someone else do things for me.	___________________________________
My behavior is used as part of another class’s behavior.	___________________________________
I change the behavior of another class.	___________________________________
I don’t change the behavior of another class.	___________________________________
I can combine the behavior of other classes together.	___________________________________
I’m not gonna go away, even if other related classes do.	___________________________________
I get my behavior and functionality from my base type.	___________________________________

Unmask the principles in Who Am I? Solutions

Tools for your OOA&D Toolbox

We’ve got a lot more OO principles to add to the toolbox. Let’s add what we’ve learned to our notes—and remember: these principles are best used together, not separately!

OOA&D Cross

This one is a particularly tough puzzle: almost all the answers are more than one word. Good luck, and keep that left brain working.

Across

Down

1. A variation in composition. 3. This is when one object owns behaviors from other objects. 6. This is when you hand over responsibility for a particular behavior. 7. He was all about substitution. 8. The LSP reveals problems related to this. 11. You should keep a single piece of code in this many places. 13. You should have each piece of your information and this in a single, sensible place. 14. ________ Out things that are common in your code. 15. Each object in your system should have this many responsibilities. 16. This is overrated in good OO software design. 17. Another term for SRP is this.

2. Aggregated objects exist _______ of the classes that use them. 4. Subtypes must be substitutable for these. 5. Classes should be closed for this. 9. OO principles work best when used this way. 10. A well-designed class has only one reason to do this. 12. Classes should be open for this.

Who Am I? Solutions

A bunch of classes involved in OO principles, all in full costume, are playing a party game, Who Am I? Solutions They give a clue, and you try to guess who they are, based on what they say. Assume they always tell the truth about themselves. If they happen to say something that could be true for more than one of them, choose all for whom that sentence can apply. Fill in the blanks next to the sentence with the names of one or more attendees. The first one’s on us.

Tonight’s attendees:

Exercise Solutions