Skip to main content
Logo image

Java, Java, Java: Object-Oriented Problem Solving, 2022E

Section 0.8 What Is Object-Oriented Programming?

Java is an object-oriented (OO) language, and this book takes an object-oriented approach to programming. So before beginning our discussion of Java, we need to talk about:
  • what an object is
  • how objects are grouped into classes
  • how classes are related to each other
  • how objects use messages to interact with each other

Subsection 0.8.1 Basic OOP Metaphor: Interacting Objects

A Java program, and any object-oriented program, is a collection of interacting objects that models a collection of real-world objects.
Figure 0.8.1. This UML diagram illustrates an ATM transaction in which a customer asks the ATM machine for their current balance.
For example, in the ATM transaction pictured in Figure 0.8.1, a customer uses an ATM machine to check their account balance. There are three entities involved: (1) the customer, (2) the bank machine, and (3) the customer’s bank account.
If you were writing the Java program for the ATM machine, you would represent each of those entities as Java objects.

Subsection 0.8.2 What is an Object?

So what is an object? Just as in the real world, an object is any thing whatsoever. An object can be a physical thing, such as an ATM, or a mental thing, such as an Idea. It can be a natural thing, such as an Customer, or an artificial, human-made thing, such as a BankAccount.
Throughout this text, we will use the notation shown in Figure 0.8.2 to depict objects and to illustrate object-oriented concepts. The notation is known as the Unified Modeling Language, or UML for short, and it is a standard in the object-oriented programming community.
As the diagram shows, an object is represented by a rectangle whose label consists of the object’s (optional) id and its type. An object’s id is the name by which it is referred to in the computer program.
Figure 0.8.2. In UML, objects are represented by rectangles that are labeled with a two-part label of the form id:Type. The object’s label is always underlined.

Subsection 0.8.3 Attributes and Values

Just as with real objects, the objects in our programs have certain characteristic attributes. For example, an ATM object would have a current amount of cash that it could dispense. A Customer object would have a name, address, and account number. Notice that an object’s attributes are themselves objects. The ATM’s cash and the customer’s account number are Number objects.
Figure 0.8.3 shows two ATM objects and their respective attributes. As you can see, an object’s attributes are listed in a second partition of the UML diagram. Notice that each attribute has a value. So the lobby:ATM has a $8650.0 in cash, while the drivethru:ATM has only $150.0 in cash.
Figure 0.8.3. A second partition of an object diagram is used to display the object’s attributes and their values.
We sometimes refer to an object’s attributes and their values as its state. For example, the current state of the lobby:ATM is $8650.0 in cash. Some transactions, such as depositing or withdrawing money, would change the ATM’s state.
Of course, this is a gross simplification of an ATM’s state, which would also include many other attributes. But, hopefully, you see the point.

Subsection 0.8.4 Actions and Messages

In addition to their attributes, objects also have characteristic actions or behaviors. Objects do things or have things done to them. In fact, programming in Java is largely a matter of getting objects to perform certain actions for us.
For example, when a customer pushes the “Current Balance” button on an ATM machine, this is telling the ATM to report the customer’s current bank balance. This is represented in Figure 0.8.1 by the arrow between the customer and ATM objects. In respose to the button-press the ATM object sends a "get balance" request to the customer’s account object, which returns the value 528.52. The ATM object then displays this value to the customer.
In this way, the actions associated with an object can be used to send messages to the objects and to retrieve information from objects. A message is the passing of information or data from one object to another, as represented by the arrows in Figure 0.8.1.
Responding to a message or performing an action sometimes causes a change in an object’s state. For example, if the ATM customer requested a $20 withdrawal, their bank account’s balance would be reduced by $20. On the other hand, some messages (or actions) leave the object’s state unchanged. Reporting the customer’s bank account balance doesn’t change the balance.

Subsection 0.8.5 What is a Class?

