Anatomy of a Class

In Topic 3.1 you designed classes on paper: a list of attributes and a list of behaviors. Until now, every class you used, such as String and Scanner, was written by someone else, and you only saw its documentation. To turn your own design into something Java can build objects from, you need to know what a class looks like on the inside: which pieces it has, where each one goes, and how Java tells them apart.

Think of a class file as a form with labeled sections. The top line says what the form is for. Below it come the sections, in a usual order: first the data every object keeps, then the code that builds a new object, then the actions an object can perform.

public class GameNight
{
    public static void main(String[] args)
    {
        Scoreboard gym = new Scoreboard();
        gym.printScores();
    }
}

class Scoreboard
{
    private String homeTeam;
    private int homeScore;
    private int awayScore;

    public Scoreboard()
    {
        homeTeam = "Hawks";
        homeScore = 0;
        awayScore = 0;
    }

    public void printScores()
    {
        System.out.println(homeTeam + " " + homeScore + ", Visitors " + awayScore);
    }
}

Hawks 0, Visitors 0

The words private and public in front of the variables, the constructor, and the method control which code is allowed to use each piece. They are the main subject of this chapter, starting in 3.3.3; for now, read past them. You read constructors in Topic 1.13, and Topic 3.4 teaches you to write them fully; here every constructor simply gives each instance variable a starting value. In the same way, Topic 3.5 teaches you to write methods fully. The methods in this chapter are short void methods with no parameters, so you can focus on how a class is organized.

A class is declared with the keyword class, followed by the class name, followed by a body in braces. In this course, every class is also marked public, so on the AP exam the header of this class would read public class Scoreboard. The usual order inside the body is instance variables first, then constructors, then methods. Java does not require that order, but nearly all Java code follows it, so a reader always knows where to look.

Why this program’s Scoreboard is not marked public

Look again at line 10: it says class Scoreboard, not public class Scoreboard. That is because of a Java rule about files: one file can hold at most one public class, and that class must have the same name as the file. GameNight.java already holds the public class GameNight, so Scoreboard cannot be public in the same file.

Every runnable example in this chapter puts two classes in one file this way so that you can see the whole program at once. Real projects, and AP exam questions, put each class in its own file, named after the class, and mark every class public:

// Scoreboard.java
public class Scoreboard
{
    // instance variables, constructors, and methods go here
}

// GameNight.java
public class GameNight
{
    public static void main(String[] args)
    {
        Scoreboard gym = new Scoreboard();
        gym.printScores();
    }
}

When those two files sit in the same project folder, GameNight can use Scoreboard exactly as before.

public class Thermostat
{
    private double currentTemp;
    private double targetTemp;
    private boolean heaterOn;

    public Thermostat()
    {
        currentTemp = 18.5;
        targetTemp = 21.0;
        heaterOn = false;
    }

    public void printReading()
    {
        System.out.println(currentTemp);
    }

    public void raiseTarget()
    {
        targetTemp = targetTemp + 0.5;
    }
}

public class TwoPublicClasses
{
    public static void main(String[] args)
    {
        Scoreboard gym = new Scoreboard();
        gym.printScores();
    }
}

public class Scoreboard
{
    private int homeScore;

    public Scoreboard()
    {
        homeScore = 0;
    }

    public void printScores()
    {
        System.out.println(homeScore);
    }
}

TwoPublicClasses.java:10: error: class Scoreboard is public, should be declared in a file named Scoreboard.java

public class Lamp
{
    private boolean isOn;
    private int brightness;

    public Lamp()
    {
        isOn = false;
        brightness = 50;
    }

    public void switchOn()
    {
        isOn = true;
    }
}

A basketball league tracks many players, and every player has a name and a point total. The class Player describes what every player has. But Ana’s points are not Ben’s points. If Ana scores, Ben’s total must not change. Where does each player’s total live, so that the totals stay separate?

The answer is that instance variables belong to the object, not to the class. The class declares that every player has a points variable. Each time new Player() builds an object, that object gets its own fresh copy of points, and of every other instance variable. A paper form works the same way: the blank form says “Name: __ Points: __”, and every copy of the form you hand out has its own blanks to fill in.

