OOP
OOP starts with a feature, not with a class list. First ask: what real things take part in this feature, and what work does each thing do?
A recruiter will not be impressed by a random Student class with getters and setters. They want to see code that solves a small real problem clearly.
Pick a feature you can explain in one line. For example: split a canteen bill, book a lab slot, track hostel laundry, or manage club event registrations.
0 of 7 lessons done · proved by a submitted project with a public repository
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Feature: students split a chai and snacks bill after a club meeting.
Useful objects are Bill, BillItem, Member, and Split. The button called Pay Now is not a domain object. A payments table is not your starting point.
Feature: Split a canteen bill between members
Objects:
- Bill: holds items and members, calculates total
- BillItem: stores name, price, quantity
- Member: stores name and amount paid
- Split: calculates what each member owes
Not objects yet:
- SplitBillScreen
- Pay Now button
- bill_items database tableBeginners often copy database tables into classes. This makes code look object-oriented, but the logic still lives outside the objects.
If your class only stores data and another file does all the work, pause. Ask which object should own that behaviour.
You can ask ChatGPT, Gemini, or Claude to suggest objects for your feature. Do not accept the first list blindly.
Check three things: are the objects from the problem, does each object have a clear responsibility, and did the AI add big-enterprise classes you do not need?
Prompt:
I am building a small OOP feature for a college project.
Feature: Split a canteen bill between 4 students.
Suggest domain objects only. Avoid UI, database, framework, and overengineered classes.
For each object, give one responsibility and 2-3 methods.
Check the answer:
- Remove Manager, Service, Controller unless you truly need them
- Keep names a non-technical user can understand
- Keep the feature small enough to build and test this weekYour first object model can be small. Three to five objects are enough for lesson 1.
Good object names make your README easier to read. If a senior can understand your feature without running the code, you are on the right track.
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Answer the quick check to finish this lesson.