A Note Regarding Supplemental Files

A. Leftovers: The Top Ten Topics (we didn’t cover)

Appendix B. Welcome to Objectville: Speaking the Language of OO

Get ready to take a trip to a foreign country. It’s time to visit Objectville, a land where objects do just what they’re supposed to, applications are all well-encapsulated (you’ll find out exactly what that means shortly), and designs are easy to reuse and extend. But before we can get going, there are a couple of things you need to know first, and a few language skills you’re going to have to learn. Don’t worry, though, it won’t take long, and before you know it, you’ll be speaking the language of OO like you’ve been living in the well-designed areas of Objectville for years.

Welcome to Objectville

Whether this is your first trip to Objectville, or you’ve visited before, there’s no place quite like it. But things are a little different here, so we’re here to help you get your bearings before you dive into the main part of the book.

UML and class diagrams

We’re going to talk about classes and objects a lot in this book, but it’s pretty hard to look at 200 lines of code and focus on the big picture. So we’ll be using UML, the Unified Modeling Language, which is a language used to communicate just the details about your code and application’s structure that other developers and customers need, without getting details that aren’t necessary.

Q:
Q: So the class diagram isn’t a very complete representation of a class, is it?
A:
A: No, but it’s not meant to be. Class diagrams are just a way to communicate the basic details of a class’s variables and methods. It also makes it easy to talk about code without forcing you to wade through hundreds of lines of Java, or C, or Perl.
Q:
Q: I’ve got my own way of drawing classes; what’s wrong with that?
A:
A: There’s nothing wrong with your own notation, but it can make things harder for other people to understand. By using a standard like UML, we can all speak the same language and be sure we’re talking about the same thing in our diagrams.
Q:
Q: So who came up with this UML deal, anyway?
A:
A: The UML specification was developed by Rational Software, under the leadership of Grady Booch, Ivar Jacobson, and Jim Rumbaugh (three really smart guys). These days it’s managed by the OMG, the Object Management Group.
Q:
Q: Sounds like a lot of fuss over that simple little class diagram thing.
A:
A: UML is actually a lot more than that class diagram. UML has diagrams for the state of your objects, the sequence of events in your application, and it even has a way to represent customer requirements and interactions with your system. And there’s a lot more to learn about class diagrams, too.
At this point, though, you just need the basics in UML and class diagrams. We’ll talk about other things you can show in a class diagram, and other types of diagrams, when we need them later in the book.

Next up: inheritance

One of the fundamental programming topics in Objectville is inheritance. That’s when one class inherits behavior from another class, and can then change that behavior if needed. Let’s look at how inheritance works in Java; it’s similar in other languages, too:

Note

Inheritance lets you build classes based on other classes, and avoid duplicating and repeating code.

Your job is to take code snippets from the pool below and place them into the blank lines in the code you see on the right. You may use the same snippet more than once, and you won’t need to use all the snippets. Your goal is to create a class that will compile, run, and produce the output listed.

Output:

public class FlyTest {
  public static void main(String[] args) {
    Airplane biplane = new Airplane();
    biplane.setSpeed(_____);
    System.out.println(_________________);
    Jet boeing = new Jet();
    boeing.setSpeed(_____);
    System.out.println(________________);
    __________;
    while (______) {
      __________________;
      System.out.println(__________________);
      if (___________________ > 5000) {
        ________________(__________________ * 2);
      } else {
        ___________________;
      }
      _______;
    }
    System.out.println(__________________);
  }
}

Solution in Pool Puzzle Solution

And polymorphism, too...

Polymorphism is closely related to inheritance. When one class inherits from another, then polymorphism allows a subclass to stand in for the superclass.

Q:
Q: What’s so useful about polymorphism?
A:
A: You can write code that works on the superclass, like Airplane, but will work with any subclass type, like Jet or Rocket. So your code is more flexible.
Q:
Q: I still don’t get how polymorphism makes my code flexible.
A:
A: Well, if you need new functionality, you could write a new subclass of Airplane. But since your code uses the superclass, your new subclass will work without any changes to the rest of our code! That means your code is flexible and can change easily.

Last but not least: encapsulation

Encapsulation is when you hide the implementation of a class in such a way that it is easy to use and easy to change. It makes the class act as a black box that provides a service to its users, but does not open up the code so someone can change it or use it the wrong way. Encapsulation is a key technique in being able to follow the Open-Closed principle. Suppose we rewrote our Airplane class like this:

