Question 23 of 28: Visibility of Classes, Variables, and Methods

Question 23: Visibility of Classes, Variables, and Methods (Part V)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Visibility (access control) determines which other code — the same class, subclasses, the same package/file, or everywhere — may access a given class, field, or method. The common levels are private (declaring class only), protected (declaring class plus subclasses), and public (everywhere); Java additionally has package-private (the default, no modifier, visible within the same package), while C++ has no package-level visibility but offers friend (Question 25) as a deliberate, named exception.

// Java
public class Account {
    private double balance;      // Account only
    protected String ownerName;  // Account + subclasses
    public String getBalance() { return String.valueOf(balance); }
}

// C++
class Account {
private:
    double balance;              // Account only
protected:
    std::string ownerName;       // Account + subclasses
public:
    std::string getBalance() const { return std::to_string(balance); }
};

Why it matters for encapsulation and modularity. Restricting direct access to balance forces every interaction to go through Account's own public methods, so the internal representation (e.g. switching from a double to a fixed-point cents integer) can change without breaking any external caller — the essence of encapsulation. It also confines the "blast radius" of a change: a private field can only ever be touched by code inside its own class, so the set of code that must be reviewed when that field's meaning changes is known and bounded, which is exactly what allows classes to be developed and modified independently (modularity).