Most Read This Week
Core Object Principles in OO Programming
Thinking with Objects
By: York Davis
Jan. 8, 2004 12:00 AM
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.
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:
I'll be using the terms message and method interchangeably.
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.
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.
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.
public interface Fuelable
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();
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.
Automobile auto = new Automobile();
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.
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."
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads