What OOP Actually Taught Me

Reflections from 42’s C++ curriculum.

The Exercise in Bureaucracy

The classic OOP exercise at 42 involves implementing bureaucratic paperwork: forms that must be signed, bureaucrats that must process them, and a chain of responsibility for who can sign what.

On the surface, it’s about inheritance and polymorphism. But the real lesson runs deeper.

Concrete Lessons

1. Composition over inheritance isn’t new advice

We built forms as abstract classes with concrete implementations. When an intern can process any form, that’s polymorphism. When we needed a robot that processes forms, we composed it with a form handler rather than inheriting.

The patterns we used weren’t invented — they emerged from solving the problem correctly.

2. Design patterns are named after solutions, not recipes

The Strategy pattern appeared when we needed interchangeable form processing algorithms. The Observer pattern appeared when we needed bureaucrats to notify each other of signings.

These weren’t “use the Strategy pattern here” — they were “this problem has a shape, and that shape has a name.”

3. Type safety prevents real bugs

C++ templates and strict type hierarchies caught bugs at compile time that would have been runtime disasters. The investment in proper typing paid off in fewer debugging sessions.

What 42 Got Right

The school teaches by forcing you to implement things correctly. You can’t fake a working program. The evaluator tests what actually works, not what looks right.

This produces engineers who think in terms of concrete constraints and correct implementations rather than abstract elegance.