Teaching object-oriented programming to second-year students

Object-oriented programming is the first place many second-year students hit a wall. They have just spent a year getting comfortable with variables and loops in Programming Techniques, and now we ask them to think in objects, classes, inheritance — abstractions with no obvious referent in the code they have written so far. After three semesters teaching OOP at VNU-HCM, here is what I have learned about getting them across that wall.

Start with a problem, not a keyword

The textbook order — class, then object, then method — is the order of definitions, not the order of understanding. I now open with a messy procedural program that is clearly painful to extend, and let the students feel the pain before I offer classes as relief. The keyword class lands very differently when it answers a question they already have.

Three things that worked

• →Living examples over toy ones — a BankAccount they can break is worth ten Animal → Dog hierarchies.
• →Drawing before typing — five minutes sketching objects and their messages saves an hour of debugging.
• →Reading code, not only writing it — students who learn to read a class fluently write far better ones.

What I would change

Inheritance is taught too early and too eagerly. Most real designs lean on composition, yet our syllabus spends weeks on deep inheritance trees that students will rarely build in practice. Next semester I am cutting that down and giving the time back to encapsulation and clear interfaces — the parts that actually make code easier to live with.

You have not taught OOP until a student refactors their own code and says, unprompted, “this is cleaner now.”