Quick Recap: Classes

In the previous topic, classes were introduced as blueprints that describe a type of thing in your program.
A class defines which data an object will hold and which operations it can perform.

For example, a User class can define attributes like id, name, email, and methods like login() or updateProfile().
But until you actually create an User object, nothing exists in memory.

The class is just the design.
Objects are the real “living” pieces created from that design at runtime.

What Is an Object?

An object is a concrete instance created from a class.
When your program runs,s and you construct an object, memory is allocated to hold that object’s data.

For example, this:This 

  • User is the class.

  • User u1(1, "Sam", "sam@example.com", "pass"); creates an object u1 of type User.

All objects created from the same class:

  • Share the same structure (same attributes and methods).

  • Have their own independent data, stored in those attributes.

You can think of it like this:

  • Class = “Contact” template in your phone.

  • Objects = each saved contact (Sam, Riya, Daniel) with their own phone numbers and names.

In Low Level Design, you design the classes once, but at runtime, your system uses many objects to represent real users, orders, tickets, etc.

Class vs Object: Clear Distinction

Many beginners mix these two terms, so make the difference very explicit:

  • A class is a definition written once in the source code.

    • It tells the compiler which fields and methods a type will have.

  • An object is created one or many times when the program runs.

    • Each object holds its own values in those fields.

Examples in words:

  • Class: Book

    • Objects: “Clean Code”, “Design Patterns”, “LLD Handbook”, each with its own title, author, and price.

  • Class: Ticket

    • Objects: ticket #101, ticket #102, ticket #103, each with its own ID, seat, and status.

In LLD discussions, you usually say “we define these classes” and then “at runtime, many objects of these classes will exist”.

Creating Objects in C++

Assume we have this simple User class:

There are two common ways you will see objects created.

1. Objects on the Stack

This is the most common style in simple examples:

Here:

  • user1 and user2 are objects.

  • They are automatically destroyed when they go out of scope (for example, when the function ends).

You can call methods on them like this:


2. Objects on the Heap (Using new)

Sometimes you need objects that live longer or are managed via pointers:

Conceptually, both ways create objects from the same class.

The main difference is how the memory is managed, which is a deeper C++ topic.

For LLD thinking, the important part is: you use the class name and constructor to create objects that represent real entities.

Object State: Data Inside Each Object

Every object has its own state — the current values of its attributes.

With the User class:

  • user1 has id = 1, name = "Sam", email = "sam@example.com", etc.

  • user2 has id = 2, name = "Riya", email = "riya@example.com", etc.

These values are stored separately.
Changing user1The data does not affect. user2.

If we add methods that can change state:

Then:

States change per object, not per class.

Multiple Objects from the Same Class

One advantage of good LLD is that a single class design can serve many objects.

Imagine a Customer class:

You can create multiple customers easily:

In LLD problems:

  • A parking system will have many ParkingSlot objects.

  • A ticketing system will have many Ticket objects.

  • A game might have many Player or Enemy objects.

You design the class once, then the program instantiates as many objects as needed at runtime.

Practical Example: Objects Working Together

Let’s use a different, simple domain: a movie ticket booking scenario.

Entities:

  • Viewer – the person watching the movie.

  • Ticket – represents one booked seat for a movie show.

Viewer Class

Ticket Class

Creating and Using Objects

What’s happening here:

  • v1 is a Viewer object.

  • t1 is a Ticket object that contains a Viewer object.

  • Methods on t1 use data from v1 (like the viewer’s name).

  • The status inside t1 changes when it cancel() is called.

This is exactly how LLD systems are built: many objects collaborating to represent real actions.

Object Lifetime and Scope

Understanding when objects are created and destroyed helps you reason about your design.

  • Objects created on the stack (like Viewer v1(...)) live until the end of the block or function.

  • Objects created with new live until you call delete on them.

Example with scope:

For LLD interviews, you usually mention object creation briefly, then focus more on what the objects represent and how they interact, rather than low-level memory details.

Common Mistakes with Objects

Some typical mistakes when learning about objects are:

  • Confusing class and object vocabulary.

    • Saying “I created a class” when you actually instantiated an object.

    • Better: “I defined a class” vs “I created an object of that class”.

  • Forgetting that each object has its own state.

    • Changing one object’s data does not affect another object of the same class.

  • Creating objects in an invalid state.

    • For example, missing required data in constructors.

    • Good LLD tries to ensure that every object is valid immediately after creation.

  • Not thinking about how many objects will exist.

    • Designing as if only one user, one order, or one ticket exists, when in reality there will be many.

Recognizing these issues early helps you build more realistic and robust designs.

Summary

Objects are concrete instances created from classes when the program runs.
They hold their own data in attributes and expose behavior through methods, and many objects can be created from a single class definition.

In this article, you saw:

  • The precise difference between classes and objects.

  • How to create objects in C++ using constructors.

  • How the object state is stored and changes over time.

  • How multiple objects work together in a small movie ticket booking example.

  • Common mistakes beginners make when dealing with objects.