OOP practice: Student, Bank, Employee

The last few lessons handed you a set of tools: classes and objects, fields, methods, constructors, private data, inheritance, overriding and polymorphism. This lesson adds no new ideas. Instead you design three small but complete classes from scratch, the kind real programs are full of, and watch each one run.

A small recipe for designing a class#

Before the code, a way to think. When you sit down to design a class, you are answering the same few questions every time. Keep this list nearby for all three designs below.

1. 1What one kind of thing is this? Name it. A class is a single, clear noun: Student, not StuffAboutSchool.
2. 2What does it have? Those are the fields, its state. Pick a type for each.
3. 3How is a valid one built? That is the constructor. What must you know to make a sensible object?
4. 4What does it do? Those are the methods, its behavior. Each one reads or changes the object's own fields.
5. 5How should it look when printed? Write a toString so the object reads as a sentence, not as its class name and a number.

Design one: Student#

A student record. It has a name, an id number, and a grade point average. It is built from all three at once. It can answer one question we care about: did this student make the honor roll? We will say the honor roll is a GPA of 3.5 or higher. And it prints as a tidy line.

Read it, then press Run and step through. Watch the constructor fill the fields with this, one field per step, and watch isHonorRoll compare each student's own gpa against the threshold.

That prints four lines:

• Student #901 Aisha (GPA 3.8)
• Student #902 Ben (GPA 2.9)
• Aisha made the honor roll.
• Ben did not make the honor roll.

Three things to notice, because they recur in every design. First, the constructor parameters share names with the fields (name, id, gpa), so this.name = namesays “set my field name from the parameter name”. Second, isHonorRoll returns a boolean, which is exactly what an if wants, so if (a.isHonorRoll()) reads almost like English. Third, when we wrote System.out.println(a) with just the object, Java called our toString to turn it into that readable line.

Design two: BankAccount, with the data protected#

A bank account is the classic case for encapsulation: hiding the data so the outside world cannot put the object into a nonsense state. The balance is the thing to protect. If anyone could write acc.balance = -999 from outside, the account would be broken and nothing could stop them. So we make balance private and only let it change through methods that check the request first.

The two methods, deposit and withdraw, each validate before they act. A deposit must be positive. A withdrawal cannot take out more than is there. When a request fails, the method says so and leaves the balance alone. Run it and watch the rejected withdrawal: the balance does not move.

Trace the run. Start at 100. Deposit 50, now 150. Try to withdraw 200, which is more than 150, so it is rejected and the balance stays 150. Withdraw 80, now 70. The four lines printed are:

• Deposited 50.0, balance now 150.0
• Rejected: cannot withdraw 200.0 from 150.0
• Withdrew 80.0, balance now 70.0
• Final: Aisha has 70.0

Key idea

Encapsulation means putting a gatekeeper in front of a field: a method that decides whether a change is allowed before letting it through. Private data plus validating methods is how an object protects its own rules.

Notice the early return inside each method. When a request is invalid, the method prints a message and returns straight away, before the line that would change the balance. This is a common and tidy pattern: check for the bad cases first, leave early, and let the rest of the method assume everything is fine.

The constructor checks its input too. Ben opens an account with -20.0, then tries a negative deposit, a real one, and a withdrawal. Decide what this run prints.

The account opens at 0, because the constructor refuses -20.0. The deposit of -5.0 is turned away, the deposit of 30.0 brings the balance to 30, and the withdrawal of 40 is more than 30, so it is rejected. The final line is Final: Ben has 30.0. Every way into the balance was guarded, so it never went below zero.

Design three: Employee, then Manager on top#

The last design pulls in inheritance and polymorphism. We start with an Employee: a name, a salary, and the ability to give itself a raise by a percentage. Then we notice that a manager is an employee with something extra, a bonus, so instead of copying everything we build Manager on top of Employee with extends.

Read the two classes first. Manager inherits name, salary, and the whole raise method for free. It adds a bonus field, and it overrides toStringto mention the bonus, reusing the parent's version with super.toString() rather than rewriting it.

This prints two lines:

• Ravi earns 4400.0
• Sana earns 6600.0 plus a bonus of 1500.0

