Abstraction and Program Design

Imagine your school asks you to write a program that tracks library books. A real book has hundreds of facts about it: its title, author, number of pages, cover color, weight, the font it is printed in, the city where it was printed, and whether someone spilled juice on page 40. If your program tried to store every one of those facts, it would be enormous, slow to write, and confusing to read. Yet most of those facts have nothing to do with lending books.

Good programmers handle this the same way a good mapmaker does. A subway map leaves out streets, parks, and buildings and keeps only the stations and the lines between them, because a rider only needs to know where to get on and off. A hiking map of the same city keeps the trails and hills and leaves out the subway. Neither map is “missing” information; each one keeps exactly what its reader needs.

That habit has a name. Abstraction means making a problem simpler by concentrating on its central idea: you hide the details that do not matter for the question you are answering, and you gather together the details that do. The word “abstract” here means “pulled away from the messy specifics.” What counts as a detail that matters always depends on the question at hand.

Now change one thing: the question. Suppose a shipping company writes a program for mailing books to stores. For that program, weight is essential, because postage depends on it, and the size of the book matters for choosing a box. The due date and “checked out” status are now useless. The same real object, a book, gets a different abstraction because the program is answering different questions. There is no single correct list of details for “a book”; there is only the right list for a particular problem.

You have been using abstraction on data since your first program. When you wrote int score = 92; in Topic 1.2, you thought of score as “the score,” not as a pattern of 1s and 0s stored somewhere in memory. When you called length() on a String in Topic 1.15, you got the number of characters without ever learning how Java stores those characters. You used the data through its name and its meaning, and the storage details stayed out of your way.

That is data abstraction: separating what a piece of data means (its abstract properties) from the specific way it is stored (its concrete representation). Data abstraction manages complexity by giving the data a name you can think and talk about, without mentioning how it is represented. A person reading startTime in a program thinks “the time the event starts,” not “an int holding minutes since midnight.”

Data abstraction works at different sizes:

• A single variable. double temperature names one value.
• A class. A String brings many characters together under one name, so you can think about “the word "hopper"” instead of six separate characters. A class that you design can bring together several related pieces of data, as you will see in 3.1.3.
• A set of data. “This year’s daily temperatures” names a whole collection of values as one thing. You will learn ways to store sets of data in Unit 4; the abstraction, thinking of the whole collection by one name, already makes sense.

int startMinutes = 615;
System.out.println("Starts at " + startMinutes / 60 + ":" + startMinutes % 60);

int startHour = 10;
int startMinute = 15;
System.out.println("Starts at " + startHour + ":" + startMinute);

Starts at 10:15
Starts at 10:15

Now vary the situation. Suppose the schedule program needs to know how long a class lasts. With the first representation, a 10:15 start (615) and an 11:05 end (665) give 665 − 615 = 50 minutes with one subtraction. With the second, you have to subtract hours and minutes separately and handle borrowing when the end minute is smaller than the start minute. Programmers choose a representation based on what the program needs to do with the data. But someone who only needs to know “the start time” does not care which one was chosen, and with good data abstraction, they should not have to.

int start = 615;
int later = start + 1;
System.out.println("Ends at " + later / 60 + ":" + later % 60);

Ends at 10:16

int startMinutes = 615;
int endMinutes = startMinutes + 60;
System.out.println("Ends at " + endMinutes / 60 + ":" + endMinutes % 60);

Ends at 11:15

int priceInCents = 1250;
System.out.println("$" + priceInCents / 100 + "." + priceInCents % 100);

In Topic 1.12 you learned that a class is a blueprint that defines the attributes (what an object knows) and behaviors (what an object can do) of a kind of object. You used classes other people wrote, like String and Scanner. Starting in this unit, you will design and write your own. That raises a new question: when you plan a class, where does its data go, and how do you write the plan down?

