Object-Oriented Programming in C++: State, Behaviour and Valid Objects

What is object-oriented programming?

Gammal Tech's OOP course requires C++. Data Structures and Algorithms are not stated prerequisites for that OOP branch, although the subjects can support one another as your knowledge grows.

Model one clear rule

Suppose a progress object tracks completed lessons out of a fixed total. Its rule is that completed lessons never exceed the total. Rather than exposing a freely writable counter, provide an operation that checks whether another completion is allowed.

#include <iostream>

class Progress {
    unsigned total_;
    unsigned completed_ = 0;
public:
    explicit Progress(unsigned total) : total_(total) {}

    bool complete_one() {
        if (completed_ >= total_) {
            return false;
        }
        ++completed_;
        return true;
    }

    unsigned completed() const {
        return completed_;
    }
};

int main() {
    Progress progress(2);
    progress.complete_one();
    progress.complete_one();
    progress.complete_one();
    std::cout << progress.completed() << '\n';
}

The output is 2. A third completion attempt returns false and leaves the state unchanged. This is a small example of maintaining an invariant through an interface.

Distinguish the terms

Making a field private is a tool, not a complete design by itself. If every method permits invalid changes, the object still fails to protect its rule.

Do you need inheritance?

Not for this example. A single class with a clear responsibility is sufficient. Inheritance becomes relevant when a genuine type relationship and substitutable behaviour justify it; it is not a required decoration on every OOP exercise.

Composition means an object contains or uses other objects. For instance, a larger study record might contain a progress object. Do not choose a relationship merely to demonstrate a language feature.

Test behaviour rather than private details

Create a total of two, attempt three completions and check that the count is two. Also consider a total of zero: the first completion should fail and the count remain zero.

The test focuses on externally visible behaviour. It does not need direct access to the private counter. That separation lets an implementation change while the agreed interface remains understandable.

Your next exercise

Write a short specification for resetting progress. Should resetting be allowed? Does it preserve the total? What should happen after a reset? Answer those questions before adding a method.

OOP becomes useful when the object boundaries and rules simplify reasoning. Aim for a small model whose behaviour you can explain, then use the project guide to plan a larger state-based exercise.