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
1 (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.
Organizing Code into Functional Units
One way to divide code into functional units is to put the user interface code in one class and the code that responds to user interface interactions in another class. Going back to Lesson 6: Internationalization, take the
RMIClient1.java program and move the
actionPerformed method to its own class.
Hints: The
RMIClient1 class will become two classes.
- The class that builds the UI has a
main method; the second class does not.
- The class with the
main method creates an instance of the second class, and passes an instance of itself to the second class.
- The second class accesses user interface components in the first class by referencing the class instance.
- You will need to work out how the second class will get access to the message bundle with the translated text in it.
- You will have to change some access levels so the classes can access each other's members.
Here is a possible solution:
- RMIClientView
- RMIClientControlle