Walk through the numbers. Ravi starts at 4000, a 10 percent raise adds 400, giving 4400. Sana starts at 6000, a 10 percent raise adds 600, giving 6600. The raise method was written once in Employee, and Manager used it unchanged: that is inheritance saving you the copy.

Two things are happening at once here

First, super.toString(). Inside Manager's toString, the call super.toString() runs the parent's version, which returns "Sana earns 6600.0", and then Manager adds " plus a bonus of 1500.0". That is how you extend behavior instead of replacing it: do what the parent did, then add to it.

Second, the loop is polymorphic. The array is typed Employee[], but one slot holds a real Manager. When the loop reaches staff[i] in println, Java looks at the actual object at runtime and runs that object's toString. So the same line of code prints a plain employee one time and a manager with a bonus the next, with no if deciding which is which.

Key idea

Inheritance lets a subclass reuse a parent's fields and methods. Overriding lets it change one of them. Polymorphism means a variable typed as the parent will still run the real object's version at runtime. Together they let one piece of code handle a whole family of related objects.

How Manager builds its Employee half

Look at the first line of the Manager constructor: super(name, salary);. A manager is an employee with something extra, so before Manager sets its own bonus, it asks the Employee constructor to set up the name and salary. That call builds the Employee part of the object, so it has to come before anything that uses that part, and it is usually the very first line.

Here it is not optional. Employee only has a constructor that takes a name and a salary. If Manager left out the super(...) line, Java would try to call an Employee() constructor with no arguments, find none, and refuse to compile the program with the error constructor Employee in class Employee cannot be applied to given types. The full story is in inheritance.

Now a third kind of employee, written by you. An intern's raise should be half of whatever percentage the others get, and the loop in main must not need to know that.

1public class Main {
2    public static void main(String[] args) {
3        Employee[] staff = {
4            new Employee("Ravi", 4000.0),
5            new Intern("Theo", 2000.0)
6        };
7 
8        for (int i = 0; i < staff.length; i = i + 1) {
9            staff[i].raise(10.0);
10            System.out.println(staff[i]);
11        }
12    }
13}
14 
15class Employee {
16    protected String name;
17    protected double salary;
18 
19    Employee(String name, double salary) {
20        this.name = name;
21        this.salary = salary;
22    }
23 
24    void raise(double percent) {
25        salary = salary + salary * percent / 100;
26    }
27 
28    @Override
29    public String toString() {
30        return name + " earns " + salary;
31    }
32}
33 
34class Intern extends Employee {
35    Intern(String name, double salary) {
36        super(name, salary);
37    }
38 
39    // TODO: override raise so an intern gets half the percentage
40}

Stepping back: the shape of all three#

Different as they are, the three designs share one skeleton. Seeing it makes the next class you design feel familiar before you start.

Your turn. Here is a library book with the recipe half done: the fields, the constructor and the toString are written. The two methods that change the book are yours. It is a guarded resource, the same shape as BankAccount.

1public class Main {
2    public static void main(String[] args) {
3        Book b = new Book("Dune", 2);
4 
5        b.borrow();
6        b.borrow();
7        b.borrow();
8        b.returnCopy();
9 
10        System.out.println(b);
11    }
12}
13 
14class Book {
15    private String title;
16    private int copiesAvailable;
17 
18    Book(String title, int copies) {
19        this.title = title;
20        this.copiesAvailable = copies;
21    }
22 
23    void borrow() {
24        // TODO: with no copies left, print "No copies of Dune left"
25        // (built from the title) and change nothing. Otherwise take
26        // one copy away and print "Borrowed Dune, 1 left".
27    }
28 
29    void returnCopy() {
30        // TODO: put one copy back
31    }
32 
33    @Override
34    public String toString() {
35        return title + ": " + copiesAvailable + " available";
36    }
37}

Further reading#

• Creating Classes, the dev.java tutorial on declaring a class, its fields and who may access them
• Object as a Superclass, the dev.java tutorial on toString, equals and the other methods every class inherits
• JEP 513, Flexible Constructor Bodies, the Java 25 change that allows statements before super(...)