What Are Classes?

Classes are the building blocks of an object-oriented system, so it's important to define them and talk about how they relate to objects before you learn to declare and use them. On one hand, objects are relatively easy to define because they surround you. Obviously, this book you're reading and the keyboard on which you type are both objects. The concreteness of objects makes the concept simple to grasp ”objects are specific things (persons, places, ideas, and so on if you want to be complete). Turning to classes, however, you must trade this concrete view for the abstract.

In nearly every aspect of life, from simple conversation to scientific research, people have found it easier to understand objects and work with them after they have been put into categories that make similarities and differences clear. The world is too complex otherwise . Imagine Henry Ford trying to explain his plans for the Model T when there was no such abstraction as a "car" from which to start. When an automaker introduces a new model today, you might be anxious to see what it looks like but no one has to tell you what it does. When abstractions are used to group objects, the key is to focus on what they have in common and ignore the ways in which they differ when those differences are unimportant in a given context.

So how does this relate to classes? A class defines an abstraction using a set of attributes and behavior that represents what is common among objects in a group. From a programming standpoint, these attributes are variables that represent state and you define methods to act on these variables as a way to model behavior. With proper adherence to encapsulation, these methods define everything that is allowed in terms of accessing, using, and changing the state of an object. Any behavior that is important to the system you're building should be found in the classes you design.

Before going any further, consider this simple example: Suppose you have to design a system to coordinate the stoplights in a busy section of town as a way to ease traffic congestion. You look at the problem and right away know that the stoplights found at the affected intersections are the primary objects that need to be represented in your system. There might be tens or even hundreds of individual stoplights, but based on your problem, they're all the same when it comes to state and behavior. With this in mind, you decide you need a class named StopLight. The first step is to define variables to hold the state of a StopLight. As an initial pass, you decide that the color of the light is the only state of a StopLight that the rest of your system needs to know. To represent this state, you select a single integer variable named greenYellowRed that will hold the value of the light color. Java offers a much better way than using an integer here but you'll learn about that a little later. Given these design choices, here's an example class declaration:

 public class StopLight{   /* 0 -> Green      1 -> Yellow      2 -> Red    */   int greenYellowRed; } 

This class declaration is valid but it isn't very interesting and it doesn't do anything to model the behavior of a stoplight. This is where methods are needed. In the case of a StopLight class, it is likely that you would have a method called changeLight(), which would cause the light to change from red to green (probably by changing the greenYellowRed variable). The following modified declaration of StopLight shows how this behavior is incorporated into the class:

 public class StopLight{   int greenYellowRed;    void changeLight(){     greenYellowRed = ++greenYellowRed % 3;   } } 

Note

To distinguish class variables with variables that are parts of methods, class variables are often referred to as fields, or class scope variables. In the previous example, the greenYellowRed variable would be a field of the StopLight class.