Think about the variables you have written so far. Every one of them was declared inside a method, usually main. A variable declared inside a method belongs to that method: it is created when that line runs and is gone when the method finishes. That is fine for a temporary value like a loop counter. But a song in a music app needs to know its title the whole time the song object exists, no matter which behavior is running.

That is what an attribute is in Java. An attribute is a data abstraction defined in a class outside any method or constructor. Because it sits in the class itself rather than inside one method, it describes the object as a whole, and every behavior of the class can use it. (You will learn the Java syntax for writing attributes in Topic 3.3; for now, the focus is planning them.)

A class brings related data together under one name, which is data abstraction at the size of a whole class. Instead of juggling four separate variables called title, artist, lengthInSeconds, and timesPlayed, a program can work with one Song object that has all four.

Drawing a class diagram

Programmers plan classes with a class diagram: a box with three parts. The top part names the class, the middle part lists the attributes with their types, and the bottom part lists the behaviors as method headers. Here is a plan for a Song class in a music app:

+------------------------------------+
|                Song                |
+------------------------------------+
| Attributes                         |
|   String title                     |
|   String artist                    |
|   int lengthInSeconds              |
|   int timesPlayed                  |
+------------------------------------+
| Behaviors                          |
|   void play()                      |
|   String getTitle()                |
|   int getLengthInSeconds()         |
+------------------------------------+

Read the attribute line int lengthInSeconds the same way you read a variable declaration: the type, then the name. Read the behavior lines the same way you read method headers in Topic 1.9: return type, name, and parameters. You may see other diagram styles that put the type after the name, like lengthInSeconds : int; they mean the same thing.

Now vary it: the theater adds, “Each ticket also remembers how many times someone tried to scan it.” That one sentence adds one attribute, int scanAttempts, because it is a new fact the ticket must remember. When the requirements change, the attribute list changes with them.

In Topic 1.12 you saw that two String objects have the same kind of attribute (characters) but their own values: "Ada" and "Grace Hopper" hold different characters. Most attributes work that way. But think about the movie theater again. Every ticket has its own seat, but all the tickets are for showings at the same theater, at the same address. Should each ticket store its own copy of the theater’s name? If the theater were renamed, someone would have to update every ticket ever sold.

Java gives you two kinds of attribute for these two situations:

• An instance variable is an attribute whose value belongs to one instance. Every object of the class has its own copy, and changing one object’s value does not affect any other object. A ticket’s seat is an instance variable.
• A class variable is an attribute that is shared by all instances of the class. There is only one copy, and every object sees the same value. If it changes, every object sees the new value. The theater name is a class variable.

  ticket A            ticket B            ticket C
  seat:  "B12"        seat:  "F3"         seat:  "A1"
  price: 12.5         price: 9.0          price: 15.0
     |                   |                   |
     +-------------------+-------------------+
                         |
          theaterName: "Riverside Cinema"
             (one value, shared by all)

Now vary the class. A bank has accounts. Each account has its own balance (instance variable), but the bank pays the same interestRate on every account (class variable). If the bank raises its rate from 2% to 3%, every account immediately uses 3%, with one change. If the rate were an instance variable, the bank would have to update thousands of accounts one at a time, and missing even one would make that customer’s interest wrong.

In a class diagram, mark a class variable so that readers can tell it apart. This guide labels it in the attribute list:

+---------------------------------------------+
|                MovieTicket                  |
+---------------------------------------------+
| Attributes                                  |
|   String seat                               |
|   double price                              |
|   String theaterName     (class variable)   |
+---------------------------------------------+

(In Java, the keyword that makes an attribute a class variable is taught in Topic 3.7. The design decision comes first.)

So far this chapter has been about data. Classes also have behaviors, and behaviors can get complicated. Picture a single main method that plans a whole party: it counts guests, works out food, rounds up to whole pizzas, figures out cost, and prints a plan. Forty lines in one block is hard to read and hard to fix, because every detail of every step is mixed together.

