Skip to content

Course Information

What this course covers, how it is structured, and what an instructor needs to supply for their own institution.

Course description

Object-Oriented Programming using C++ is a university-level course that takes students with introductory programming experience and teaches them to design and build software in modern C++ (C++17). It covers the object-oriented mechanisms — abstraction, encapsulation, inheritance, polymorphism — through to resource management with RAII and smart pointers, generic programming with templates and the STL, exception safety, design principles, and the design patterns that make object-oriented systems changeable.

The course is practical throughout. Concepts are introduced only when a program the student is already building needs them.

Intended audience

Undergraduate students who can already write programs using variables, control flow, functions and arrays, in C++ or any other language. No object-oriented experience is assumed. The exact expectations are listed on the Prerequisites page and include a refresher on references and pointers.

Learning outcomes

On completing the course a student can:

  1. Model a problem domain as cooperating C++ types with clear responsibilities.
  2. Design classes with enforced invariants and stable, const-correct interfaces.
  3. Implement encapsulation, composition, inheritance and polymorphism in C++17, and justify choosing one mechanism over another.
  4. Manage object lifetime and resources correctly, and explain every copy and move their program performs.
  5. Handle failure with exceptions and exception-safe design.
  6. Generalise code with templates and the standard library, selecting containers and algorithms on complexity evidence.
  7. Persist and organise a multi-file application that builds reproducibly.
  8. Document a design with UML and apply SOLID and selected design patterns without over-engineering.
  9. Test and debug their own code, including reading compiler diagnostics and writing boundary and failure tests.
  10. Evaluate design trade-offs and communicate the reasoning in writing.

This list mirrors the outcomes stated on the student-facing course home, so instructors and students are working from the same statement of intent.

Structure
Modules 16, in a fixed order, each assuming the ones before it
Labs 16, cumulative: one system extended in every module
Exercises Three tiers per module (warm-up, core, challenge)
Quizzes One per module
Projects One mid-course project, plus the capstone
Assessments Two practice midterms, one practice final, a question bank
Standard C++17, compiled with g++ -std=c++17 -Wall -Wextra

Module order, prerequisites and per-module objectives: All Modules. A suggested sixteen-week mapping to a semester is in Study Plan.

The course comes in four arcs: foundations (Modules 1–4), building objects well (5–8), objects relating to objects (9–12), and professional practice (13–16).

Assessment

Unlike most published course material, this repository publishes rubrics, so that self-study students are assessed against the same standard as enrolled ones. The general rubric — correctness, design, object orientation, resource management, failure handling, code quality, documentation, testing — is on the Projects page, along with the capstone's additional requirements.

Practical work dominates: sixteen labs and a capstone. The practice papers are exam-style and are published with answer keys, kept separate so students attempt them honestly first.

A note on solutions. Reference material for the practical work is published deliberately, because a self-study student with no access to any of it is stuck rather than challenged — but it is published selectively, and the selection is deliberate too:

  • Labs 1–4 have complete reference solutions under examples/labs/, because their purpose is to be compared against.
  • Labs 5–16 publish none. Each is an increment on a program the student has already written, so the design decisions are the exercise; each lab page says what to compare instead, and names the example programs to read.
  • Module exercises are answered by an explicit mapping on each module's Exercises page — to a reference program under examples/module-NN/, or to the discussion that constitutes the answer. A few are deliberately unanswered, and the page says so.
  • The 160-exercise bank publishes a hint and a model answer per exercise, in docs/exercises/bank/.

Instructors assessing for credit can withhold any of these for the duration of a term without touching the teaching pages: the files are separate from the module pages that refer to them.

What an instructor must supply

The following are institution- and offering-specific and are not stated in this repository, because inventing them would misrepresent a real course. Fill them in for your own delivery:

  • credit hours, contact hours, and whether a lab session is separate;
  • marks distribution and weighting between labs, projects, quizzes, midterm and final;
  • semester dates, week numbering and holidays;
  • examination regulations, attendance policy and academic-integrity rules;
  • submission procedures and late-submission penalties;
  • the department's contact details for the instructor and teaching assistants;
  • any programme-level mapping (course learning outcomes to programme outcomes) required by your institution.

The instructor-only planning material under meta/ in the repository is the right place for those details, so that the student-facing pages remain accurate for everyone using them.

Adapting the course

You may adapt freely under the licence — content CC BY 4.0, code MIT.

Two cautions, both about coherence rather than permission:

  1. The module sequence encodes prerequisites. If you reorder, re-check them — the module table lists each module's dependency.
  2. The cumulative lab spine is the course's main teaching device. Sixteen laboratories building one system is what makes each OOP feature arrive as a solution to a felt problem. If you replace it, expect to rebuild the motivation for each concept as well.

Before changing repository structure, read docs/technical/authoring-guide.md: the repository's quality checks verify navigation, link integrity, module completeness and naming, so structural edits need to keep those passing.

Licence and attribution

If you teach from these materials, attribution is required and appreciated:

"Based on Object-Oriented Programming using C++ by Muhammad Nadeem Majeed, University of the Punjab, Lahore — licensed under CC BY 4.0."