Welcome!

Java Authors: Pat Romanski, Yeshim Deniz, Bob Gourley, JP Morgenthal, Jim Kaskade

Related Topics: Java

Java: Article

Core Object Principles in OO Programming

Thinking with Objects

Individuals just starting out with Java and object-oriented (OO) programming often feel overwhelmed by not only having to learn a new language syntax but also having to comprehend the unfamiliar concepts of OO programming. For those individuals, building a strong foundation on the key OO concepts is a great place to start. For seasoned developers, a refresher on these topics is always beneficial.

Objects
The most basic concept in an OO language is that of an object. In OO languages, objects represent real everyday items such as an automobile, radio, or dog. Objects can contain both attributes and behaviors. For instance, an automobile has the concept of a manufacturer name attribute and the concept of a drive behavior. In Java, attributes are represented as variables while behaviors are represented as methods. Variables can be a variety of different types - simple types such as int or complex types such as another object. Listing 1 shows an Automobile class.

For a real Automobile object, we would certainly not limit ourselves to such a small list of attributes and behaviors. In fact, our Automobile object should contain all of the properties and methods that a real-world automobile would actually have. We can therefore define an object as all of the attributes and behaviors that a real-world entity would possess. Objects can be used to represent more abstract concepts or entities as well. For instance, you could create an object to represent an idea.

One common area of confusion is the differences and similarities between classes and objects. In all OO languages, classes become objects when they are instantiated. In Java, object instantiation is performed using the new operator, as in the following line of code.

Automobile auto = new Automobile();

Until a class becomes an object through instantiation, it's only a shell of what the object can be. Think of a class as an object blueprint. Just as a house exists only in blueprint form until it is actually constructed, classes do not become objects until they are constructed via instantiation. Once an object is instantiated, it contains its own version of all the instance methods and instance variables of the class. I'll be using the terms class and object interchangeably.

Objects communicate by calling each other's methods. This concept is called messaging. To send a message is simply to invoke a method of a called object by a calling object. Depending on the method signature, messages can include one or more parameters that can affect the operation of the method. Parameters can be simple types like an int or complex types like another object. As an example, perhaps our Automobile object contains an accelerate() method that accepts an int value representing the speed to which the Automobile object should accelerate. A Driver object, representing the operator of the automobile, can pass a message to the Automobile object's accelerate() method causing the vehicle to increase its speed. A message can optionally return a value. As with the parameters sent to a message, a message's return value type can be simple or complex.

The following example illustrates the concept:

