18. Classes and Objects

Advanced perspective: access control is useful only when the type accepts responsibility

A class earns its boundary by making invalid states or transitions harder to express

Putting variables between class braces does not create a useful abstraction. Nor does changing public to private while supplying a setter for every field. The real test is whether the type takes responsibility for a coherent state model: what must be true after successful construction, which operations may change the state, which requests are rejected, and what remains true after rejection.

An object has identity, state and lifetime. Its class definition describes the type shared by such objects; it does not create one universal object. Two Account objects can obey the same rules while holding different balances. An ordinary int is also an object, although its type is supplied by the language. We introduce a user-defined class when the program needs a responsibility that a collection of unrelated values and functions does not state clearly enough.

Construction must either establish a usable object or fail

#include <iostream>
#include <stdexcept>

class Account {
public:
    explicit Account(int openingBalance) : balance_{openingBalance} {
        if (openingBalance < 0) {
            throw std::invalid_argument{"opening balance cannot be negative"};
        }
    }

    bool withdraw(int amount) {
        if (amount < 0 || amount > balance_) {
            return false;
        }
        balance_ -= amount;
        return true;
    }

    int balance() const {
        return balance_;
    }

private:
    int balance_;
};

int main() {
    Account account{100};
    account.withdraw(30);
    std::cout << account.balance() << '\n';
}

A successful Account promises that balance_ >= 0. Construction with 100 establishes that state. The withdrawal request is valid because 30 is non-negative and no greater than the current balance, so the state changes from 100 to 70 and the program prints 70.

The constructor also exposes an important boundary in the word "invariant". With a negative argument, balance_ is initialised before the constructor body detects the problem. The exception prevents construction from completing, so no usable Account with a negative balance escapes to the caller. The externally promised invariant holds for every successfully constructed object. If a type requires the member never to contain a rejected value even during construction, validation must occur before that member is initialised, for example through a checked helper or factory. State the required boundary; do not pretend every class needs the stronger one.

The rejected cases matter as much as the accepted one. A method that returns false after partially changing the balance has not honoured the model. Tests should inspect both the reported outcome and the resulting state. The invariant is a relation over program states; a method name is not evidence that the relation survived.

Encapsulation controls transitions, not merely spelling

private prevents an ordinary caller from writing account.balance_ = -500;. That closes one path. A member function can still write an invalid value, expose a mutable reference to the member, retain a dangling alias or perform work that belongs to another component. Access control determines which code may name the representation directly. Encapsulation depends on what that privileged code actually permits.

This is why withdraw(amount) describes more than set_balance(value). The withdrawal operation receives a request, checks it against the current state and either performs one valid transition or rejects it without change. A general setter transfers the responsibility back to every caller. If the class accepts any value a caller chooses, the data is privately spelt but publicly controlled.

The const on balance() allows the member to be called through a const account and prevents ordinary modification of that account through this. It supports the claim that this operation is an observation. It is not a moral guarantee: indirection, global state or carelessly used mutable data can still create externally visible effects. Review the behaviour as well as the qualifier.

Decide whether objects are values or entities

The compiler can copy this simple Account by copying its integer member. Whether that operation is meaningful is a design question, not a mechanical one. If an account object represents a value-like snapshot, independent copies may be sensible. If it represents one continuing real-world identity, accidental duplication may violate the model even though every copied integer is valid.

Ask what equality means, whether two objects may represent the same entity, and what copying is supposed to produce. Then make copy and move operations agree with that answer. Deleting copying is appropriate when duplication has no meaning or a unique resource forbids it. Default copying is appropriate when well-behaved members already express independent value semantics. A hand-written copy constructor is justified only when the type has a real policy to implement.

Representation privacy should buy freedom to change representation

A class that exposes its internal vector by mutable reference has published more than a convenience. It has published storage choice, invalidation behaviour and unrestricted mutation. Replacing the vector later may break callers even if the class's intended behaviour has not changed. Returning a read-only value, an operation-specific result or a carefully bounded view can preserve more design freedom.

This does not mean every getter is wrong or every data member belongs behind a behavioural ceremony. A coordinate with two independently meaningful public values may be an honest open record. C++ permits both struct and class to have constructors, member functions, templates and inheritance. Their principal language differences are default member access and default base-class access: public for struct, private for class. The common convention of using struct for an open record and class for an invariant-protecting abstraction communicates intent; it is not a separate capability tier.

Composition and inheritance answer different substitution questions

Composition says that one object uses or owns another as part of its implementation. Inheritance says more than two types share fields: public inheritance presents a derived object where a base object is expected and therefore accepts the base interface's behavioural obligations. The phrase "is a" is a useful prompt, but it is not a completed substitution argument.

If a Team owns a std::vector<Player>, composition already gives it managed storage, destruction, and defined copy and move behaviour inherited from its members. Unless the class adds a raw resource or a different identity policy, a hand-written destructor and copy constructor add code without adding meaning. This is the Rule of Zero: choose members that already own their responsibilities, then let generated special member functions express the composition.

Runtime polymorphism is justified when callers must work through one stable interface while selecting implementations at runtime. Templates can express compile-time variation when concrete types may be known during compilation. "Virtual is slow" and "templates are fast" are proxies, not decisions. Substitution needs, ownership, binary boundaries, code size, diagnostics and measured cost all belong in the judgement.

Transfer task: design the state model before designing the methods

Design an InventoryItem with stock and reserved quantities. Its invariant is 0 <= reserved && reserved <= stock. The system must receive stock, reserve an available quantity, cancel a reservation and dispatch reserved items. For each operation, state the accepted inputs, the state transition on success and the unchanged state required on failure.

Now decide whether callers need set_stock, set_reserved, neither or both. Decide whether copying an item duplicates an independent value or creates an impossible second representation of one inventory identity. Finally, list the minimum observations needed for tests without returning mutable references to the representation. Write the public interface only after those decisions. Otherwise the first draft of the methods will quietly become the specification.

#include <cstdint>

class InventoryItem {
public:
    using quantity_type = std::int64_t;

    enum class Result {
        applied,
        non_positive_quantity,
        insufficient_available,
        exceeds_reserved,
        quantity_overflow
    };

    explicit InventoryItem(quantity_type initial_stock);

    InventoryItem(const InventoryItem&) = delete;
    InventoryItem& operator=(const InventoryItem&) = delete;
    InventoryItem(InventoryItem&&) = delete;
    InventoryItem& operator=(InventoryItem&&) = delete;

    [[nodiscard]] Result receive(quantity_type quantity) noexcept;
    [[nodiscard]] Result reserve(quantity_type quantity) noexcept;
    [[nodiscard]] Result cancel_reservation(quantity_type quantity) noexcept;
    [[nodiscard]] Result dispatch(quantity_type quantity) noexcept;

    [[nodiscard]] quantity_type stock() const noexcept;
    [[nodiscard]] quantity_type reserved() const noexcept;
    [[nodiscard]] quantity_type available() const noexcept;

private:
    quantity_type stock_ = 0;
    quantity_type reserved_ = 0;
};

A class is not successful because it contains data and functions. It is successful when its constructors establish a usable state, its operations preserve the stated model, its failures leave a defined result, and its interface keeps callers from assuming responsibilities the type was created to own.