3.1 Abstraction and Program Design

What you need to know

• Abstraction means focusing on what something does and hiding how. Data abstraction: representing a concept as a class with attributes. Procedural abstraction: a method's name and header stand in for its implementation.
• Designing a class: identify the attributes (what it needs to remember — become instance variables) and the behaviors (what it needs to do — become methods).
• Encapsulation keeps instance variables private and exposes controlled access through public methods. Outside code can't corrupt the object's state.
• Breaking a program into classes and methods makes it easier to write, test, debug, and reuse — the same reasoning as for procedures.
• A class should represent one clear concept. Its public methods are its API to the rest of the program.
• Design happens before code: reading an FRQ 2 prompt, list attributes and behaviors first, then write.

Worked example

Prompt: "Write a class representing a bank account with an owner, a balance, deposits, withdrawals that can't overdraw, and a way to get the balance."

• Attributes: owner (String), balance (double) → private instance variables.
• Behaviors: deposit(amount), withdraw(amount) returning whether it succeeded, getBalance() → public methods.
• Constructor: takes owner and starting balance.

That outline is the design. The code follows in 3.3–3.5.

Going deeper

The nuance, edge cases, and connections that turn a 3 into a 5.

• Data abstraction = modeling a real thing as a class: a Student with a name and GPA, rather than loose variables. Users of the class think "a student" not "a String and a double." Procedural abstraction = a method's name and header standing for its body. Both hide detail; they hide different kinds.
• Designing a class from a description: nouns that describe state → instance variables. Verbs that describe what it does → methods. Adjectives describing the state at creation → constructor parameters. Every FRQ 2 prompt is written to be decomposed this way.
• Encapsulation has two halves: private instance variables (nobody outside can touch them directly) and public methods (the only way in). This guarantees the object's state can only change in ways the class allows — a BankAccount can enforce "no negative balance" because withdraw is the only way to reduce it.
• Why encapsulation matters for the exam: if a question shows a class with a public instance variable, the "what's wrong with this design" answer is that outside code can set invalid state. If it shows a private variable with no getter, the answer to "how can other code read it" is "it can't — add an accessor."
• Good class design is cohesive (one clear concept) and has a minimal public interface (only the methods clients need). Extra public methods are extra ways to break things.
• Classes are also reuse: once Student exists, any program that needs students uses it. Libraries (1.7) are collections of well-designed classes.

Mistakes that cost points

• Adding features the prompt didn't ask for. FRQ 2 rubrics score exactly what's described. Extra methods earn nothing and can introduce errors.
• Making instance variables public. Breaks encapsulation and costs a rubric point.
• Mixing up the two abstractions. A list or class = data abstraction. A method = procedural abstraction.

Practice questions

Written in the style of the real exam. Try each one before revealing the answer.