Lesson 8: Object-Oriented Programming

You have probably heard a lot of talk about object-oriented programming. And, if the Java programming language is your first experience with an object-oriented language, you are probably wondering what all the talk is about.

You already know a little about object-oriented programming because after working the example programs in Java Programming Language Basics, Part 1 and Part 2, you are somewhat familiar with the object-oriented concepts of class, object, instance, and inheritance plus the access levels public and private. But mostly, you have been doing object-oriented programming without really thinking about it.

And that is one of the great things about the Java programming language. It is inherently object oriented.

To help you gain a deeper understanding of object-oriented programming and its benefits, this lesson presents a very brief overview of object-oriented concepts and terminology as they relate to some of the example code presented in this tutorial.

• Object-Oriented Programming Defined
• Classes
• Objects
• Well-Defined Boundaries and Cooperation
• Inheritance
• Polymorphism
• Data Access Levels
• Your Own Classes
• Program Improvements
• More Information

Object-Oriented Programming Defined

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

Classes

A class is a structure that defines the data and the methods to work on that data. When you write programs in the Java language, all program data is wrapped in a class, whether it is a class you write or a class you use from the Java platform API libraries.

The ExampleProgram class from the simple program in the first lesson of Part 1 is a programmer-written class that uses the java.lang.System class from the Java platform API libraries to print a character string to the command line.

class ExampleProgram {

  public static void main(String[] args){

    System.out.println("I'm a simple Program");

  }

}

Classes in the Java platform API libraries define a set of objects that share a common structure and behavior. The java.lang.System class used in the example defines such things as standard input, output, and error streams, and access to system properties. In contrast, the java.lang.String class defines character strings.

In the example, you do not see an explicit use of the String class, but in the Java language, a character string can be used anywhere a method expects to receive a String object. During execution, the Java platform creates a String object from the character string passed to the System.out.println call, but your program cannot call any of the String class methods because it did not instantiate the String object.

If you want access to the String methods, you can rewrite the example program to create a String object as follows. This way, you can call a method such as the String.concat method that adds text to the original string.

class ExampleProgram {

  public static void main(String[] args){

    String text = new String("I'm a simple Program ");

    System.out.println(text);

    String text2 = text.concat(

      "that uses classes and objects");

    System.out.println(text2);

  }

}

The output looks like this:

I'm a simple Program

I'm a simple Program that uses classes and objects

Objects

An instance is an executable copy of a class. Another name for instance is object. There can be any number of objects of a given class in memory at any one time.

In the last example, four different String objects are created for the concatenation operation, text object, text2 object, and a String object created behind the scenes from the " that uses classes and objects" character string passed to the String.concat method.

Also, because String objects cannot be edited, the java.lang.String.concat method converts the String objects to StringBuffer (editable) string objects to do the concatenation.

Besides the String object, there is an instance of the ExampleProgram.java class in memory as well.

The System class is never instantiated by the ExampleProgram class because it contains only static variables and methods, and therefore, cannot be instantiated by a program, but it is instantiated behind the scenes by the Java virtual machine¹ (VM).

Well-Defined Boundaries and Cooperation

Class definitions must allow objects to cooperate during execution. In the previous section, you saw how the System, String, and StringBuffer objects cooperated to print a concatenated character string to the command line.

This section changes the example program to display the concatenated character string in a JLabel component in a user interface to further illustrate the concepts of well-defined class boundaries and object cooperation.

The program code to place the text in a label to display it in a user interface uses a number of cooperating classes. Each class has its own function and purpose as summarized below, and where appropriate, the classes are defined to work with objects of another class.

• ExampleProgram defines the program data and methods to work on that data.
• JFrame defines the top-level window including the window title and frame menu.
• WindowEvent defines behavior for (works with) the Close option on the frame menu.
• String defines a character string to create the label.
• JLabel defines a user interface component to display static text.
• JPanel defines the background color, contains the label, and uses the default layout manager (java.awt.FlowLayout) to position the label on the display.

