Classes & Objects

A class describes a kind of thing: its data and the operations on that data. An object is one such thing, alive in memory, with its own state.

Overview

A class is a description. It names a kind of thing, lists the data each one carries (fields) and the operations it supports (methods). An object is one concrete thing built from that description. One BankAccount class can produce a million account objects; each has its own balance, and all of them share the same deposit and withdraw code.

This is where a low-level design interview starts. Before any pattern or principle, the interviewer wants to see that you can turn a sentence like 'a customer has accounts, and each account records its transactions' into a few well-named classes with clear fields, clear methods and clear ownership. Everything else on this page (inheritance, interfaces, encapsulation) is a rule about how those classes relate.

A class is the plan, an object is one thing built from it

What it is — A type: the definition of fields and methods — An instance: one value of that type
How many — Written once — Created as many times as needed
Holds — Method code, constants, class-level fields — Its own copy of each instance field
Exists — From the moment the program loads it — From construction until nothing refers to it
Example — BankAccount — Alice's checking account, balance 240.00

The symbols in front of each member are UML visibility marks, and Mermaid uses the same ones: + public, - private, # protected, ~ package. Draw them in interviews; they say who is allowed to touch what without a word of explanation.

What a class holds

A class has four kinds of members. Naming them precisely is a small thing that interviewers notice.

Instance field — each object — object — balanceCents
Instance method — each object (reads self or this) — class, shared code — withdraw(cents)
Class (static) field — the class — program — accountsOpened
Class (static) method — the class, no self — class — fromCsvRow(row)

In Java a static field lives in one fixed place in memory and every instance shares it; a static method cannot touch instance fields, because there is no instance to read them from. Python has the same split: attributes assigned in the class body are shared by every instance, and attributes assigned on self belong to one object.

How an object comes to life, and how it goes

Construction is two steps in every mainstream language, even when the syntax hides it: memory is set aside for the new object, then the constructor fills in its fields. In Python the two steps have names. new creates the instance, and init is called after that, on the new instance, before it is handed back to the caller. In Java the new keyword allocates and then runs the constructor, a method with the class's own name.

The end of an object's life is less tidy than the start. In garbage-collected languages (Python, Java, C#) an object is reclaimed some time after the last reference to it disappears. Python's docs say plainly that del is not guaranteed to run for objects that still exist when the interpreter exits. So never put must-happen cleanup (closing a file, releasing a lock) in a destructor; use an explicit close(), a with block, or weakref.finalize. C++ is the exception: an object with automatic storage is destroyed, and its destructor runs, exactly when it goes out of scope, which is why C++ code relies on destructors for cleanup (RAII).

Same object, equal objects, copied objects

Three questions that sound alike have different answers, and interview code often mixes them up.

Is it the same object? — a is b — a == b — identity: the same memory
Does it have the same value? — a == b (calls eq) — a.equals(b) — whatever the class defines
Give me another one like it — copy.copy or copy.deepcopy — copy constructor, clone, or a builder — shallow: shares nested objects; deep: copies them too

Assigning an object to a second variable copies the reference, not the object. Both names now point at the same thing, and a change through one is visible through the other. That is aliasing, and it is the root of a whole family of bugs.

What you will be able to do

Say what a class holds and what an object holds, and why one is shared and the other is not.
Turn a one-sentence requirement into classes with named fields, methods and visibility marks.
Explain what a constructor must guarantee, and why cleanup does not belong in a destructor.
Tell identity, equality and copying apart, and pick the right one in code.
Decide when a class should be an immutable value (record, frozen dataclass) and when an entity with identity.

Interview questions

What is the difference between a class and an object?
When should a member belong to the class rather than to each instance?
What must a constructor guarantee?
What happens when you assign one object variable to another?
When should a class be an immutable value instead of an entity?
Where do objects live in memory, and what does that mean for design?