To show this, the Player class in the next examples marks its instance variables public, which lets code outside the class reach them directly. Outside code names an object’s instance variable the same way it calls an object’s method in Topic 1.14: the reference, a dot, then the name. ana.points means “the points variable that belongs to the object ana refers to.” (3.3.4 explains why real classes usually do not make instance variables public.)

public class TwoPlayers
{
    public static void main(String[] args)
    {
        Player ana = new Player();
        Player ben = new Player();
        ana.name = "Ana";
        ana.points = 12;
        ben.name = "Ben";
        ben.points = 7;
        ana.points = ana.points + 3;
        System.out.println(ana.name + " has " + ana.points);
        System.out.println(ben.name + " has " + ben.points);
    }
}

class Player
{
    public String name;
    public int points;

    public Player()
    {
        name = "Nobody";
        points = 0;
    }
}

ana ──► Player object        ben ──► Player object
        name:   "Nobody"             name:   "Nobody"
        points: 0                    points: 0

Ana has 15
Ben has 7

Notice the count: there is only one Player class, written once, yet there are two points variables, because there are two objects. The number of copies of an instance variable equals the number of objects built, not the number of classes.

public class SamePlayer
{
    public static void main(String[] args)
    {
        Player first = new Player();
        Player second = first;
        Player third = new Player();
        second.points = 20;
        third.points = 4;
        System.out.println(first.points);
        System.out.println(second.points);
        System.out.println(third.points);
    }
}

class Player
{
    public String name;
    public int points;

    public Player()
    {
        name = "Nobody";
        points = 0;
    }
}

first  ──┐
         ├──► object #1   points: 0
second ──┘
third  ─────► object #2   points: 0

20
20
4

public class ClassNameField
{
    public static void main(String[] args)
    {
        Player ana = new Player();
        Player.points = 12;
        System.out.println(ana.points);
    }
}

class Player
{
    public String name;
    public int points;

    public Player()
    {
        name = "Nobody";
        points = 0;
    }
}

ClassNameField.java:6: error: non-static variable points cannot be referenced from a static context

public class PlayerTrace
{
    public static void main(String[] args)
    {
        Player p = new Player();
        Player q = new Player();
        Player r = q;
        p.points = 5;
        q.points = 9;
        r.points = r.points + p.points;
        p.points = 1;
        System.out.println(p.points);
        System.out.println(q.points);
        System.out.println(r.points);
    }
}

class Player
{
    public String name;
    public int points;

    public Player()
    {
        name = "Nobody";
        points = 0;
    }
}

1
14
14

Player a = new Player();
Player b = new Player();
Player c = new Player();
Player d = b;

In 3.3.2, main could change any player’s points to anything it liked. That is convenient for a demonstration, but think about a real score-keeping app with code written by several programmers. Any line, in any class, could set a player’s points to -500. Java gives the author of a class a way to say which pieces outside code may use and which pieces are for the class’s own code only.

That is the job of the words in front of each declaration. They are access modifiers: keywords that decide which code is allowed to use a class, a variable, a constructor, or a method. This course uses two:

• public: any code may use it, inside or outside the class that declares it.
• private: only code inside the class that declares it may use it. Code in any other class cannot, not even by naming the object with a dot.

Here, “inside the class” means between that class’s braces: its constructors and its methods. Code in any other class, including the main method of a different class, is outside.

(A member is anything declared directly in the class body: an instance variable, a constructor, or a method.)

Why check this when the program is compiled, instead of when it runs? Because a mistake caught by the compiler can never reach a user. The author of the class marks the rule once, and Java enforces it on every line of every other class.

public class PrivateOutside
{
    public static void main(String[] args)
    {
        Player ana = new Player();
        ana.name = "Ana";
        ana.points = 12;
    }
}

class Player
{
    public String name;
    private int points;

    public Player()
    {
        name = "Nobody";
        points = 0;
    }

    public void printCard()
    {
        System.out.println(name + ": " + points + " points");
    }
}

PrivateOutside.java:7: error: points has private access in Player