You already know the tool that helps. In Topic 1.9 you learned procedural abstraction: you can use a method knowing only what it does, not how it does it, the way you use Math.sqrt without knowing how it computes square roots. Procedural abstraction also gives a name to a process. The name sqrt stands for a whole calculation, so a reader thinks “square root” instead of following every step.

You can use that idea in your own programs. Method decomposition means breaking a large behavior into smaller behaviors and writing a separate method for each one. The big behavior then becomes a short list of calls, and each call’s name says what that step does. It works like a recipe that says “make the sauce” and puts the sauce instructions on a separate card.

public class PizzaPartyOneBlock
{
    public static void main(String[] args)
    {
        int guests = 13;
        int slices = guests * 3;
        int pizzas = slices / 8;
        if (slices % 8 != 0)
        {
            pizzas++;
        }
        System.out.println("Guests: " + guests);
        System.out.println("Pizzas to order: " + pizzas);
    }
}

Guests: 13
Pizzas to order: 5

public class PizzaParty
{
    public static void main(String[] args)
    {
        int guests = 13;
        int slices = slicesNeeded(guests);
        int pizzas = pizzasNeeded(slices);
        printPlan(guests, pizzas);
    }

    public static int slicesNeeded(int people)
    {
        return people * 3;
    }

    public static int pizzasNeeded(int slices)
    {
        int pizzas = slices / 8;
        if (slices % 8 != 0)
        {
            pizzas++;
        }
        return pizzas;
    }

    public static void printPlan(int people, int pizzas)
    {
        System.out.println("Guests: " + people);
        System.out.println("Pizzas to order: " + pizzas);
    }
}

Guests: 13
Pizzas to order: 5

Decomposition is also a planning tool, before any code exists. Suppose a LibraryBook class needs a behavior “check out the book.” Broken into smaller behaviors, it might be:

1. Check whether the book is available.
2. Record who is borrowing it.
3. Set the due date to two weeks from today.

Each step can become its own method in the plan, such as boolean isAvailable(), void recordBorrower(String name), and void setDueDate(). The big behavior checkOut then just uses those three. Each small method is easier to write and test on its own, and a method like isAvailable can be reused by other behaviors, such as a search page that shows which books are on the shelf.

public class CarWash
{
    public static void main(String[] args)
    {
        printSign();
        int total = washCost(2) + waxCost(2);
        System.out.println("Total: $" + total);
    }

    public static void printSign()
    {
        System.out.println("Sparkle Car Wash");
    }

    public static int washCost(int cars)
    {
        return cars * 8;
    }

    public static int waxCost(int cars)
    {
        System.out.println("Adding wax");
        return cars * 5;
    }
}

Sparkle Car Wash
Adding wax
Total: $26

Decomposition breaks one big behavior into pieces. A different problem shows up when a program does almost the same thing in several places. Look at this program, which prints three rows of stars of different lengths:

public class StarsRepeated
{
    public static void main(String[] args)
    {
        for (int i = 0; i < 5; i++)
        {
            System.out.print("*");
        }
        System.out.println();
        for (int i = 0; i < 3; i++)
        {
            System.out.print("*");
        }
        System.out.println();
        for (int i = 0; i < 8; i++)
        {
            System.out.print("*");
        }
        System.out.println();
    }
}

*****
***
********

The three loops with their println calls (lines 5–9, 10–14, and 15–19) are identical except for one number: 5, 3, or 8. That is duplicated code: the same steps written out more than once. It makes the program longer, and every copy is another place for a mistake.

The fix is to notice the shared features (everything that is the same in each copy), put them into one method, and turn the one thing that differs into a parameter. Recall from Topic 1.9 that a parameter is a variable in the method header that receives a copy of the argument each time the method is called. Because the argument can be different on every call, a parameter makes a method general: it works for a whole range of input values, not just one. Writing the work once and calling it many times is code reuse, and it helps manage complexity.

