JAVA'S Object-oriented programming concepts

Object-oriented programming concepts

The Java language is (mostly) object oriented. If you haven't used an object-oriented language before, OOP concepts might seem strange at first. This section is a short introduction to OOP language concepts, using structured programming as a point of contrast.

What is an object?

Structured programming languages like C and COBOL follow a different programming paradigm from object-oriented ones. The structured-programming paradigm is highly data oriented: You have data structures, and then program instructions act on that data. Object-oriented languages such as the Java language combine data and program instructions into objects.

An object is a self-contained entity that contains attributes and behavior, and nothing more. Instead of having a data structure with fields (attributes) and passing that structure around to all of the program logic that acts on it (behavior), in an object-oriented language, data and program logic are combined. This combination can occur at vastly different levels of granularity, from fine-grained objects such as a Number, to coarse-grained objects, such as a FundsTransfer service in a large banking application.

Parent and child objects

A parent object is one that serves as the structural basis for deriving more-complex child objects. A child object looks like its parent but is more specialized. With the object-oriented paradigm, you can reuse the common attributes and behavior of the parent object, adding to its child objects attributes and behavior that differ. (You learn more about inheritance in the next section of this tutorial.)

Object communication and coordination

Objects talk to other objects by sending messages (method calls in Java parlance). Furthermore, in an object-oriented application, program code coordinates the activities among objects to perform tasks within the context of the given application domain.

Object summary

A well-written object:

Has crisp boundaries
Performs a finite set of activities
Knows only about its data and any other objects that it needs to accomplish its activities

In essence, an object is a discrete entity that has only the necessary dependencies on other objects to perform its tasks.

Now, you see what an object looks like.

The `Person` object

I start with an example that is based on a common application-development scenario: an individual being represented by a Person object.

Going back to the definition of an object, you know that an object has two primary elements: attributes and behavior. I show how these apply to thePerson object.

Attributes

What attributes can a person have? Some common ones include:

Name
Age
Height
Weight
Eye color
Gender

You can probably think of more (and you can always add more attributes later), but this list is a good start.

Behavior

An actual person can do all sorts of things, but object behaviors usually relate to some kind of application context. In a business-application context, for instance, you might want to ask your Person object, "What is your age?" In response, Person would tell you the value of its Age attribute.

More-complex logic can be hidden inside of the Person object — for example, calculating a person's Body Mass Index (BMI) for a health application — but for now, suppose that Person has the behavior of answering these questions:

What is your name?
What is your age?
What is your height?
What is your weight?
What is your eye color?
What is your gender?

State and string

State is an important concept in OOP. An object's state is represented at any moment in time by the value of its attributes.

In the case of Person, its state is defined by attributes such as name, age, height, and weight. If you wanted to present a list of several of those attributes, you might do so using a String class, which I talk more about later in the tutorial.

Using the concepts of state and string together, you can say to Person, "Tell me who you are by giving me a listing (or String) of your attributes."

Principles of OOP

If you come from a structured-programming background, the OOP value proposition might not be clear yet. After all, the attributes of a person and any logic to retrieve (and convert) those values can be written in C or COBOL. This section clarifies the benefits of the OOP paradigm by explaining its defining principles: encapsulation, inheritance, and polymorphism.

Encapsulation

Recall that an object is above all discrete, or self-contained. This characteristic is the principle of encapsulation at work. Hiding is another term that is sometimes used to express the self-contained, protected nature of objects.

Regardless of terminology, what's important is that the object maintains a boundary between its state and behavior and the outside world. Like objects in the real world, objects used in computer programming have various types of relationships with different categories of objects in the applications that use them.

On the Java platform, you can use access modifiers (which I introduce later in the tutorial) to vary the nature of object relationships from public toprivate. Public access is wide open, whereas private access means the object's attributes are accessible only within the object itself.

The public/private boundary enforces the object-oriented principle of encapsulation. On the Java platform, you can vary the strength of that boundary on an object-by-object basis, depending on a system of trust. Encapsulation is a powerful feature of the Java language.

Inheritance

In structured programming, it's common to copy a structure, give it a new name, and add or modify the attributes that make the new entity (such as an Account record) different from its original source. Over time, this approach generates a great deal of duplicated code, which can create maintenance issues.

OOP introduces the concept of inheritance, whereby specialized classes — without additional code — can "copy" the attributes and behavior of the source classes that they specialize. If some of those attributes or behaviors need to change, you override them. The only source code you change is the code needed for creating specialized classes. As you know from the "Object-oriented programming concepts" section, the source object is called the parent, and the new specialization is called the child.

