DEV Community: Anubhav Gupta

Getters and Setters Are Not Encapsulation — Here’s What Encapsulation Actually Means

Anubhav Gupta — Thu, 27 Aug 2026 11:22:02 +0000

When we first learn Object-Oriented Programming, encapsulation is often explained like this:

Make fields private and access them using getters and setters.

Technically, this introduces data hiding, but it does not automatically give us good encapsulation.

There is an important difference.

class BankAccount {

    private double balance;

    public double getBalance() {
        return balance;
    }

    public void setBalance(double balance) {
        this.balance = balance;
    }
}

At first glance, this looks perfectly encapsulated.

The field is private.

Nobody can directly write:

account.balance = 1000;

Instead, they have to call:

account.setBalance(1000);

But ask yourself one question:

What exactly did we protect?

Not much.

A caller can still do this:

account.setBalance(-50000);

or:

account.setBalance(999999999);

The field is private, but the object's internal state is still completely controlled by the outside world.

That is not strong encapsulation.

What Encapsulation Actually Means

Encapsulation is not just about restricting how a variable is accessed.

It is about restricting how an object's state can change.

A well-encapsulated object should:

protect its internal state
enforce business rules
maintain valid state
expose meaningful operations
hide unnecessary implementation details

The object itself should decide which state transitions are allowed.

This leads to an important concept:

Invariants

An invariant is a condition that should always remain true for an object.

For example, suppose our banking system does not allow a balance to become negative.

Then:

balance >= 0

is an invariant.

If we expose a generic setter:

setBalance(double balance)

we are allowing outside code to break that invariant.

Instead of exposing the state directly, we should expose behavior.

A Better Design

Consider this version:

class BankAccount {

    private double balance;

    public BankAccount(double initialBalance) {

        if (initialBalance < 0) {
            throw new IllegalArgumentException(
                "Initial balance cannot be negative"
            );
        }

        this.balance = initialBalance;
    }

    public double getBalance() {
        return balance;
    }

    public void deposit(double amount) {

        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Deposit amount must be positive"
            );
        }

        balance += amount;
    }

    public void withdraw(double amount) {

        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Withdrawal amount must be positive"
            );
        }

        if (amount > balance) {
            throw new IllegalStateException(
                "Insufficient balance"
            );
        }

        balance -= amount;
    }
}

Notice something important.

There is no setBalance() method.

Instead, the object exposes operations that make sense in its domain:

deposit()
withdraw()
getBalance()

Now someone cannot arbitrarily change:

1000 -> 500000

by calling:

setBalance(500000);

They have to perform a legitimate operation.

account.deposit(500);

This is much closer to real encapsulation.

Data Hiding vs Encapsulation

These two concepts are related, but they are not identical.

Data Hiding

Data hiding restricts direct access to internal data.

For example:

private double balance;

Outside code cannot directly access the variable.

That's useful.

But encapsulation goes further.

Encapsulation

Encapsulation combines state and behavior while controlling the way the state can change.

Instead of asking:

"Can external code access this variable?"

we should ask:

"Can external code put this object into an invalid state?"

That question gives us a much better understanding of encapsulation.

Another Example: User Age

Consider:

class User {

    private int age;

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

We technically have a private variable.

But this is possible:

user.setAge(-25);

Now our object contains an invalid state.

We could add validation:

public void setAge(int age) {

    if (age < 0) {
        throw new IllegalArgumentException(
            "Age cannot be negative"
        );
    }

    this.age = age;
}

This is already better.

But sometimes even the existence of a setter should be questioned.

Imagine age is calculated from date of birth.

In that case, there should probably be no:

setAge()

at all.

Instead:

class User {

    private LocalDate dateOfBirth;

    public User(LocalDate dateOfBirth) {
        this.dateOfBirth = dateOfBirth;
    }

