Intermediate Projects¶

Ten projects of a few evenings to a week each. They are the step where a project stops being one class with a main and becomes a small system: several types with relationships, a container in charge, a failure policy, and a file it can read and write.

Every project here is one of the designated integration projects: it must use multiple classes with real relationships, encapsulation, inheritance or composition, polymorphism, the STL, and exception handling — all seven, not whichever three you find convenient.

No complete solutions are provided. Each brief gives the requirements, the constraints and the checklists you assess yourself against. The design is the work.

The ten projects¶

#	Project	Difficulty	Effort	Modules	Core skill
1	Virtual Zoo	Intermediate	10–14 h	6–8	A hierarchy that earns its inheritance, plus a visitor-style report
2	Student Gradebook	Intermediate	12–16 h	4, 14	Invariants, ordered containers, and graded rules that vary
3	Shape Editor	Intermediate	12–16 h	7, 11	Polymorphic editing over an owned document
4	Playlist Manager	Intermediate	12–16 h	9, 11	Ownership across two containers, and undo
5	Car Park Ticket System	Intermediate	12–18 h	9, 15	Occupancy invariants and a pricing policy
6	Vending Machine	Intermediate	10–14 h	13	A state machine that refuses gracefully
7	Quiz Engine	Intermediate	14–18 h	8, 12	Polymorphic question types loaded from a file
8	Payroll System	Intermediate	14–18 h	6, 12	Many kinds of employee, one run loop, a factory
9	Contact Book	Intermediate	12–16 h	14, 13	Persistence, search and edit under an invariant
10	Shipping Quote Engine	Intermediate	12–18 h	15	Rules that compose instead of branching

The seven things every intermediate project must use¶

Explicitly required, and checked in each brief's concept table:

Requirement	What "yes" looks like
Multiple classes	At least four types with single responsibilities, none of them a namespace in disguise
Relationships between classes	Composition, aggregation or association, each named in an ownership diagram
Encapsulation	Every invariant is unreachable from outside the class that owns it
Inheritance or composition	Used where it genuinely fits, and the alternative considered
Polymorphism	At least one operation that dispatches on a derived type through a base interface
The STL	Containers and algorithms doing the work, with a stated reason for each container
Exception handling	A failure policy: what is refused, what is thrown, what is left unchanged

What every intermediate project also requires¶

Multi-file layout: at least one header/source pair per class group, with a documented build command.
A file it can read, or a documented input format — most of them require persistence.
Tests with assertions, covering invariants, boundaries and failure paths.
No warnings with g++ -std=c++17 -Wall -Wextra -Werror.
A design note: one page naming your classes, your relationships and one decision you would make differently now.

How to work through this tier¶

Do them roughly in order — later projects assume the earlier ones' habits. If you have limited time, the three worth most are Virtual Zoo (polymorphism done honestly), Car Park Ticket System (invariants under real operations) and Shipping Quote Engine (rules that compose).

Write the class list and the ownership diagram before any code.
Build the smallest end-to-end path first: create, operate, print.
Add persistence, then the failure policy, then the polish.
Run the checklists honestly, then write the design note — the note is where the learning is consolidated, not a formality.