OOP Module Projects - Engineering Challenges

Level: Intermediate → Engineering | Format: Build, not follow

These are not exercises. They are not walkthroughs. They are project specifications.

You receive a requirements document, a starter skeleton, and expected outputs. You build the implementation. The same way you would at work.

Each project is designed so that the OOP concepts from the module are not optional - they are structurally required. You cannot complete Project 02 without understanding __eq__ and __hash__. You cannot complete Project 03 without ABCs and dunders. The projects force the concepts into place through real engineering constraints.

How to Approach These Projects

Read the full spec before writing a line of code. The requirements are ordered for comprehension, not for implementation. You will often need to design the class hierarchy before you touch the keyboard.

Sketch the class diagram first. List every class, its attributes, its methods, and its relationships (inheritance vs. composition). This catches design errors before they become refactoring debt.

Build incrementally and test as you go. Implement one class at a time. Write a few lines in a __main__ block to verify it works before moving to the next class.

The hints section exists for when you are genuinely stuck - not as a first resort. Try to work through the problem for at least 20 minutes before reading a hint.

Extension challenges are serious. If you complete the core requirements quickly, the extensions will push you into territory that covers the next two lessons.

The Four Projects

Project 01 - Banking System Simulator

Core OOP concepts tested: Inheritance, @property with validation, @classmethod factory methods, __repr__, encapsulation, polymorphism.

You build a banking system with an Account base class, CheckingAccount and SavingsAccount subclasses, and a Transaction class. The system enforces overdraft protection, tracks full transaction history, and calculates compound interest. This is the entry point - if you have never built an inheritance hierarchy from scratch, start here.

Estimated time: 3–5 hours for core requirements.

Project 02 - Library Management System

Core OOP concepts tested: __repr__, __eq__, __hash__, Abstract Base Classes, composition, date arithmetic, encapsulation.

You build a library system with Book, Member, and Library classes. Books must be hashable so they can live in sets (which requires implementing __eq__ and __hash__ correctly). A LibraryItem ABC enforces a common interface across books and other media. The checkout system tracks due dates and calculates overdue fines. This project is heavier on protocol correctness than Project 01.

Estimated time: 4–6 hours for core requirements.

Project 03 - Chess Engine (OOP Version)

Core OOP concepts tested: ABCs with abstract methods, dunders (__getitem__, __setitem__, __repr__, __str__), dataclasses, composition, MRO, encapsulation of complex state.

This is the hardest project in the module. You build a working chess engine using pure OOP design. A Piece ABC defines the contract every piece must satisfy. Six concrete piece classes implement valid move generation. A Board class wraps a grid using __getitem__ and __setitem__. A Move dataclass carries move data cleanly. The engine tracks game state, detects check, and parses algebraic notation. The extension challenge adds minimax AI.

Do not start here unless you are comfortable with Projects 01 and 02. The complexity is intentional - chess exposes every weakness in a class design.

Estimated time: 8–15 hours for core requirements.

Skills Map

Concept	Project 01	Project 02	Project 03
Class hierarchy design	Yes	Yes	Yes
__init__ and encapsulation	Yes	Yes	Yes
Inheritance	Yes	Yes	Yes
@property with validation	Yes
@classmethod factory	Yes
__repr__ / __str__	Yes	Yes	Yes
__eq__ / __hash__		Yes
Abstract Base Classes		Yes	Yes
__getitem__ / __setitem__			Yes
Dataclasses			Yes
Composition		Yes	Yes
Date arithmetic		Yes
MRO awareness			Yes

Setup

All projects are self-contained. No third-party libraries required beyond the Python standard library.

# Create a working directory
mkdir oop-projects
cd oop-projects

# Run your implementation with
python banking_system.py
python library_system.py
python chess_engine.py

Python 3.10 or later is assumed. Dataclasses, ABCs, and __match_args__ (for structural pattern matching in extensions) require 3.10+.

What Good Looks Like

A complete submission for any of these projects satisfies four criteria:

1. All expected outputs match exactly - the sample outputs in each spec are exact. Your implementation must reproduce them.
2. No public attributes that should be private - if data should not be modified directly from outside the class, it is not directly accessible. Use @property, name-mangling, or controlled interfaces.
3. OOP structure is not decorative - inheritance is used where substitutability is real. Composition is used where ownership is real. Classes are not just bags of functions.
4. The code reads like a domain model - someone reading your class definitions should understand the banking domain, the library domain, or the chess domain without reading comments.

These are the same criteria a senior engineer would apply in a code review.