    public int getAge() {
        return Period.between(
            dateOfBirth,
            LocalDate.now()
        ).getYears();
    }
}

Now age cannot accidentally become inconsistent with dateOfBirth.

The object's design prevents the invalid state from existing.

That is powerful encapsulation.

Tell, Don't Ask

There is another useful object-oriented design principle related to this discussion:

Tell, Don't Ask.

Instead of extracting an object's data, making decisions outside the object, and then setting the state again, tell the object what you want it to do.

Consider:

if (account.getBalance() >= amount) {
    account.setBalance(
        account.getBalance() - amount
    );
}

Here, the caller knows:

how the balance is stored
how withdrawal works
what validation is required
how the state should change

That logic belongs to the BankAccount.

A better approach is:

account.withdraw(amount);

Now the object owns the behavior.

The caller does not need to understand the object's internal rules.

Why Generic Setters Can Be Dangerous

Imagine a class with ten fields:

class Order {

    private String status;
    private double total;
    private boolean paid;
    private LocalDateTime shippedAt;
}

Now imagine automatically generating setters for everything:

setStatus()
setTotal()
setPaid()
setShippedAt()

External code could create combinations like:

status = SHIPPED
paid = false
shippedAt = null

The individual values may be legal.

But together they represent an invalid Order.

This is why encapsulation is not just about validating individual variables.

Sometimes we need to protect the relationship between multiple variables.

Instead, our API might expose:

order.markAsPaid();

order.ship();

Inside ship():

public void ship() {

    if (!paid) {
        throw new IllegalStateException(
            "An unpaid order cannot be shipped"
        );
    }

    this.status = "SHIPPED";
    this.shippedAt = LocalDateTime.now();
}

Now the class protects its own rules.

The Order object becomes responsible for maintaining a valid order state.

Encapsulation Reduces Coupling

Good encapsulation has another major benefit:

implementation details can change without breaking callers.

Suppose today we store:

private double balance;

Later, because financial calculations should avoid floating-point precision issues, we replace it with:

private BigDecimal balance;

If the rest of our application directly depends on how balance works, the change could spread everywhere.

But if callers simply use:

account.deposit(amount);
account.withdraw(amount);

the internal implementation can evolve independently.

That is one of the biggest advantages of encapsulation:

Objects expose stable behavior while hiding implementation decisions.

Should We Never Use Setters?

No.

Setters themselves are not bad.

The problem is automatically generating setters for every field without thinking about the object's rules.

A setter can be perfectly valid:

public void setDisplayName(String displayName) {

    if (displayName == null || displayName.isBlank()) {
        throw new IllegalArgumentException();
    }

    this.displayName = displayName;
}

If changing a display name is a legitimate operation in the domain, this design is fine.

The important question is not:

"Should this field have a setter?"

The better question is:

"Should external code be allowed to change this value directly?"

Sometimes the answer is yes.

Sometimes the answer is no.

Encapsulation Is About Designing an API

One useful way to think about a class is:

Every public method becomes part of the API of that object.

For example:

setBalance()

essentially says:

You are allowed to replace the balance with any value.

While:

deposit()
withdraw()

say:

You can request legitimate banking operations, but the account controls how its state changes.

That difference may look small in code.

Architecturally, it is huge.

A Simple Rule I Use

Before adding a setter, ask:

"Am I exposing state, or am I exposing behavior?"

Instead of:

order.setStatus("SHIPPED");

consider:

order.ship();

Instead of:

account.setBalance(balance - 500);

consider:

account.withdraw(500);

Instead of:

user.setVerified(true);

consider:

user.verify();

The second approach usually produces objects that are easier to understand, harder to misuse, and safer to modify.

Final Thought

private fields and getters/setters are language mechanisms.

Encapsulation is a design principle.

You can have:

private fields
+ getters
+ setters

and still have a poorly encapsulated class.

Good encapsulation means that an object:

owns its state
protects its invariants
exposes meaningful behavior
prevents invalid transitions
hides implementation details from callers

So next time your IDE offers:

Generate Getters and Setters

don't automatically click:

Select All.

First ask:

What should this object actually allow the outside world to do?

That is where encapsulation really begins.

The Hidden Cost of AI: Moving from Tutorial Code to Production Code

Anubhav Gupta — Mon, 22 Jun 2026 16:15:00 +0000

If you've watched a web development tutorial in the last year, chances are you've seen someone build an "AI-powered" app. The instructor pastes their OpenAI API key into an environment file, writes a simple fetch request, and within 10 minutes, the app is magically generating text.

It looks incredibly easy. So, you build your own version. It works perfectly on localhost:3000. You're ready to deploy and share it with the world.

Then, the panic sets in.

What happens if someone shares your link on Reddit? What if a user absentmindedly clicks the "Generate" button 50 times? What if a malicious bot finds your open endpoint?

Because AI APIs charge by the "token" (the amount of text processed), an unprotected endpoint isn't just a bug—it's a financial liability.

Here is what tutorials don't tell you, and how I had to adapt my backend architecture to safely deploy AI features.

The Problem: The Unprotected Wrapper
The standard tutorial implementation is essentially an unprotected wrapper. Your frontend talks to your Next.js/Node.js backend, and your backend blindly forwards the request to the LLM.

// ❌ The Tutorial Way (Dangerous in Production)
export async function POST(req) {
  const { prompt } = await req.json();

  // Blindly forwarding the request and paying for it
  const response = await openai.chat.completions.create({
    model: "gpt-4",
    messages: [{ role: "user", content: prompt }],
  });

  return Response.json(response.choices[0].message);
}

The Solution: Building a Defense Layer
To move this to production, I had to stop treating the AI API like a standard database query and start treating it like a precious resource. Here are the three pillars of production AI architecture I implemented.

1. Strict Rate Limiting
Before a request even touches the logic of my application, it has to pass a rate limiter. Using a tool like Redis (or Upstash), you can track how many requests a specific IP address or User ID has made in a given window.

If a user tries to generate 10 responses in 10 seconds, the server throws a 429 Too Many Requests error and refuses to talk to the AI. This instantly stops bots and button-mashers.

2. Token Tracking and Quotas
Rate limiting protects against bursts, but what about a user who slowly drains your API credits over a month?

To solve this, I had to update my database schema to include a tokens_used column for every user. Every time a successful AI request completes, the API returns a usage object. I extract the total_tokens from that object and add it to the user's profile in my database.

If their usage exceeds their tier (e.g., free tier vs. premium), they are locked out until they upgrade or the month resets.

3. Caching (Don't Pay for the Same Answer Twice)
This was the biggest "Aha!" moment. Why should I pay the AI to answer "How do I reverse a string in Python?" if another user asked the exact same question yesterday?

By implementing a caching layer (saving the Prompt and the AI's Response to my own database), I can check the database first. If the answer exists, I serve it instantly for free. If it doesn't, only then do I query the AI.

Your 5-line tutorial endpoint suddenly turns into this:

// ✅ The Production Way (Pseudocode)
export async function POST(req) {
  const user = await authenticateUser(req);
  const { prompt } = await req.json();

  // 1. Rate Limiting Check
  if (await isRateLimited(user.id)) return Error("Too many requests");

  // 2. Quota Check
  if (user.tokens_used > MAX_LIMIT) return Error("Upgrade your plan");

  // 3. Cache Check
  const cachedResponse = await checkDatabaseCache(prompt);
  if (cachedResponse) return Response.json(cachedResponse);

  // 4. The actual AI call
  const response = await openai.chat.completions.create({...});

  // 5. Save usage and cache the response
  await saveToCache(prompt, response);
  await updateUserTokens(user.id, response.usage.total_tokens);

  return Response.json(response);
}

The Takeaway
Integrating an AI API is the easiest part of building an AI application. The real engineering challenge lies in building the infrastructure around it—protecting your endpoints, managing costs, and optimizing performance.

Are you building an AI-powered app? What strategies are you using to manage API costs and prevent abuse? Let me know in the comments!

The Hidden Trap in Backend Tutorials: Why Your Webhooks Are Creating Duplicate Data (And How to Fix It)

Anubhav Gupta — Sat, 20 Jun 2026 05:19:25 +0000

We've all been there. You're sitting at your desk late at night, watching a backend tutorial, fueled by coffee and determination. The instructor shows you how to integrate a payment gateway or a webhook, and it looks incredibly simple:

Receive the webhook event.
Update the database.
Return a 200 OK.

You write the code, test it locally, and it works perfectly. You push it to production feeling like a senior engineer.

But a few days later, you check your database and notice something terrifying: Duplicate records. Users are being credited twice, or identical data entries are piling up.

Welcome to the real world of backend engineering, where the "Happy Path" is a myth, and network reliability is a lie.

Here is what went wrong, and the crucial concept of Idempotency that tutorials often skip.

The Problem : The Unreliable Network
In a perfect world, when an external service (like Stripe, GitHub, or Razorpay) sends a webhook to your server, your server processes it instantly and fires back a 200 OK to say, "Got it, thanks!"

But networks are inherently flaky. Sometimes, your server takes too long to process the data. Other times, a DNS hiccup drops your 200 OK response before it reaches the external service.

When the external service doesn't get your confirmation in time, it assumes the event was lost. So, what does it do? It retries. It fires the exact same webhook event again a few seconds (or minutes) later.

If your code blindly accepts data and inserts it into the database, you've just processed the same event twice.

The "Aha!" Moment: Enter Idempotency
To fix this, we need to design our API to be Idempotent.

Idempotency is a fancy mathematical term that simply means: Making multiple identical requests has the same effect as making a single request.

Think of it like an elevator button. Pressing the "Floor 5" button once tells the elevator to go to floor 5. Smashing the "Floor 5" button ten times in a row doesn't make the elevator go to floor 50. The end result is exactly the same.

Your webhook endpoint needs to act like that elevator button.

How to Implement an Idempotent Webhook
To stop duplicate data, you need to turn your server into a bouncer. Before letting any data in, it needs to check the guest list.

Here is the step-by-step logic to fix the issue:

1. Find the Unique Identifier
Every well-designed webhook payload contains a unique ID for that specific event (e.g., event_id or stripe_signature). This is your golden ticket.

2. Check the Database Before Processing
When the webhook hits your server, do not process the business logic immediately. First, query your database to see if you have already processed this event_id.

3. Handle the Duplicate Gracefully
If the event_id exists, it means this is a network retry. Your server should safely ignore the payload and immediately return a 200 OK to satisfy the external service.

If the event_id does not exist, process the data, save the event_id to your database, and return the 200 OK.

The Code Example (Node.js / Express)
Here is what that mental shift looks like in code:

app.post('/webhook', async (req, res) => {
  const eventId = req.body.event_id;
  const payloadData = req.body.data;

  try {
    // 1. Check if we've already processed this event
    const existingEvent = await db.processedEvents.findUnique({
      where: { id: eventId }
    });

    // 2. If it exists, it's a retry! Ignore it, but send a 200 OK.
    if (existingEvent) {
      console.log(`Duplicate event ${eventId} blocked.`);
      return res.status(200).send('Event already processed');
    }

    // 3. If it's new, process the business logic safely
    await updateUserData(payloadData);

    // 4. Save the event_id so we remember it for the future
    await db.processedEvents.create({
      data: { id: eventId }
    });

    // 5. Finally, send the success response
    return res.status(200).send('Webhook received and processed');

  } catch (error) {
    console.error("Webhook processing failed", error);
    return res.status(500).send('Internal Server Error');
  }
});

The Takeaway
Tutorials are amazing for learning the syntax and the basic flow of a framework. But the transition from a "learner" to a "builder" happens the moment you start dealing with real-world edge cases.

Building systems that work when everything goes perfectly is easy. Engineering systems that gracefully handle failure, retries, and latency is the real challenge and the real fun.

Have you ever had a network retry cause havoc in your database? How do you handle idempotency in your own APIs? Let me know in the comments below!