Encapsulation is when you protect information in your code from being used incorrectly.

Now anyone can set the speed directly

This change means that the rest of your app no longer has to call setSpeed() to set the speed of a plane; the speed variable can be set directly. So this code would compile just fine:

$image with no caption$

So what’s the big deal?

Doesn’t seem like much of a problem, does it? But what happens if you create a Jet and set its speed like this:

What’s the value of encapsulating your data?

Type in, compile, and run the code for FlyTest3.java, shown above. What did your output look like? Write the two lines of output in the blanks below:

Speed of jet1: ________________

Speed of jet2: ________________

What do you think happened here? Write down why you think you got the speeds that you did for each instance of Jet:

_____________________________________________________________________

Finally, summarize what you think the value of encapsulation is:

_____________________________________________________________________

Q:
Q: So encapsulation is all about making all your variables private?
A:
A: No, encapsulation is about separating information from other parts of your application that shouldn’t mess with that information. With member variables, you don’t want the rest of your app directly messing with your data, so you separate that data by making it private. If the data needs to be updated, you can provide methods that work with the data responsibly, like we did with the Airplane class, using getSpeed() and setSpeed().
Q:
Q: So are there other ways to use encapsulation besides with variables?
A:
A: Absolutely. In fact, in Chapter 1, we’ll be looking at how you can encapsulate a group of properties away from an object, and make sure that the object doesn’t use those properties incorrectly. Even though we’ll deal with an entire set of properties, it’s still just separating a set of information away from the rest of your application.
Q:
Q: So encapsulation is really about protecting your data, right?
A:
A: Actually, it’s even more than that! Encapsulation can also help you separate behavior from other parts of your application. So you might put lots of code in a method, and put that method in a class; you’ve separated that behavior from the rest of your application, and the app has to use your new class and method to access that behavior. It’s the same principles as with data, though: you’re separating out parts of your application to protect them from being used improperly.
Q:
Q: Wow, I’m not sure I’m following all of this. What do I need to do?
A:
A: Just keep reading. Make sure you understand the exercise solutions in Sharpen your pencil answers, and you’re ready for Chapter 1. We’ll spend a lot more time on all of these OO principles and concepts, so don’t feel like you need to get everything down perfectly at this point.
Encapsulation separates your data from your app’s behavior.
Then you can control how each part is used by the rest of your application.

UML stands for the Unified Modeling Language.
UML helps you communicate the structure of your application to other developers, customers, and managers.
A class diagram gives you an overview of your class, including its methods and variables.
Inheritance is when one class extends another class to reuse or build upon the inherited class’s behavior.
In inheritance, the class being inherited from is called the superclass; the class that is doing the inheritance is called the subclass.
A subclass gets all the behavior of its superclass automatically.
A subclass can override its superclass’s behavior to change how a method works.
Polymorphism is when a subclass “stands in” for its superclass.
Polymorphism allows your applications to be more flexible, and less resistant to change.
Encapsulation is when you separate or hide one part of your code from the rest of your code.
The simplest form of encapsulation is when you make the variables of your classes private, and only expose that data through methods on the class.
You can also encapsulate groups of data, or even behavior, to control how they are accessed.

Take a moment to review the concepts in this appendix, and then you’re ready to step firmly into the world of analysis, design, OO programming, and great software.

Across	Down
3. This is when a subclass can substitute for its superclass. 4. Class diagrams don’t show details about this part of our class. 5. A class that inherits from another class is this. 6. Encapsulation lets you do this to information. 7. A class that is inherited from is called this.	1. Another term for encapsulation id separation of this. 2. Polymorphism helps make your code ____________. 4. Use this kind of diagram to avoid wading through lots of code.

Across

Down

3. This is when a subclass can substitute for its superclass.

4. Class diagrams don’t show details about this part of our class.

5. A class that inherits from another class is this.

6. Encapsulation lets you do this to information.

7. A class that is inherited from is called this.

1. Another term for encapsulation id separation of this.

2. Polymorphism helps make your code ____________.

4. Use this kind of diagram to avoid wading through lots of code.

Previous Chapter

A. Leftovers: The Top Ten Topics (we didn’t cover)

Next Chapter

Index

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

Appendix B. Welcome to Objectville: Speaking the Language of OO

Welcome to Objectville

UML and class diagrams

Next up: inheritance

Note

And polymorphism, too...

Last but not least: encapsulation

Now anyone can set the speed directly

So what’s the big deal?

Note

Highlight

Highlight

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