While each class has its own specific purpose, they all work together to create the simple user interface you see here.

import javax.swing.*;

import java.awt.Color;

import java.awt.event.*;

class ExampleProgram extends JFrame {

  public ExampleProgram(){

    String text = new String("I'm a simple Program ");

    String text2 = text.concat(

      "that uses classes and objects");

    JLabel label = new JLabel(text2);

    JPanel panel = new JPanel();

    panel.setBackground(Color.white);

    getContentPane().add(panel);

    panel.add(label);

  }

  public static void main(String[] args){

    ExampleProgram frame = new ExampleProgram();

    frame.setTitle("Fruit $1.25 Each");

    WindowListener l = new WindowAdapter() {

      public void windowClosing(WindowEvent e) {

        System.exit(0);

      }

    };

    frame.addWindowListener(l);

    frame.pack();

    frame.setVisible(true);

  }

}

Inheritance

One object-oriented concept that helps objects work together is inheritance. Inheritance defines relationships among classes in an object-oriented language. In the Java programming language, all classes descend from java.lang.Object and implement its methods.

The following diagram shows the class hierarchy as it descends from java.lang.Object for the classes in the user interface example above. The java.lang.Object methods are also shown because they are inherited and implemented by all of its subclasses, which is every class in the Java API libraries. java.lang.Object defines the core set of behaviors that all classes have in common.

As you move down the hierarchy, each class adds its own set of class-specific fields and methods to what it inherits from its superclass or superclasses. The java.awt.swing.JFrame class inherits fields and methods from java.awt.Frame, which inherits fields and methods from java.awt.Container, which inherits fields and methods from java.awt.Component, which finally inherits from java.lang.Object, and each subclass adds its own fields and methods as needed.

Polymorphism

Another way objects work together is to define methods that take other objects as parameters. You get even more cooperation and efficiency when the objects are united by a common superclass. All classes in the Java programming language have an inheritance relationship.

For example, if you define a method that takes a java.lang.Object as a parameter, it can accept any object in the entire Java platform. If you define a method that takes a java.awt.Component as a parameter, it can accept any component object. This form of cooperation is called polymorphism.

You saw an example of polymorphism in Part 2, Lesson 5: Collections where a collection object can contain any type of object as long as it descends from java.lang.Object. It is repeated here to show you that Set collection can add a String object and an Integer object to the Set because the Set.add method is defined to accept any class instance that traces back to the java.lang.Object class.

  String custID = "munchkin";

  Integer creditCard =  new Integer(25);

  Set s = new HashSet();

  s.add(custID);

  s.add(creditCard);

Data Access Levels

Another way classes work together is through access level controls. Classes, and their fields and methods have access levels to specify how they can be used by other objects during execution, While cooperation among objects is desirable, there are times when you will want to explicitly control access, and specifying access levels is the way to gain that control. When you do not specify an access level, the default access level is in effect.

Classes

By default, a class can be used only by instances of other classes in the same package. A class can be declared public to make it accessible to all class instances regardless of what package its class is in. You might recall that in Part 1, Part 1, Lesson 3: Building Applets, the applet class had to be declared public so it could be accessed by the appletviewer tool because the appletviewer program is created from classes in another package.

Here is an applet class declared to have a public access level:

