Encapsulation

What Is Encapsulation?

Encapsulation means hiding the internal details of a class and exposing only a controlled interface to the outside world.
It is like a black box: you know what the box can do (its public methods), but you do not need to know how it does it internally.

In simpler words:

• The internal state of a class (its attributes) is kept hidden.

• Other parts of the system access or modify that state only through well‑defined methods on the class.

In Low Level Design, encapsulation helps you:

• Protect an object’s data from being changed in arbitrary ways.

• Control how the object changes its own state.

• Make it easier to change the internal implementation later without affecting the rest of the system.

Encapsulation is one of the four main pillars of OOP, along with abstraction, inheritance, and polymorphism.

Why Encapsulation Matters in LLD

In real systems and LLD interview problems, encapsulation has several practical benefits.

• Data safety

  • If attributes are private, no other class can directly overwrite them.

  • You reduce the chance of bugs caused by invalid or unexpected changes.

• Clear responsibilities

  • A class is responsible for its own state.

  • It provides methods that enforce rules when the state changes.

• Easier evolution

  • You can change how the data is stored or computed without changing the public methods.

  • As long as the interface (method signatures) remains the same, the rest of the system is unaffected.

• Better testability and maintainability

  • You can reason about behavior through method calls instead of direct field access.

  • You can add validation, logging, or side effects inside methods without scattering them across many places.

In interviews, showing good encapsulation (hiding data, using methods to control state) signals that you design for long‑term maintainability, not just quick code.

How to Implement Encapsulation in C++

In C++, encapsulation is achieved mainly by:

• Marking attributes as private.

• Providing public methods (sometimes protected) for controlled access.

1. Private Attributes

A class keeps its internal data in private fields:

• Outside code cannot see or change balance directly.

• Only methods inside BankAccount can read or write it.

2. Public Methods as the Interface

The class exposes behavior through public methods:

Here:

• balance and They isActive are hidden from the outside world.

• Code that uses BankAccount must call deposit, withdraw, getBalance to interact with the object.

This is encapsulation in action: the class protects its state and only allows controlled changes.

Example: Encapsulated User Class

Consider a A User class that should not allow direct access to its password or status.

Usage:

Notice:

• The The password field is private; it is never exposed directly.

• You can only check if the login succeeds, not read the stored password.

• The class controls when a user becomes inactive.

Encapsulation prevents external code from bypassing these rules.

Getters and Setters: Controlled Access

Even when you need to expose data, you can do it in a controlled way.

Getters

Getters are methods that let external code read internal state, without exposing the field directly:

Setters with Validation

Setters can add validation before changing state:

Using getters and setters, you retain encapsulation even when external code needs to read or modify some state.

Encapsulation vs “Just Make Everything Public”

A common beginner pattern is:

This is not encapsulated.

Problems with this:

• Any code can overwrite password or be overwritten isActive directly.

• Business rules (like “password cannot be empty”) are scattered or missing.

• If you later want to validate, you must change every place that touches the fields.

With encapsulation, you can:

• Add validation, logging, or notifications inside methods.

• Change how the class stores data without affecting callers.

• Keep the external interface clean and simple.

Encapsulation in LLD‑Style Problems

In LLD interview‑style problems, encapsulation appears naturally:

• Parking slot

  • A ParkingSlot class might keep its status private and only allow changes through markOccupied() and markFree().

• Order

  • An Order class might keep its status private and only allow state changes through confirm(), cancel(), refund() methods.

• Player (game or booking)

  • A Player or A Rider class might keep its points, balance, or status private and expose only increment/decrement methods.

Think of it this way:
If an entity in your problem has a “state” that can change, those changes should be controlled by methods of that entity, not by random code mutating raw fields.

Common Mistakes with Encapsulation

Some typical mistakes:

• Making all fields public “for convenience”.

  • This breaks encapsulation and makes the design fragile.

• Having public fields but still providing methods.

  • If both are exposed, other code may ignore the methods and corrupt the state.

• Not validating in setters or business methods.

  • Just exposing a setter without checking data is almost as bad as making the field public.

• Exposing implementation details (like internal helper structs or collections) directly.

  • Better to hide them and provide a clean, intentional interface.

Being strict about encapsulation from the start helps you write interview-ready, production‑style code.

Summary

Encapsulation means hiding the internal state of a class and allowing controlled access through well‑defined methods.
In C++, you achieve this by marking attributes private and providing public methods to read and modify the state.

You now understand:

• What encapsulation is and why it is important in LLD.

• How to design classes with private fields and public methods in C++.

• How getters and setters can expose data safely.

• How encapsulation improves safety, maintainability, and flexibility in real‑world examples like bank accounts, users, and tickets.

• Common mistakes to avoid when applying encapsulation.