public class StarsMethod
{
    public static void main(String[] args)
    {
        printStars(5);
        printStars(3);
        printStars(8);
    }

    public static void printStars(int count)
    {
        for (int i = 0; i < count; i++)
        {
            System.out.print("*");
        }
        System.out.println();
    }
}

*****
***
********

Now vary what is generalized. Here is a method with no parameter:

public class WelcomeFixed
{
    public static void main(String[] args)
    {
        printWelcomeAda();
    }

    public static void printWelcomeAda()
    {
        System.out.println("Welcome back, Ada!");
    }
}

Welcome back, Ada!

It can greet only Ada. To greet Grace, you would need a second method, printWelcomeGrace, with the same body except for the name. Instead, make the name a parameter:

public class WelcomeAnyone
{
    public static void main(String[] args)
    {
        printWelcome("Ada");
        printWelcome("Grace");
        String nextUser = "Alan";
        printWelcome(nextUser);
    }

    public static void printWelcome(String name)
    {
        System.out.println("Welcome back, " + name + "!");
    }
}

Welcome back, Ada!
Welcome back, Grace!
Welcome back, Alan!

The shared feature is the greeting pattern, “Welcome back, … !”, and the part that varies, the name, became the parameter name. The argument can be a literal like "Ada" or a variable like nextUser; either way, its value is copied into name.

public class BonusCopies
{
    public static void main(String[] args)
    {
        int levelOneScore = 40;
        int levelOneTotal = levelOneScore * 2 + 20;
        System.out.println("Level 1 total: " + levelOneTotal);

        int levelTwoScore = 40;
        int levelTwoTotal = levelTwoScore * 2 + 10;
        System.out.println("Level 2 total: " + levelTwoTotal);
    }
}

Level 1 total: 100
Level 2 total: 90

public class BonusMethod
{
    public static void main(String[] args)
    {
        int levelOneScore = 40;
        System.out.println("Level 1 total: " + withBonus(levelOneScore));

        int levelTwoScore = 40;
        System.out.println("Level 2 total: " + withBonus(levelTwoScore));
    }

    public static int withBonus(int score)
    {
        return score * 2 + 20;
    }
}

Level 1 total: 100
Level 2 total: 100

public class StarsIgnoreParam
{
    public static void main(String[] args)
    {
        printStars(5);
        printStars(3);
        printStars(8);
    }

    public static void printStars(int count)
    {
        for (int i = 0; i < 5; i++)
        {
            System.out.print("*");
        }
        System.out.println();
    }
}

for (int i = 0; i < count; i++)

Programs keep changing after they are written. A method might be too slow, or someone might find a shorter way to compute the same thing. But a method like pizzasNeeded may be called from dozens of places, written by other programmers. Does improving it mean finding and warning every one of them?

Procedural abstraction answers this. Callers depend only on two things: the method’s signature (its name and parameter types, from Topic 1.9) and what it does (the result it promises). They never depended on how it works inside. So a programmer may change the inside of a method, to make it faster, more efficient, or use less memory, without telling the method’s users, as long as the signature and what the method does stay the same.

public class PizzaIfVersion
{
    public static void main(String[] args)
    {
        System.out.println(pizzasNeeded(39));
        System.out.println(pizzasNeeded(40));
        System.out.println(pizzasNeeded(41));
    }

    public static int pizzasNeeded(int slices)
    {
        int pizzas = slices / 8;
        if (slices % 8 != 0)
        {
            pizzas++;
        }
        return pizzas;
    }
}

5
5
6

public class PizzaFormulaVersion
{
    public static void main(String[] args)
    {
        System.out.println(pizzasNeeded(39));
        System.out.println(pizzasNeeded(40));
        System.out.println(pizzasNeeded(41));
    }

    public static int pizzasNeeded(int slices)
    {
        return (slices + 7) / 8;
    }
}

