How to write more stable and testable code 👉 use encapsulation

Oleksandr Tokariev — Wed, 21 Jan 2026 22:00:45 +0000

Encapsulation is often introduced as a basic OOP principle: “hide state, expose behavior.”

But its real value becomes obvious when you start writing tests — especially for domain logic.

Let’s look at a simple finance tracker example: a Wallet that holds a balance and a list of transactions.

The non-encapsulated wallet

In a non-encapsulated design, the wallet is just a data holder. The business rules live elsewhere — for example, in a WalletRepository.

Tests look reasonable at first:

adding INCOME(500) increases the balance
adding INCOME(0) throws an exception
adding an expense larger than the balance is rejected

These tests pass, and everything seems fine.

But there’s a hidden assumption: all callers must always go through the repository.

The moment a caller bypasses it, the model breaks:

anyone can append directly to wallet.transactions
anyone can set wallet.balanceCents = -50

The wallet can no longer defend its own invariants.

Tests don’t verify the domain — they verify “correct usage” by convention.

This is the real cost of missing encapsulation.

The encapsulated wallet

In the encapsulated version, the rules move into the Wallet itself.

The wallet:

keeps its state private
exposes read-only views (List<Transaction>)
provides a single domain operation (wallet.add(tx))

Now the tests change in an important way. They no longer care who calls the wallet — only what happens when valid or invalid transactions are applied.

Invalid inputs are rejected at the boundary.

Impossible states cannot be constructed.

Bypassing the rules is no longer an option.

The key difference is not the if statements — it’s where they live.

Why this matters

Encapsulation turns your domain objects into the authority over their own correctness.

As a result:

tests become simpler and more meaningful
refactors break fewer tests
invariants are enforced consistently, everywhere

Encapsulation isn’t just about clean design.

It’s a way to make your tests trustworthy — and your domain harder to misuse.

1 year of using AI tools in enterprise apps — here’s what I learned

Oleksandr Tokariev — Tue, 13 Jan 2026 20:52:12 +0000

I build enterprise POS Android apps — lots of architecture, lots of business rules, and plenty of “this has to be correct.” 🧱

My AI journey started in a pretty normal place: using ChatGPT to reason through tricky architecture decisions and scaffold the boring-but-necessary code.

Then it escalated fast. 🚀

Once tools like Cursor made “chat-to-code” feel native inside the editor, I noticed a shift. I stopped creating classes manually and started directing how they should be created. Cursor’s agent-style workflows are built to take broader tasks, plan ahead, edit across files, and even run commands — a move from autocomplete to execution.

What I do differently now 👇

📚I don’t anymore write files and classes, I write TDD for AI model.
🧠 I think in systems, not snippets When code generation gets cheap, architecture decisions get expensive. I spend more time on patterns, boundaries, and long-term maintainability than on low-level syntax.
👀 I review everything AI moves fast — and it can be confidently wrong. Reading “foreign code” is now a core skill, not a nice-to-have.
📚 Docs are part of the toolchain Strong README files and a /docs folder keep the model grounded in the application’s business logic.
🧪 Tests protect me from becoming a human linter I lean on TDD and automated tests to shorten feedback loops and avoid spending my day QA’ing AI output.
🧹 I treat AI output like real work in Git Frequent commits, then rebase/squash. Clean history still matters.