public class Driver {
public static void main(String args[])
{
Driver driver = new Driver();
driver.drive();
}

private void drive() {
{
Automobile auto = new Automobile();
auto.accelerate(25);
}
}

I'll be using the terms message and method interchangeably.

Coherence
Coherence is the concept of modeling objects in such a way that they reflect, as accurately as possible, the actual properties and behaviors of real-world entities.

This goal, though desirable, is not always easy to achieve. Even experienced object modelers struggle with the balance between making an object do too much or too little and assigning responsibility to the correct object. Sometimes, however, a class ends up with functionality that is not central to the core concept of the class. Let's return to our Automobile class for another example. Let's pretend that a request was made for the capability to calculate the price of fuel in different international currencies. Would it make sense to add this method to the Automobile class? Certainly it wouldn't break the Automobile class by doing so. However, the object would now be somewhat fragmented in terms of its functionality. You could say that the Automobile class would be less coherent.

There's no doubt that performing this calculation is related to the processes surrounding using an automobile. But doing so is not central to what an Automobile object does. Generally, if a property or behavior is not essential to the concept that the object is attempting to model, it does not belong in the object and will reduce the object's level of coherence. Reducing the level of coherence in an object also reduces the intuitive understanding of what a real-world entity does and how it behaves. A better alternative is to place the fuel price conversion method in a different class - perhaps a Trip or TripUtilities class.

Inheritance
Inheritance provides the capabilities for one object to automatically contain attributes and behaviors of another object. Let's quickly return to our Automobile object and show an example of inheritance, how it works, and why it's so important. Perhaps in addition to our Automobile object, we wanted to create a new object DriversEducationAutomobile. DriversEducationAutomobile is exactly like Automobile in every way except that it has an extra brake pedal on the front passenger side for the instructor to depress.

One option in creating DriversEducationAutomobile is to copy all of the attributes and methods of Automobile, add the new attributes and methods that are specific to DriversEducationAutomobile, and create a new source and class file. That will certainly work but would create a bit of a maintenance problem. Now if we wanted to make a change to any of the common variables or methods shared between Automobile and DriversEducationAutomobile, we would need to make changes in both classes. A better way is to have DriversEducationAutomobile inherit from Automobile. By doing so, DriversEducationAutomobile will now automatically contain all of the variables and methods in Automobile. The only remaining task is to add those variables and methods specific to DriversEducationAutomobile.

Another benefit of using inheritance in this manner is that any changes made to Automobile will automatically be reflected in DriversEducationAutomobile. When an object inherits from another object in this way, the parent class is said to be the superclass and the child class is said to be the subclass.

Listing 2 provides an example. In this case, the brakeUsingInstructorsPedal() method of the DriversEducationAutomobile class performs some specialized behavior, then simply calls the brake() method that it inherits from Automobile. Note that in Java, inheritance is indicated by the use of the extends keyword.

Subclasses can have other more interesting behaviors as well. A subclass can override the inherited behaviors of a superclass method, providing a specialized behavior that will automatically occur when the method of the subclass is called.

By using inheritance, developers can implement a hierarchical tree structure of classes by which specialized behaviors can be implemented at many different levels.

Encapsulation
Encapsulation revolves around the principle of exposing only as much information about an object as is absolutely necessary. In fact, there are actually two forms of encapsulation - "implementation hiding" and "information hiding."

Let's return to the automobile example to explain why encapsulation in its first form, implementation hiding, is so important. Suppose our automobile was manufactured with anti-lock brakes (ABS) and, in addition to the drive() method, our Automobile object also had brake() and triggerABS() methods. As many people know, the normal braking system of cars with ABS will determine when to cause the ABS system to engage. We would assume that somewhere in the logic of the brake() method would be a call to the triggerABS() method. However, if we expose the triggerABS() method to the outside world, the effects may not be desirable. Suppose someone bypassed the brake() method and called the triggerABS() method directly. This could cause an accident. It's therefore desirable that only the logic of the brake() method call triggerABS() when it deems it appropriate. To prevent the above accident scenario from occurring, the concept of encapsulation dictates that the triggerABS() method not be exposed to any user of the class but only internally to the Automobile object.

In Listing 3, AutomobileWithABS extends Automobile and inherits Automobile's brake() method. Notice how AutomobileWithABS overrides the brake() method and adds its own customized version of brake(). If it's determined that it is necessary to engage the ABS system, then the triggerABS() method is called. If it is unnecessary, the brake() method of the Automobile class is called. Notice further that a triggerABS() method has been added that does not exist in Automobile. Note that the signature of this method is private, indicating that it can only be called internally to the AutomobileWithABS class.

The second form of encapsulation, information hiding, is equally important. Consider that our Automobile class could maintain a variable that contains the revolutions per minute (RPMs) at which the engine is running. This variable is set by the engine in reaction to various driving events: the Driver calling the accelerate() or brake() methods, for instance. What would happen if this variable were made available to be modified by the Driver class? At best the results would be unexpected. Since only the engine should set the RPM variable, it makes no sense to allow this variable to be altered by any external class.

In Listing 4, Automobile has an rpms variable declared as private, meaning that the variable cannot be accessed from outside the class. Two methods allow access to this variable, however. The getRPMs() method is declared as public and allows any other class to obtain the RPMs value. The setRPMs() method is declared as private, thus preventing any class other than Automobile from altering this value.

In short, encapsulation ensures that the inner-workings of an object are hidden from the outside world. Further, encapsulation ensures that both the hidden implementation (methods) and the hidden information (variables) of an object can be altered without negatively affecting other objects on which those objects depend.

Interfaces
In the Java programming language, an interface is a contract specifying which properties and behaviors an object will support. Interfaces allow the processing of objects based on a type rather than a class. (It's important to note that not all OO programming languages support the concept of interfaces.) Let's include our automobile again in an example. Suppose that a VehicleFueler class has been created. On an assembly line, two types of products are produced - automobiles and trucks - and each type of object (Automobile and Truck) gets instantiated somewhere in the assembly line process. Just before these products roll off the assembly line, both products receive a certain amount of a similar type of fuel from the VehicleFueler. The VehicleFueler class doesn't care whether the object is an automobile or a truck. Its only requirement is that the vehicles have some means of properly receiving fuel. In other words, the VehicleFueler requires a contract between itself and the two types of products that roll off the assembly line. A perfect solution to this problem is the implementation of an interface. By implementing the following interface:

public interface Fuelable
{
public void refuel(double amount);
}

the Automobile and Truck classes are agreeing to expose an implementation of the refuel() method. Automobile and Truck will look something like Listing 5.

VehicleFueler can now process either of the vehicles based on the type of object that it's processing rather than the object's class, as in the following:

Fuelable fuelable1 = new Automobile();
Fuelable fuelable2 = new Truck();
...
fuelable1.refuel(0.5);
fuelable2.refuel(0.5);

Another advantage of using interfaces in this way is that VehicleFueler does not need to concern itself with the implementations of either the Automobile or Truck refuel() methods. In fact, the details of what happens in the two objects' versions may be completely different and probably unknown to VehicleFueler. All VehicleFueler needs to know is that by implementing the Fuelable interface, Automobile and Truck encapsulate the functionality required for those objects to receive fuel.

Polymorphism
Polymorphism is the concept of an object changing its form to conform to a generic object abstraction. Varying definitions and implementations of polymorphism exist, most beyond the scope of this article. Yet the most common and easily usable definition is that of parametric polymorphism. Parametric polymorphism uses the concept of a common interface or lowest common denominator in terms of inheritance to implement a single abstraction across a number of types. To reuse the example, instances of Automobile or Truck can be inserted into a Collection object even though Automobile and Truck may be objects of a different class.

Automobile auto = new Automobile();
Truck truck = new Truck();

java.util.List list = new java.util.ArrayList();
list.add(auto);
list.add(truck);

The add() method of java.util.List (as well as many of the "add" methods of Collections classes) takes an instance of java.lang.Object as a parameter. Since Automobile and Truck are ultimate subclasses (see Inheritance discussion, above) of java.lang.Object, the code works. The root of the word polymorphism is morph, which means to change form. The example does essentially that as the added objects, regardless of class or type, are inserted into the Collection object due to their compliance with the inheritance requirements.

Conclusion
This article explained some of the core object principles in OO programming. Mastering these concepts will not only make you a better, more productive programmer, but will also make your code easier to write, easier to maintain, and more easily understood by others.

If you are just starting out, it may take time to integrate all of these concepts into your OO programming repertoire. But with patience and practice, you'll see yourself develop skills that will start to come to you automatically as you begin to think with "objects."

More Stories By York Davis

York Davis is a senior managing consultant at Software Architects, Inc. With more than 12 years in the software development field, York has been using Java for more than five years and has extensive experience building enterprise application architectures.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
M.N.Ramaswamy. 10/26/04 02:08:47 AM EDT

Hi,

Objects share methods, they do not have their own instance methods. Objects have their own instance variables as long as the variables are not declared static.

Cheers,
M.N.Ramaswamy