5
5
6

Now vary the kind of change. Two other changes look small but break the promise.

Changing the signature. Suppose the teammate makes the method more general by adding a parameter for slices per pizza, but the callers still pass one argument:

public class PizzaNewSignature
{
    public static void main(String[] args)
    {
        System.out.println(pizzasNeeded(39));
    }

    public static int pizzasNeeded(int slices, int slicesPerPizza)
    {
        return (slices + slicesPerPizza - 1) / slicesPerPizza;
    }
}

PizzaNewSignature.java:5: error: method pizzasNeeded in class PizzaNewSignature cannot be applied to given types;
        System.out.println(pizzasNeeded(39));
                           ^
  required: int,int
  found:    int

(The exact wording can vary between Java versions.) The signature is now pizzasNeeded(int, int), so every existing call with one argument fails to compile. This is a change callers must be told about, because they have to change their code.

Changing what it does. Suppose the teammate “simplifies” the body to just divide:

public class PizzaForgotRoundUp
{
    public static void main(String[] args)
    {
        System.out.println(pizzasNeeded(39));
        System.out.println(pizzasNeeded(40));
        System.out.println(pizzasNeeded(41));
    }

    public static int pizzasNeeded(int slices)
    {
        return slices / 8;
    }
}

4
5
5

The signature is the same, so everything compiles. But the method no longer returns the number of whole pizzas needed: for 39 slices it says 4 pizzas, which is only 32 slices. Every caller now gets wrong answers without any error message. That is worse than a compile error, because nobody is warned.

When you write a short program, you might start typing right away. A class is different. Its attributes are used by all its behaviors, and other programmers will call its methods. If you discover halfway through that a behavior needs data you never planned, or that an attribute should have been shared, you may have to rewrite much of what you wrote.

That is why it helps to design each class before implementing it: decide its attributes and its behaviors first, then write the code. You have now seen every piece of a design:

• Abstraction (3.1.1) decides which details belong at all.
• Attributes (3.1.3), marked as instance or class variables (3.1.4), hold the data.
• Behaviors (3.1.5), named for what they do, decomposed into smaller methods and generalized with parameters (3.1.6).

A design can be written in natural language (plain sentences or a list) or drawn as a class diagram. Both record the same decisions; a diagram is quicker to scan, and sentences are easier to share with someone who does not know the notation.

+-------------------------------------------+
|                WaterBottle                |
+-------------------------------------------+
| Attributes                                |
|   int capacity                            |
|   int currentAmount                       |
|   int dailyGoal          (class variable) |
+-------------------------------------------+
| Behaviors                                 |
|   void drink(int amount)                  |
|   void refill()                           |
|   double percentFull()                    |
+-------------------------------------------+

Now vary the requirements. The app adds: “The bottle remembers how many times it has been refilled.” That adds one instance variable, int refillCount, and the refill behavior now also updates it. Changing a design on paper takes a minute; changing a class after hundreds of lines use it takes much longer. That is the payoff of designing first.

+-------------------------------------------+
|               ParkingSpot                 |
+-------------------------------------------+
| Attributes                                |
|   int spotNumber         (class variable) |
|   boolean taken                           |
|   double hourlyRate                       |
+-------------------------------------------+
| Behaviors                                 |
|   void markTaken()                        |
|   void markFree()                         |
|   double cost()                           |
+-------------------------------------------+

|   int spotNumber                          |
|   boolean taken                           |
|   double hourlyRate      (class variable) |
...
|   double cost(int hours)                  |

Here is a short program that uses the chapter’s ideas together: a reading planner that tells a student how many days it will take to finish a book.

public class ReadingPlan
{
    public static void main(String[] args)
    {
        int days = daysToFinish(250, 30);
        printPlan("Hatchet", days);
        days = daysToFinish(90, 30);
        printPlan("Frindle", days);
    }