Inheritance at work

Suppose you are writing a human-resources application and want to use the Person class as the basis (called the super class) for a new class called Employee. Being the child of Person, Employee would have all of the attributes of a Person class, along with additional ones, such as:

Taxpayer identification number
Employee number
Salary

Inheritance makes it easy to create the new Employee class without needing to copy all of the Person code manually.

You'll see plenty of examples of inheritance in Java programming later in the tutorial, especially in Part 2.

Polymorphism

Polymorphism is a harder concept to grasp than encapsulation and inheritance. In essence, it means that objects that belong to the same branch of a hierarchy, when sent the same message (that is, when told to do the same thing), can manifest that behavior differently.

To understand how polymorphism applies to a business-application context, return to the Person example. Remember telling Person to format its attributes into a String? Polymorphism makes it possible for Person to represent its attributes in a variety of ways depending on the type ofPerson it is.

Polymorphism is one of the more complex concepts you'll encounter in OOP on the Java platform and is beyond the scope of an introductory tutorial.

Getting started with the Java language

The Java language: Not purely object-oriented

With the Java language, you can create first-class objects, but not everything in the language is an object. Two qualities differentiate the Java language from purely object-oriented languages such as Smalltalk. First, the Java language is a mixture of objects and primitive types. Second, with Java, you can write code that exposes the inner workings of one object to any other object that uses it.

The Java language does give you the tools necessary to follow sound OOP principles and produce sound object-oriented code. Because Java is not purely object-oriented, you must exercise some discipline in how you write code — the language doesn't force you to do the right thing, so you must do it yourself. (This tutorial's last section, "Writing good Java code," provides tips.)

It would be impossible to introduce the entire Java language syntax in a single tutorial. The remainder of Part 1 focuses on the basics of the language, leaving you with enough knowledge and practice to write simple programs. OOP is all about objects, so this section starts with two topics specifically related to how the Java language handles them: reserved words and the structure of a Java object.

Reserved words

Like any programming language, the Java language designates certain words that the compiler recognizes as special. For that reason, you're not allowed to use them for naming your Java constructs. The list of reserved words is surprisingly short:

abstract
assert
boolean
break
byte
case
catch
char
class
const
continue
default
do
double
else
enum
extends
final
finally
float
for
goto
if
implements
import
instanceof
int
interface
long
native
new
package
private
protected
public
return
short
static
strictfp
super
switch
synchronized
this
throw
throws
transient
try
void
volatile
while

Note that true, false, and null are technically not reserved words. Although they are literals, I included them in this list because you can't use them to name Java constructs.

One advantage of programming with an IDE is that it can use syntax coloring for reserved words, as I show later in this tutorial.

Structure of a Java class

A class is a blueprint for a discrete entity (object) that contains attributes and behavior. The class defines the object's basic structure, and at runtime, your application creates an instance of the object. An object has a crisp boundary and a state, and it can do things when correctly asked. Every object-oriented language has rules about how to define a class.

In the Java language, classes are defined as shown in Listing 1:

Listing 1. Class definition

package packageName;
import ClassNameToImport; accessSpecifier class ClassName {
  accessSpecifier dataType variableName [= initialValue];
  accessSpecifier ClassName([argumentList]) {
    constructorStatement(s)
  }
  accessSpecifier returnType methodName ([argumentList]) {
    methodStatement(s)
  }
  // This is a comment
  /* This is a comment too */
  /* This is a
   multiline
     comment */
}

Listing 1 contains various types of constructs, which I've differentiated with font formatting. The constructs shown in bold (which you'll find in the list of reserved words) are literals; in any object definition, they must be exactly what they are in the listing. The names that I've given the other constructs describe the concepts they represent. I explain all of the constructs in detail in the rest of this section.

Note: In Listing 1 and some other code examples in this section, square brackets indicate that the constructs within them are not required. The brackets themselves (unlike { and }) are not part of the Java syntax.

Comments in code

Notice that Listing 1 also includes some comment lines:

// This is a comment
/* This is a comment too */
/* This is a
multiline
comment */

With just about every programming language, programmers can add comments to help document the code. Java syntax allows for both single-line and multiline comments. A single-line comment must be contained on one line, although you can use adjacent single-line comments to form a block. A multiline comment begins with /*, must be terminated with */, and can span any number of lines.

You learn more about comments when you get to this tutorial's "Writing good Java code" section.

Packaging classes

With the Java language, you can choose the names for your classes, such as Account, Person, or LizardMan. At times, you might end up using the same name to express two slightly different concepts. This situation is called a name collision, and it happens frequently. The Java language uses packages to resolve these conflicts.