Private does not mean “unusable”. It means “usable only from inside”. Change one thing: instead of touching points from main, let Player’s own method use it.

public class PrivateInside
{
    public static void main(String[] args)
    {
        Player ana = new Player();
        ana.name = "Ana";
        ana.printCard();
    }
}

class Player
{
    public String name;
    private int points;

    public Player()
    {
        name = "Nobody";
        points = 0;
    }

    public void printCard()
    {
        System.out.println(name + ": " + points + " points");
    }
}

Ana: 0 points

public class BadgeAllowed
{
    public static void main(String[] args)
    {
        Badge b = new Badge();
        b.owner = "Kim";
        b.printBadge();
    }
}

class Badge
{
    public String owner;
    private int code;

    public Badge()
    {
        owner = "Visitor";
        code = 1000;
    }

    public void printBadge()
    {
        System.out.println(owner + " #" + code);
    }
}

Now that you know what private does, when should you use it? Here is what can happen without it. This Scoreboard makes its scores public:

public class PublicScore
{
    public static void main(String[] args)
    {
        Scoreboard field = new Scoreboard();
        field.homeScore = -4;
        field.printScores();
    }
}

class Scoreboard
{
    public int homeScore;
    public int awayScore;

    public Scoreboard()
    {
        homeScore = 0;
        awayScore = 0;
    }

    public void printScores()
    {
        System.out.println("Home " + homeScore + ", Away " + awayScore);
    }
}

It compiles and prints:

Home -4, Away 0

A score of -4 is impossible in a real game, but nothing stopped line 6. Any code in any class could do the same, and if this app had a bug, every line in every class would be a suspect.

Make one change: mark the scores private.

public class PrivateScore
{
    public static void main(String[] args)
    {
        Scoreboard field = new Scoreboard();
        field.homeScore = -4;
        field.printScores();
    }
}

class Scoreboard
{
    private int homeScore;
    private int awayScore;

    public Scoreboard()
    {
        homeScore = 0;
        awayScore = 0;
    }

    public void printScores()
    {
        System.out.println("Home " + homeScore + ", Away " + awayScore);
    }
}

Now line 6 does not compile:

PrivateScore.java:6: error: homeScore has private access in Scoreboard

The impossible score never happens, because the only code allowed to change homeScore is the code inside Scoreboard. If a score is ever wrong, you only have to check one class.

This is the idea of encapsulation (also called data encapsulation): the details of how a class does its work are kept hidden inside the class, and other classes use the class only through the parts it makes public. A car is a good comparison. A driver uses a steering wheel, pedals, and a key, the public parts. The engine’s wiring is sealed away, so a driver cannot accidentally connect the wrong wires, and the maker can redesign the engine without teaching anyone to drive again. The comparison stops at one point: a mechanic can still open the hood, but nothing in another Java class can ever reach a private member.

Encapsulation gives two benefits:

1. Protection. Outside code cannot put an object’s data into a nonsense state. Only the class’s own code changes its instance variables, so the class’s author controls every change.
2. Freedom to change. Outside code depends only on the public parts, so the author can change private details later (rename a variable, store a value a different way) without breaking any other class. This is the same benefit you saw for procedural abstraction in Topic 3.1: users of a method need to know what it does, not how.

Because of this, the standard practice, and the rule for AP exam code, is: mark instance variables private, unless the class’s specification says otherwise. A specification is the written description of what a class must contain and do, such as the description at the top of an AP free-response question. If a specification explicitly says an instance variable is public, follow it; otherwise, write private.

public class GoalCounter
{
    public static void main(String[] args)
    {
        Scoreboard field = new Scoreboard();
        field.homeGoal();
        field.awayGoal();
        field.homeGoal();
        field.printScores();
    }
}

class Scoreboard
{
    private int homeScore;
    private int awayScore;

    public Scoreboard()
    {
        homeScore = 0;
        awayScore = 0;
    }

    public void homeGoal()
    {
        homeScore = homeScore + 1;
    }

    public void awayGoal()
    {
        awayScore = awayScore + 1;
    }

    public void printScores()
    {
        System.out.println("Home " + homeScore + ", Away " + awayScore);
    }
}