public class DbaAppl extends Applet

                 implements ActionListener {

Without the public access level (shown below), its access level is package by default. You get an error when you try to interpret a class with an access level of package with the appletviewer tool. The same is true if the access level is protected or private.

class DbaAppl extends Applet

                 implements ActionListener {

Also, in Part 2, Lesson 6: Internationalization the server classes are made public so client classes can access them.

Fields and Methods

Fields and methods can be declared private, protected, public, or package. If no access level is specified, the field or method access level is package by default.

private: A private field or method is accessible only to the class in which it is defined. In Part 1, Lesson 7: Database Access and Permissions the connection, user name, and password for establishing the database access are all private. This is to prevent an outside class from accessing them and jeopardizing the database connection, or compromising the secret user name and password information.

  private Connection c;

protected: A protected field or method is accessible to the class itself, its subclasses, and classes in the same package.

public: A public field or method is accessible to any class of any parentage in any package. In Part 2, Lesson 6: Internationalization server data accessed by client programs is made public.

package: A package field or method is accessible to other classes in the same package.

Your Own Classes

When you use the Java API library classes, they have already been designed with the above concepts in mind. They all descend from java.lang.Object giving them an inheritance relationship; they have well-defined boundaries; and they are designed to cooperate with each other where appropriate.

For example, you will not find a String class that takes an Integer object as input because that goes beyond the well-defined boundary for a String. You will, however, find the Integer class has a method for converting its integer value to a String so its value can be displayed in a user interface component, which only accepts String objects.

But what about when you write your own classes? How can you be sure your classes have well-defined boundaries, cooperate, and make use of inheritance? One way is to look at the functions you need a program to perform and separate them into distinct modules where each functional module is defined by its own class or group of classes.

Well-Defined and Cooperating Classes

Looking at the RMIClient2 class from the Part 2, Lesson 5: Collections lesson, you can see it performs the following functions: Get data, display data, store customer IDs, print customer IDs, and reset the display.

Getting data, displaying the data, and resetting the display are closely related and easily form a functional module. But in a larger program with more data processing, the storing and printing of customer IDs could be expanded to store and print a wider range of data. In such a case, it would make sense to have a separate class for storing data, and another class for printing it in various forms.

You could, for example, have a class that defines how to store customer IDs, and tracks the number of apples, peaches, and pears sold during the year. You could also have another class that defines report printing. It could access the stored data to print reports on apples, peaches, and pears sold by the month, per customer, or throughout a given season.

Making application code modular by separating out functional units makes it easier to update and maintain the source code. When you change a class, as long as you did not change any part of its public interface, you only have to recompile that one class.

Inheritance

Deciding what classes your program needs means separating functions into modules, but making your code more efficient and easier to maintain means looking for common functions where you can use inheritance. If you need to write a class that has functionality similar to a class in the Java API libraries, it makes sense to extend that API library class and use its methods rather than write everything from scratch.

The RMIClient2 class from the Part 2, Lesson 5: Collections lesson extends JFrame to leverage the ready-made functionality it provides for a program's top-level window including, frame menu closing behavior, background color setting, and a customized title.

Likewise, if you want to add customized behavior to an existing class, you can extend that class and add the functionality you want. For example, you might want to create your own JButton class with a different look. To do this, you can write your own class that extends JButton and implement it to appear the way you want. Then your program can instantiate your button class instead of the JButton class whenever you need a button with the new look you created.

Access Levels

You should always keep access levels in mind when you declare classes, fields, and methods. Consider which objects really need access to the data, and use packages and access levels to protect your application data from all other objects executing in the system.

Most object-oriented applications do not allow other objects to access their fields directly by declaring them private. Then they make their methods protected, public, or package as needed and allow other objects to manipulate their private data by calling the methods only. This way, you can update your class by changing a field definition and the corresponding method implementation, but other objects that access that data do not need to be changed because their interface to the data (the method signature) has not changed.

Program Improvements

Program improvements for this lesson include setting the correct access levels and organizing a program into functional units.

Setting Access Levels

It is always best to restrict access as much as possible. Going back to Part 2, Lesson 7: Packages and JAR Files, the server classes had to be made public and the DataOrder class fields also had to be made public so the client programs can access them.

At that time, no access level was specified for the other classes and fields so they are all package by default. All methods have an access level of public.

A good exercise would be to go back to the client classes and give the classes, fields, and methods an access level so they are not accessed inappropriately by other objects.

Here are possible solutions for the RMIClient1.java and RMIClient2.java client programs. Can you explain why the actionPerformed method cannot be made private? If not, make it private, run the javac command to compile, and see what the compiler has to say about it.