Object Orientation in Java
A
h, objects. Some people take to object orientation (OO) like a duck to water. Most people
don’t really get it for a while (6 to 18 months). But when they do get it, they become evangelists
for OO.
I coded procedural programs for close on 18 years before embarking on this OO journey.
Although I learned Java in 1997, I treated it like another C. In 1999, however, a gifted man
(Stuart Fripp) introduced me to OO and UML. I liked what I saw and started using it in my
projects. It was only in late 2000 that I felt I was designing properly in OO.
I tell you this story so that you will persevere with OO. It is difficult to convert from proce-
dural to object oriented programming, but please don’t give up. The benefits are real and
very cool.
By the way, does SAP “get” OO? They are certainly on the right path.
The Pillars of OO
These are the four pillars of OO:
• Inheritance
• Encapsulation
• Abstraction
• Polymorphism
It is very difficult to talk about inheritance without discussing polymorphism, so I’ll deal
with those two together. First, though, I would like to discuss the structure of a Java class.
49
LESSON 11
■ ■ ■
6250CH11.qxd 2/23/06 11:25 AM Page 49
Java Class Structure
Figure 11-1 shows a simple diagram of a Java class. The outside box is the class container—we
define a class in Java using the class keyword.
Figure 11-1. Java class schematic
Between the class definition and the first method, we can declare our instance variables.
These are variables you would like the whole class to see (although it’s not the same thing, you

on. Bear with me, this is just an example. I’ll extend it a bit in the future.
The generic BankAccount class will never be instantiated directly. In Lesson 7 we created
an instance of the String class like this (or said we could have):
String s = new String("Hello");
The new keyword means that a new instance of the class has been created, and we have called
it s.
Let’s briefly take a step back. Think of your class as being the design or specification for an
object—the blueprint of a house, for example. A house can be built many times from one set
of blueprints, and similarly, many objects can be instantiated from one class.
Cast your mind back to Lesson 2, and you’ll recognize Figure 11-2, which represents the
BankAccount class. We can see that it holds a private attribute and four public methods. (And
you can see that I’m not sticking to strict UML notation here. Please don’t report me to the OO
police just yet!)
Figure 11-2. The BankAccount class
LESSON 11
■
OBJECT ORIENTATION IN JAVA 51
6250CH11.qxd 2/23/06 11:25 AM Page 51
We can now create the classes for the three other types of accounts we want to “inherit
from” our BankAccount class: the CreditCard class, the SavingsAccount class, and the Check-
Account class. To show inheritance in UML, we draw the classes as we would draw an
organizational diagram—take a look at Figure 11-3.
Figure 11-3. Inheriting from the BankAccount class
So, let’s look at what we’re doing here. The three subclasses of the BankAccount class
inherit all the methods from the BankAccount class, free of charge. So if you have some superb
functionality in your BankAccount class (also known as the superclass), you already have it in
your subclass just by saying that the subclass extends the superclass.
If we were to look at the class signature of the SavingsAccount class, we would see this:
class SavingsAccount extends BankAccount
As a result, we do not have to recode any of the methods contained in the BankAccount class.

public void withdrawal(BigDecimal amount)
This technique is called overloading, and the really smart thing about Java is that the
correct method to be called is only determined at run time. (As an exercise, write a little
program to test this feature, called late binding in Java.)
■
Tip
Keep in mind that this is just an introduction to Java. I recommend you read Bruce Eckel’s Thinking in
Java for a good explanation of these concepts (
http://www.bruceeckel.com
).
Encapsulation
Encapsulation is the “hiding” of methods and data. I like to think of a wooden box with several
partitions that only has one opening to the outside world (see Figure 11-4). All data must pass
through this one hole.
Notice how I’ve called the area that is directly accessible “public,” and the area that is not
directly accessible “private.” We’ll cover these terms again in a moment, but you can see that I
can hide my data away in the private area.
So why would I want to hide things from my fellow programmers? Is it because I don’t
trust them? No, of course not. I’m going to let people who use my class, do so in the way I want
them to use it.
LESSON 11
■
OBJECT ORIENTATION IN JAVA 53
6250CH11.qxd 2/23/06 11:25 AM Page 53
Figure 11-4. The wooden box analogy
For example, car manufacturers expect us to use the gas pedal to make the car go faster
and the brake to slow it down. The manufacturers don’t want us messing with the engine
directly to speed up or slow down, so they give us a convenient, standard, and predictable way
to interact with it. They encapsulate the engine behind a firewall (the real kind).
We want to do the same thing with our classes. Not through arrogance or malice, but so

// code here to do the work! Updates repayment.
}
// Now we allow the class user to access the repayment amount
public double getRepayment()
{
return repayment;
}
} // end of class
I want to point out several things in this code. The first is that I am “hiding” the class vari-
ables. I do not want anyone to mess with these, so I declared my variables private.
So if the variables are hidden, how do I pass the necessary information to the class? I do
this by means of a special once only method called a constructor. The constructor cannot have
any return type, not even void. It must also have exactly the same name as the class.
The constructor’s primary job is to initialize instance variables, and we call it after the new
keyword. Here’s what it would look like in the calling program:
Loans ln = new Loans(250000.00, 240.00, 5.00);
Notice how the constructor of the Loans class is called after the new keyword.
If you understand how block scope works, you will realize that the instance variable
principal and the variable principal declared in the method signature of the constructor
are two different variables! To confuse the issue further, they have exactly the same name.
Tricky, hey!
Fortunately we can use a special this keyword, which tells us (and the Java compiler) that
we are talking about the instance variable and not the variable defined in the method. You can
see that since I don’t have that problem with interest and int, I do not have to use the this
keyword. By the way, we can use the this keyword to denote methods as well. If you want to
specify a method from the current class, you could (optionally) use this to make it clear.
The last line in the constructor calls the calcLoan method.
The next method, the calcLoan method, I’ve declared as private. This effectively means
that it can only be used from within its own class. It can’t be inherited, and it can’t be seen
until an instance of this class is created. This is fine with me. It’s a complex method, and only

■
OBJECT ORIENTATION IN JAVA56
6250CH11.qxd 2/23/06 11:25 AM Page 56