Home 2, Away 1

public class NoModifier
{
    public static void main(String[] args)
    {
        Scoreboard field = new Scoreboard();
        field.homeScore = -4;
        field.printScores();
    }
}

class Scoreboard
{
    int homeScore;
    int awayScore;

    public Scoreboard()
    {
        homeScore = 0;
        awayScore = 0;
    }

    public void printScores()
    {
        System.out.println("Home " + homeScore + ", Away " + awayScore);
    }
}

public and private apply to more than variables. A class’s constructors and methods also have access modifiers, and the right choice depends on who needs to use each one.

Constructors are always public in this course. The whole point of a constructor is to let other code build objects with new. A private constructor would block exactly that:

public class PrivateConstructor
{
    public static void main(String[] args)
    {
        Scoreboard field = new Scoreboard();
        field.printScores();
    }
}

class Scoreboard
{
    private int homeScore;
    private int awayScore;

    private Scoreboard()
    {
        homeScore = 0;
        awayScore = 0;
    }

    public void homeGoal()
    {
        homeScore = homeScore + 1;
    }

    public void printScores()
    {
        printDivider();
        System.out.println("Home " + homeScore + ", Away " + awayScore);
        printDivider();
    }

    private void printDivider()
    {
        System.out.println("--------------");
    }
}

Line 5 does not compile:

PrivateConstructor.java:5: error: Scoreboard() has private access in Scoreboard

main is outside Scoreboard, so it may not call a private constructor, and without a constructor call it cannot get a Scoreboard object at all.

Methods can be either. In Topic 3.1, behaviors were the actions of a class. Some actions are services for outside code: recording a goal, printing the scores. Those methods are public, because outside code must be able to call them. Other methods exist only to help the class’s own code, such as a small step that several public methods share. Those are private: they are part of how the class works inside, which encapsulation keeps hidden.

public class ScoreReport
{
    public static void main(String[] args)
    {
        Scoreboard field = new Scoreboard();
        field.homeGoal();
        field.printScores();
    }
}

class Scoreboard
{
    private int homeScore;
    private int awayScore;

    public Scoreboard()
    {
        homeScore = 0;
        awayScore = 0;
    }

    public void homeGoal()
    {
        homeScore = homeScore + 1;
    }

    public void printScores()
    {
        printDivider();
        System.out.println("Home " + homeScore + ", Away " + awayScore);
        printDivider();
    }

    private void printDivider()
    {
        System.out.println("--------------");
    }
}

--------------
Home 1, Away 0
--------------

Change who makes the call. Now main tries to call the helper directly:

public class CallPrivateHelper
{
    public static void main(String[] args)
    {
        Scoreboard field = new Scoreboard();
        field.printDivider();
    }
}

class Scoreboard
{
    private int homeScore;
    private int awayScore;

    public Scoreboard()
    {
        homeScore = 0;
        awayScore = 0;
    }

    public void homeGoal()
    {
        homeScore = homeScore + 1;
    }

    public void printScores()
    {
        printDivider();
        System.out.println("Home " + homeScore + ", Away " + awayScore);
        printDivider();
    }

    private void printDivider()
    {
        System.out.println("--------------");
    }
}

CallPrivateHelper.java:6: error: printDivider() has private access in Scoreboard

The method is identical; only the location of the call changed. Line 29 of ScoreReport.java is inside the class, so it may call the private method. Line 6 here is in another class, so it may not.

Why bother hiding a helper? If printDivider were public, other classes might start calling it. Then the author could not rename it, remove it, or change how it prints without breaking their code. Keeping it private means it is free to change, the same freedom private variables give.

Here is a summary of the access rules this course uses:

public class TimerBug
{
    public static void main(String[] args)
    {
        Timer quiz = new Timer();
        quiz.beep();
    }
}

class Timer
{
    private int seconds;

    public Timer()
    {
        seconds = 30;
    }

    public void finish()
    {
        System.out.println(seconds + " seconds are up");
        beep();
    }

    private void beep()
    {
        System.out.println("BEEP");
    }
}

        Timer quiz = new Timer();
        quiz.finish();

