Capstone & Interview Prep

class LibraryItem {
protected:
    std::string title;
    bool checkedOut = false;

public:
    LibraryItem(std::string t) : title(t) {}
    virtual ~LibraryItem() {}   // Phase 6 Module 7's rule — essential here

    virtual std::string itemType() = 0;   // pure virtual — Phase 6 Module 6
    std::string getTitle() { return title; }
    bool isCheckedOut() { return checkedOut; }
    void setCheckedOut(bool value) { checkedOut = value; }
};

protected members (Phase 6 Module 2) let Book and Magazine access title and checkedOut directly, while outside code is still restricted to the public getters/setters — Phase 5 Module 6's encapsulation, applied here specifically at the inheritance boundary.

class Book : public LibraryItem {
private:
    std::string author;
public:
    Book(std::string t, std::string a) : LibraryItem(t), author(a) {}
    std::string itemType() override { return "Book by " + author; }
};

class Magazine : public LibraryItem {
private:
    int issueNumber;
public:
    Magazine(std::string t, int issue) : LibraryItem(t), issueNumber(issue) {}
    std::string itemType() override { return "Magazine, issue " + std::to_string(issueNumber); }
};

Both constructors explicitly call LibraryItem(t) — exactly Phase 6 Module 3's derived-constructor pattern, delegating the shared setup to the base class rather than duplicating it.

• template <typename T> — Phase 9 Module 2, letting this ONE class manage LibraryItem, or genuinely anything else, without rewriting it.
• std::vector<std::unique_ptr<T>> — Phase 8 Module 9's exact pattern, combining the STL (Phase 7) with automatic memory management.
• std::find_if with a lambda — Phase 7 Modules 6 and 8, an STL algorithm customized with an inline function.
• std::move in add() — Phase 8 Module 4, transferring ownership into the vector rather than copying.

class ItemAlreadyCheckedOutError : public std::runtime_error {
public:
    ItemAlreadyCheckedOutError(std::string title)
        : std::runtime_error("'" + title + "' is already checked out") {}
};

class ItemNotFoundError : public std::runtime_error {
public:
    ItemNotFoundError(std::string title)
        : std::runtime_error("No item titled '" + title + "' was found") {}
};

This is precisely Phase 10 Module 3's custom-exception pattern — inheriting from std::runtime_error, building a genuinely meaningful message in the constructor. Two SEPARATE types let calling code react differently to each situation, applying Phase 10 Module 4's multiple-catch-blocks pattern.

void checkOut(Repository<LibraryItem>& repo, std::string title) {
    LibraryItem* item = repo.findByTitle(title);
    if (item == nullptr) {
        throw ItemNotFoundError(title);
    }
    if (item->isCheckedOut()) {
        throw ItemAlreadyCheckedOutError(title);
    }
    item->setCheckedOut(true);
}

Notice this checks for nullptr (Phase 4 Module 9) BEFORE calling isCheckedOut() — dereferencing a null pointer here would be the exact undefined-behavior danger that module warned about.

void saveLibrary(Repository<LibraryItem>& repo, std::string filename) {
    std::ofstream outFile(filename);
    for (const auto& item : repo.all()) {
        outFile << item->getTitle() << "|"
                << item->itemType() << "|"
                << item->isCheckedOut() << std::endl;
    }
}

Genuinely the same CSV-style pattern from Phase 11 Module 5, just using | as the delimiter since titles might genuinely contain commas. Notice item->itemType() is called polymorphically (Phase 6 Module 5) — the SAME line of code correctly produces "Book by ..." or "Magazine, issue ..." depending on the object's real type.

Run through this: Repository<LibraryItem> (Phase 9 templates), std::make_unique (Phase 8 smart pointers) creating Book/Magazine objects (Phase 6 inheritance), try/multiple catch blocks (Phase 10) around a function that validates before throwing (Phase 5's encapsulation principle), a range-based for loop (Phase 7) calling a virtual function polymorphically (Phase 6), and finally saveLibrary (Phase 11). Thirteen phases, one working program.

A genuine answer: A pointer can be reassigned to point elsewhere, can be nullptr, and requires explicit dereferencing with *. A reference (Phase 3 Module 7) must be initialized when declared, can never be reassigned to refer to something else, and is used with the same syntax as the original variable. References are generally safer for simple pass-by-reference; pointers are needed when "no valid target" (nullptr) or reassignment is genuinely required.

A genuine answer: Memory allocated with new (Phase 4) that's never freed with delete, because the pointer to it was lost. Modern C++ prevents this structurally with RAII and smart pointers (Phase 8) — std::unique_ptr/std::shared_ptr guarantee cleanup happens automatically via the destructor, even during an early return or an exception (Phase 10 Module 4).

A genuine answer: Calling the same function on objects of different derived types and getting each type's own correct behavior, decided at runtime based on the object's ACTUAL type rather than a pointer's declared type (Phase 6 Module 5). This capstone's item->itemType(), called identically on both Book and Magazine objects through a shared LibraryItem*, is a genuine, concrete working example.

A genuine answer (a concept this roadmap touched on without naming formally): If a class manually manages a resource (like raw memory), and needs a custom destructor, it typically also needs a custom copy constructor and copy assignment operator — the "Rule of Three." Modern C++ extends this to "Rule of Five" adding move constructor and move assignment (Phase 8 Modules 5-6). Using smart pointers (Phase 8) instead of raw resource management is exactly what lets most classes AVOID needing to write any of these by hand at all.

A genuine answer: std::vector (Phase 7 Module 2) for ordered data accessed by position, where insertion order matters. std::map (Phase 7 Module 4) when you need to look things up by a meaningful key rather than a numeric position, and want that lookup to be efficient. Choosing between them is genuinely about how the data will actually be ACCESSED, not just what it stores.

A genuine answer: unique_ptr (Phase 8 Module 2) enforces single, exclusive ownership — it can't be copied, only moved. shared_ptr (Phase 8 Module 3) allows multiple owners via reference counting, deleting the resource only once every owner is gone. Default to unique_ptr unless genuine shared ownership is required — it's simpler and has less overhead.

A genuine answer: It tells the compiler to infer a variable's type from what's assigned to it, at COMPILE time (Phase 8 Module 7) — not a dynamic or runtime-flexible type the way it might work in some other languages. It's genuinely most useful for long, awkward types like STL iterators, and should be used carefully where it might otherwise hurt readability.

A genuine answer, drawing directly on Phase 12: Reproduce it reliably first. Use a real debugger (Module 2) to find the exact line and inspect the call stack at the crash point. Check for the classic causes from this roadmap: a null pointer dereference (Phase 4 Module 9), a dangling pointer after delete (Phase 4 Module 8), or an out-of-bounds array access (Phase 3 Module 2). A static analysis tool (Phase 12 Module 5) can also catch many of these before the program ever runs at all.

Pre-Course → Fundamentals → Loops → Arrays/Strings/Functions → Pointers & Memory → OOP → Inheritance & Polymorphism → the STL → Modern C++ → Templates → Error Handling → File I/O → Tooling → this capstone. Every single one of those built directly on the last — and this final phase genuinely proved it, by using every one of them together in one real system.

That's not a vague encouragement — it's a direct claim you can now verify for yourself: you can explain memory management, RAII, and polymorphism in interview terms (Modules 7-8); you can build and debug a real multi-file project with CMake, git, and a debugger (Phase 12); and you've built something genuinely more substantial than a single-file script, with real error handling and persistence.