    public static int daysToFinish(int pages, int pagesPerDay)
    {
        int days = pages / pagesPerDay;
        if (pages % pagesPerDay != 0)
        {
            days++;
        }
        return days;
    }

    public static void printPlan(String title, int days)
    {
        System.out.println(title + ": " + days + " days");
    }
}

Hatchet: 9 days
Frindle: 3 days

Look at it through each idea from the chapter:

• Data abstraction (3.1.2). The names pages, pagesPerDay, days, and title say what each value means. Nobody reading main has to think about how they are stored.
• Method decomposition (3.1.5). The job “plan the reading” is split into two smaller behaviors: compute the days (daysToFinish) and print the result (printPlan). main reads as a list of steps.
• Procedural abstraction (3.1.5). A reader of main needs only to know that daysToFinish returns the whole number of days needed. How it rounds up (lines 13–17) is hidden.
• Generalizing with parameters (3.1.6). One daysToFinish method works for any book and any reading speed; one printPlan method prints any title. Without parameters, each book would need its own copy of the calculation.

Trace the two calls to daysToFinish:

For Hatchet, 8 full days covers 240 pages, and the last 10 pages need a ninth day. For Frindle, 3 days covers exactly 90 pages, so no extra day is added.

If this planner became a class, the design step (3.1.8) would start by asking what each book remembers: its title and page count, as instance variables. Writing classes like that in Java begins in Topic 3.3.

• Abstraction reduces complexity by hiding details that do not matter for the problem and keeping the ones that do; which details matter depends on what the program is for.
• Data abstraction separates what data means from how it is represented. A good name lets you use data without knowing its storage details, whether the data is one variable, a class, or a set of values.
• A class’s attributes are kept outside any method or constructor. An instance variable has its own value in each object; a class variable has one value shared by every object.
• Procedural abstraction names a process so it can be used by knowing what it does, not how. Method decomposition splits large behaviors into smaller methods, and parameters let one general method replace duplicated code and be reused with many arguments.
• The inside of a method can change (to be faster or smaller) without telling its callers, as long as its signature and what it does stay the same.
• Before coding a class, design it: choose its attributes and behaviors and record them in natural language or a class diagram.

public class ReadingPlanCopy
{
    public static void main(String[] args)
    {
        System.out.println("Hatchet: " + daysToFinish(250, 30) + " days");
        int wonderDays = 310 / 30;
        System.out.println("Wonder: " + wonderDays + " days");
    }

    public static int daysToFinish(int pages, int pagesPerDay)
    {
        int days = pages / pagesPerDay;
        if (pages % pagesPerDay != 0)
        {
            days++;
        }
        return days;
    }
}

Hatchet: 9 days
Wonder: 10 days

int wonderDays = daysToFinish(310, 30);

public class SumToLoop
{
    public static void main(String[] args)
    {
        System.out.println(sumTo(4));
        System.out.println(sumTo(10));
    }

    public static int sumTo(int n)
    {
        int total = 0;
        for (int k = 1; k <= n; k++)
        {
            total += k;
        }
        return total;
    }
}

public class SumToFormula
{
    public static void main(String[] args)
    {
        System.out.println(sumTo(4));
        System.out.println(sumTo(10));
    }

    public static int sumTo(int n)
    {
        return n * (n + 1) / 2;
    }
}

10
55

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

• I can explain abstraction and choose which details a program should keep for a given problem. Reread
• I can explain how data abstraction separates what data means from how it is stored. Reread
• I can explain what an attribute is and read or draw a class diagram. Reread
• I can decide whether an attribute should be an instance variable or a class variable. Reread
• I can explain procedural abstraction and break a large behavior into smaller methods. Reread
• I can explain how a parameter lets one method replace duplicated code. Reread
• I can decide whether a change to a method needs to be announced to the programmers who call it. Reread
• I can design a class by listing its attributes and behaviors in words or in a class diagram. Reread