30 seconds are up
BEEP

This Locker class uses every idea in the chapter: private instance variables, a public constructor, public methods, and a private helper. Two lockers show that each object keeps its own data.

public class LockerDemo
{
    public static void main(String[] args)
    {
        Locker mine = new Locker();
        Locker yours = new Locker();
        mine.lock();
        yours.lock();
        yours.unlock();
        System.out.print("Mine: ");
        mine.printStatus();
        System.out.print("Yours: ");
        yours.printStatus();
    }
}

class Locker
{
    private boolean locked;
    private int timesUsed;

    public Locker()
    {
        locked = false;
        timesUsed = 0;
    }

    public void lock()
    {
        locked = true;
        countUse();
    }

    public void unlock()
    {
        locked = false;
        countUse();
    }

    public void printStatus()
    {
        if (locked)
        {
            System.out.println("locked, uses: " + timesUsed);
        }
        else
        {
            System.out.println("open, uses: " + timesUsed);
        }
    }

    private void countUse()
    {
        timesUsed++;
    }
}

First, the layout of Locker (lines 17 to 56):

Now trace main. Lines 5 and 6 build two Locker objects, each with its own locked (false) and timesUsed (0).

Each lock or unlock call sets locked and then calls the private helper countUse (line 31 or 37), which adds 1 to that same object’s timesUsed (line 54). mine was used once; yours was used twice and ended open. Lines 10 to 13 print a label and then call printStatus, whose if (Topic 2.3) picks the message:

Mine: locked, uses: 1
Yours: open, uses: 2

Finally, check which lines main is allowed to contain:

Because locked and timesUsed are private, the only way to change them is through lock and unlock, and every use is counted. No outside code can lock a locker without counting it, or set timesUsed back to 0.

• A class has a header (public class Name) and a body that holds its instance variables, then its constructors, then its methods. In this course every class is public. A file can hold only one public class, named like the file, so real projects put each class in its own file.
• Instance variables belong to the object: every object built with new gets its own copy, so changing one object’s variable never changes another object’s. Two variables share data only when they refer to the same object.
• private limits a member to code inside the declaring class; public allows code in any class. The deciding question is which class a line of code is written in, not which file.
• Encapsulation keeps a class’s data hidden inside the class. Instance variables are private unless the specification says otherwise, so only the class’s own code can change them.
• Constructors are always public so other classes can build objects. Methods other classes need are public; helper methods used only inside the class are private.

public class TwoBoards
{
    public static void main(String[] args)
    {
        Scoreboard field = new Scoreboard();
        field.homeGoal();
        field.homeGoal();
        Scoreboard gym = new Scoreboard();
        gym.awayGoal();
        field.printScores();
        gym.printScores();
    }
}

class Scoreboard
{
    private int homeScore;
    private int awayScore;

    public Scoreboard()
    {
        homeScore = 0;
        awayScore = 0;
    }

    public void homeGoal()
    {
        homeScore = homeScore + 1;
    }

    public void awayGoal()
    {
        awayScore = awayScore + 1;
    }

    public void printScores()
    {
        System.out.println("Home " + homeScore + ", Away " + awayScore);
    }
}

Home 2, Away 0
Home 0, Away 1

Timer t = new Timer();   // I
t.seconds = 60;          // II
t.finish();              // III

public class PrivateClassHeader
{
    public static void main(String[] args)
    {
        Score game = new Score();
        game.printScore();
    }
}

private class Score
{
    private int points;

    public Score()
    {
        points = 0;
    }

    public void printScore()
    {
        System.out.println(points);
    }
}

class Score

Check each statement. If the answer is “not yet,” reread the linked subsection.

• I can find the class header, instance variables, constructor, and methods in a class. Reread
• I can explain why a one-file example marks only one class public, and where each class goes in a real project. Reread
• I can trace code with several objects and explain why each has its own instance variables. Reread
• I can decide whether a line of code may use a public or private member. Reread
• I can explain encapsulation and why instance variables are private unless a specification says otherwise. Reread
• I can explain why constructors are public and choose public or private for a method. Reread