Objects are organized into classes. Both the lobby and driveThru ATMs are members of the ATM class (Figure 0.8.3). All members of a given class share the same attributes and actions. We say that an object is an instance of a class.
In an object-oriented program, a class definition serves as a blueprint or template for the objects that the program uses. It describes the attributes and actions that characterize the objects of that class.
A good analogy here is to think of a class definition as a cookie cutter and its objects, or instances, as individual cookies. Just as we use the cookie cutter to stamp out cookies of a certain shape, in an object-oriented program, we use class definitions to create objects of a certain type.
Writing an object-oriented program is largely a matter of designing classes and writing definitions for those classes in Java. Designing a class is a matter of specifying all of the attributes and behaviors that are characteristic of that type of object.
Figure 0.8.4. A UML diagram of the Account class.
Figure 0.8.4 shows a UML diagram of a scaled down Account class for our ATM example. A UML class symbol has up to three partitions. The top partition gives just the class’s name and it is not underlined. The second partition lists the class’s attributes and the third partition lists the class’s actions.
Our simplified Account objects have two attributes. customerID and balance and can perform two actions, validateID and reportBalance(). Note that the attributes have no values. Only the claas’s objects, its instances, will have values for these attributes.

Subsection 0.8.6 Variables and Methods

Up to this point we have been using the terms attribute and action to describe an object’s features. We will continue to use this terminology when talking in general about objects or when talking about an object or class represented by a UML diagram.
However, when talking about Java code, the more common way to describe an object’s features are to talk about its variables and methods. A variable, which corresponds to an attribute, is a named memory location that can store a certain type of value.
For example, as Figure 0.8.4 shows, customerID and is a variable that can store whole number (int) values, such as 100009044 And balance is a variable that can store decimal (double) values, such as 582.74.
A method, which corresponds to an action or a behavior, is a named chunk of code that can be called upon or invoked to perform a certain pre-defined set of actions. For example, as its name suggests, the reportBalance() method reports the customer’s account balance.

Subsection 0.8.7 Class Hierarchy and Inheritance

How are classes related to each other? In Java, and in any other object-oriented language, classes are organized in a class hierarchy.
A class hierarchy is like an upside-down tree. At the very top of the hierarchy is the most general class. In Java, the most general class is the Object class. The classes below Object in the hierarchy are known as its subclasses. Since all of the objects we use in our programs belong to some class or other, this is like saying that every object is an Object.
Figure 0.8.5 illustrates the concept of a class hierarchy using some of the classes described in this section. Notice that the Object class occurs at the top of the hierarchy. It is the most general class. It has features that are common to all Java objects.
As you move down the hierarchy, the classes become more and more specialized. An Account is an Object but it contains attributes — customerID and balance — that it more specialized than its parent class (Object).
Notice that we have added a Person class to the hierarchy as the superclass of Customer. Customers are more specialized than persons—they have bank accounts.
Figure 0.8.5. A hierarchy of Java classes.
A subclass is said to inherit the attributes (variables) and actions (methods) of its superclass. Thus, a Customer would inherit things like a name, address, phone number and other attributes from the Person class. The subclass is said to extend the superclass by adding attributes and actions to those it inherits.
This class inheritance is similar to the classification of natural things. A horse is a mammal. Horses inherit the characteristic of being warm blooded by virtue of also being mammals. But they also have specialized attribues —manes hooves— that distinguish them from other mammals, such as cows and humans.

Subsection 0.8.8 Principles of Object-Oriented Design

As we embark on learning object-oriented programming in Java, there are a number of principles and practices that we will aspire towards.
  • Divide-and-Conquer Principle. Generally, we will divide solutions to problems into sets of interacting objects, each with its own specialized tasks,
  • Encapsulation Principle. Each object will encapsulate the expertise, attributes and actions that it needs to carry out its role in the solution.
  • Interface Principle. Each object will present an interface to other objects that will limit the way they interact with each other.
  • Information Hiding Principle. Objects will be designed to hide certain information and implementation details from other objects.
  • Generality Principle. Objects will be designed as generally as possible. So that rather than solving only a particular problem they can solve similar problems of the same kind.
  • Extensibility Principle. Objects will be designed so that they can potentially be extended to perform related tasks.
  • Abstraction Principle. The objects we design will be abstractions because they will ignore many of the attributes and actions that characterize the real objects they represent. They will include only on those attributes and behaviors needed to solve a particular problem.
Although these principles may not mean much to you now, they will become clear as we use them to learn how to design and write object-oriented Java programs.
You have attempted of activities on this page.