OOP - lesson 1 | HackIndia Skills

Start from behaviour

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.

Your to-do

Find your objects

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.

Write the feature in one sentence.
Underline the nouns that belong to the problem, not the app UI.
Circle the verbs that change something or calculate something.
Group each verb with the object that should own that work.
Remove objects that are only storage, screens, buttons, or database tables.

0 of 5 done

Example

Worked example

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 table

Common mistake

Beginners 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.

Tip

Use AI carefully

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 week

What good looks like

Your 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.