A Java package is a mechanism for providing a namespace— an area inside of which names are unique, but outside of which they might not be. To identify a construct uniquely, you must fully qualify it by including its namespace.

Packages also give you a nice way to build more-complex applications with discrete units of functionality.

Package definition

To define a package, you use the package keyword followed by a legal package name, terminated with a semicolon. Often package names are separated by dots and follow this de facto standard scheme:

package orgType.orgName.appName.compName;

This package definition breaks down like so:

orgType is the organization type, such as com, org, or net.
orgName is the name of the organization's domain, such as makotojava, oracle, or ibm.
appName is the name of the application, abbreviated.
compName is the name of the component.

The Java language doesn't force you to follow this package convention. In fact, you don't need to specify a package at all, in which case all of your classes must have unique names and will reside in the default package. As a best practice, I recommend that you define all of your Java classes in packages named as I've described here. You follow that convention throughout this tutorial.

Import statements

Up next in the class definition (referring back to Listing 1) is the import statement. An import statement tells the Java compiler where to find classes that you reference inside of your code. Any nontrivial class uses other classes for some functionality, and the import statement is how you tell the Java compiler about them.

An import statement usually looks like this:

import ClassNameToImport;

You specify the import keyword, followed by the class that you want to import, followed by a semicolon. The class name should be fully qualified, meaning that it should include its package.

To import all classes within a package, you can put .* after the package name. For example, this statement imports every class in thecom.makotojava package:

import com.makotojava.*;

Importing an entire package can make your code less readable, however, so I recommend that you import only the classes that you need, using their fully qualified names.

Class declaration

To define an object in the Java language, you must declare a class. Again, think of a class as a template for an object, like a cookie cutter.

Listing 1 includes this class declaration:

accessSpecifier class ClassName {
  accessSpecifier dataType variableName [= initialValue];
    accessSpecifier ClassName([argumentList]) {
    constructorStatement(s)
  }
  accessSpecifier returnType methodName([argumentList]) {
    methodStatement(s)
  }
}

A class's accessSpecifier can have several values, but usually it is public. You look at other values of accessSpecifier soon.

Class-naming conventions

You can name classes pretty much however you want, but the convention is to use camel case: Start with an uppercase letter, capitalize the first letter of each concatenated word, and make all the other letters lowercase. Class names should contain only letters and numbers. Sticking to these guidelines ensures that your code is more accessible to other developers who are following the same conventions.

Classes can have two types of members: variables and methods.

Variables

The values of a given class's variables distinguish each instance of that class and define its state. These values are often referred to as instance variables. A variable has:

An accessSpecifier
A dataType
A variableName
Optionally, an initialValue

The possible accessSpecifier values are:

public: Any object in any package can see the variable. (Don't ever use this value; see thePublic variables sidebar.)
protected: Any object defined in the same package, or a subclass (defined in any package), can see the variable.
No specifier (also called friendly or package private access): Only objects whose classes are defined in the same package can see the variable.
private: Only the class containing the variable can see it.

A variable's dataType depends on what the variable is — it might be a primitive type or another class type (again, more about this later).

The variableName is up to you, but by convention, variable names use the camel case convention I described in "Class-naming conventions," except that they begin with a lowercase letter. (This style is sometimes called lower camel case.)

Don't worry about the initialValue for now; just know that you can initialize an instance variable when you declare it. (Otherwise, the compiler generates a default for you that is set when the class is instantiated.)

Example: Class definition for `Person`

Before moving on to methods, here's an example that summarizes what you've learned so far. Listing 2 is a class definition for Person.

Listing 2. Basic class definition for `Person`

package com.makotojava.intro;

public class Person {
   private String name;
   private int age;
   private int height;
   private int weight;
   private String eyeColor;
   private String gender;
}

The basic class definition for Person isn't useful at this point, because it defines only its attributes (and private ones at that).

To be more interesting, the Person class needs behavior — and that means methods.

Methods

A class's methods define its behavior.

Methods fall into two main categories: constructors or all other methods, of which there are many types. A constructor method is used only to create an instance of a class. Other types of methods can be used for virtually any application behavior.

The class definition back in Listing 1 shows the way to define the structure of a method, which includes elements like:

accessSpecifier
returnType
methodName
argumentList

The combination of these structural elements in a method's definition is called the method's signature.

Next, you look in more detail at the two types of methods, starting with constructors.

Constructor methods

You use constructors to specify how to instantiate a class. Listing 1 shows the constructor-declaration syntax in abstract form; here it is again:

accessSpecifier ClassName([argumentList]) {
  constructorStatement(s)
}

A constructor's accessSpecifier is the same as for variables. The name of the constructor must match the name of the class. So if you call your class Person, the name of the constructor must also be Person.

For any constructor other than the default constructor, you pass an argumentList, which is one or more of:

argumentType argumentName

Arguments in an argumentList are separated by commas, and no two arguments can have the same name. argumentType is either a primitive type or another class type (the same as with variable types).

Class definition with a constructor

Now, you see what happens when you add the capability to create a Person object in two ways: by using a no-arg constructor and by initializing a partial list of attributes.

Listing 3 shows how to create constructors and also how to use argumentList:

Listing 3. `Person` class definition with a constructor

package com.makotojava.intro;
public class Person {
  private String name;
  private int age;
  private int height;
  private int  weight;
  private String eyeColor;

  private String gender;
  public Person() {
    // Nothing to do...
  }

  public Person(String name, int age, int height, int weight String eyeColor, String gender) {
    this.name = name;
    this.age = age;
    this.height = height;
    this.weight = weight;
    this.eyeColor = eyeColor;
    this.gender = gender;
  }
}

Note the use of the this keyword in making the variable assignments in Listing 3. The this keyword is Java shorthand for "this object," and you must use it when you reference two variables with the same name. In this case, age is both a constructor parameter and a class variable, so thethis keyword helps the compiler to disambiguate the reference.

The Person object is getting more interesting, but it needs more behavior. And for that, you need more methods.

Other methods

A constructor is a particular kind of method with a particular function. Similarly, many other types of methods perform particular functions in Java programs. Exploration of other method types begins in this section and continues throughout the tutorial.

Back in Listing 1, I showed you how to declare a method:

accessSpecifier returnType methodName ([argumentList]) {
  methodStatement(s)
}

Other methods look much like constructors, with a couple of exceptions. First, you can name other methods whatever you like (though, of course, certain rules apply). I recommend the following conventions:

Start with a lowercase letter.
Avoid numbers unless they are absolutely necessary.
Use only alphabetic characters.

Second, unlike constructors, other methods have an optional return type.

`Person`'s other methods

Armed with this basic information, you can see in Listing 4 what happens when you add a few more methods to the Person object. (I've omitted constructors for brevity.)

Listing 4. `Person` with a few new methods

package com.makotojava.intro;

public class Person {
   private String name;
   private int age;
   private int height;
   private int  weight;
   private String eyeColor;
   private String gender;

   public String getName() { return name; }
   public void setName(String value) { name = value; }
   // Other getter/setter combinations...
}

Notice the comment in Listing 4 about "getter/setter combinations." You'll work more with getters and setters later in the tutorial. For now, all you need to know is that a getter is a method for retrieving the value of an attribute, and a setter is a method for modifying that value. Listing 4 shows only one getter/setter combination (for the Name attribute), but you can define more in a similar fashion.

Note in Listing 4 that if a method doesn't return a value, you must tell the compiler by specifying the void return type in its signature.

Static and instance methods

Generally, two types of (nonconstructor) methods are used: instance methods and static methods. Instance methods are dependent on the state of a specific object instance for their behavior. Static methods are also sometimes called class methods, because their behavior is not dependent on any single object's state. A static method's behavior happens at the class level.

Static methods are used largely for utility; you can think of them as being global methods (à la C) while keeping the code for the method with the class that defines it.

For example, throughout this tutorial, you use the JDK Logger class to output information to the console. To create a Logger class instance, you don't instantiate a Logger class; instead, you invoke a static method called getLogger().

The syntax for invoking a static method on a class is different from the syntax used to invoke a method on an object. You also use the name of the class that contains the static method, as shown in this invocation:

Logger l = Logger.getLogger("NewLogger");

In this example, Logger is the name of the class, and getLogger(...) is the name of the method. So to invoke a static method, you don't need an object instance, just the name of the class.

Your first Java class

It's time to pull together what you've learned in the previous sections and start writing some code. This section walks you through declaring a class and adding variables and methods to it using the Eclipse Package Explorer. You learn how to use the Logger class to keep an eye on your application's behavior, and also how to use a main() method as a test harness.

Creating a package

If you're not already there, get to the Package Explorer view (in the Java perspective) in Eclipse through Window > Perspective > Open Perspective. You're going to get set up to create your first Java class. The first step is to create a place for the class to live. Packages are namespace constructs, and they also conveniently map directly to the file system's directory structure.