Design the Classes
By the end of this lesson, you'll be able to:
- Identify the "things" in a problem domain that deserve their own class
- Sketch class responsibilities before writing implementation code
- Explain why designing on paper first avoids costly rework
Prerequisites: Module 11: "Object-Oriented Programming Principles"
What we're building
Over this module you'll build a small student management system that:
- Models a
Studentwith their own data. - Models a
CourseRosterthat tracks which students are enrolled in a course. - Enforces business rules (like a maximum roster size).
- Handles errors gracefully (like enrolling the same student twice).
Each lesson builds one piece using classes, objects, and encapsulation from Modules 9-11.
Finding the classes: look for the nouns
A useful trick for identifying classes: read a plain description of the problem and underline the nouns. "A student enrolls in a course, which has a roster of enrolled students, limited to a maximum size." That sentence surfaces two clear class candidates: Student and CourseRoster. Verbs like "enrolls" hint at methods those classes will need.
Sketching responsibilities before code
Student
- holds: studentId, name, email
- responsible for: describing itself
CourseRoster
- holds: courseName, a list of enrolled Students, a maximum size
- responsible for: enrolling a student, rejecting invalid enrollments,
reporting how many seats remainWriting this out first (even just as comments, like above) means the next five lessons have a clear target — each one fills in a piece of this sketch rather than improvising as it goes.
Exercise
As comments, sketch the responsibilities of a Course class (separate from CourseRoster) that would hold a courseName and a credits value.
Show hint
What does Course hold? What is it responsible for?
Design the Classes Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Before writing any code, this lesson identifies the real-world "things" a student management system needs to model, and sketches what each class is responsible for.