Solved exercise: classes and objects with a wallet in Java

The solution separates two responsibilities. The Wallet class protects its state and applies the business rules; the main method only reads lines, finds the owner's wallet and writes the result. This split is exactly what a first exercise on classes and objects is meant to illustrate.

The balance is stored as an int in cents. With integers every comparison is exact, and the limit of 15000 can be tested without fear of rounding errors.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.HashMap;
import java.util.Map;

public class Main {

    static class Wallet {
        private static final int MAXIMUM = 15000;

        private final String owner;
        private int balance;

        Wallet(String owner) {
            this.owner = owner;
            this.balance = 0;
        }

        String getOwner() {
            return owner;
        }

        int getBalance() {
            return balance;
        }

        String topUp(int cents) {
            if (cents <= 0) {
                return "INVALID";
            }
            if (balance + cents > MAXIMUM) {
                return "LIMIT";
            }
            balance += cents;
            return "OK";
        }

        String pay(int cents) {
            if (cents <= 0) {
                return "INVALID";
            }
            if (cents > balance) {
                return "INSUFFICIENT";
            }
            balance -= cents;
            return "OK";
        }

        String balanceInDollars() {
            return String.format("%d.%02d", balance / 100, balance % 100);
        }
    }

    public static void main(String[] args) throws IOException {
        BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
        String first = in.readLine();
        if (first == null || first.isBlank()) {
            return;
        }
        int n = Integer.parseInt(first.trim());
        Map<String, Wallet> wallets = new HashMap<>();
        StringBuilder output = new StringBuilder();

        for (int i = 0; i < n; i++) {
            String line = in.readLine();
            if (line == null) {
                break;
            }
            String[] parts = line.trim().split("\\s+");
            String owner = parts[0];
            String operation = parts[1];
            int amount = Integer.parseInt(parts[2]);

            Wallet w = wallets.computeIfAbsent(owner, Wallet::new);
            String result;
            if (operation.equals("TOPUP")) {
                result = w.topUp(amount);
            } else {
                result = w.pay(amount);
            }
            output.append(result).append(' ')
                  .append(w.getOwner()).append(' ')
                  .append(w.balanceInDollars()).append('\n');
        }
        System.out.print(output);
    }
}

The Wallet class. The fields owner and balance are private and the constant MAXIMUM is 15000. The constructor sets the balance to 0. Outside the class there is no way to write to balance: only topUp and pay modify it, and both validate before touching it. That is encapsulation in practice: the invariant "0 ≤ balance ≤ 15000" holds because a single class guards it.

Order of the checks. In topUp the code first tests cents <= 0 and then balance + cents > MAXIMUM; in pay, the non-positive amount and then cents > balance. The order matters: a negative amount must yield INVALID regardless of any other rule. Only the final, accepted branch executes balance += cents or balance -= cents, so a rejected operation leaves the balance untouched.

The main method. The HashMap associates each name with its object. computeIfAbsent(owner, Wallet::new) creates the wallet with balance 0 the first time and returns the existing one afterwards, so each owner has a distinct, independent object. Each line is split on whitespace and the result is accumulated in a StringBuilder to be printed at the end. If n is 0 the loop never runs and nothing is written.

Balance format. balanceInDollars uses balance / 100 and balance % 100 with %02d, so 50 cents is written 0.50 and 15000 is written 150.00. Since the value never goes through a double, there is no rounding to explain surprising results.

Test cases. The first test, the one in the statement, mixes top-ups and payments of two owners and checks that their balances do not get mixed: bob's payment of 600 is rejected with INSUFFICIENT while alice is unaffected. The second exercises the rejection reasons (zero amount, negative amount and a payment larger than the balance). The third, "Exact balance limits", tops up to exactly 150.00, which is accepted, and then confirms that one more cent is rejected with LIMIT without altering the balance. The fourth covers input with 0 operations, which produces no output, and the fifth a single operation by a new owner.