The Hidden Cost of Interface Changes
In software architecture, one of the most subtle forms of technical debt comes not from what we write - but from what we expose.
It often starts with a small, well-meaning change: we want to add access to a private field or internal method of an important class. But we only need that access in one very specific client - a test, a legacy integration, a specialized handler. And so we think: maybe we should just extend the interface a little?
But this decision, while easy to justify in the moment, has long-lasting consequences. Every extension to an interface creates a new public contract. And public contracts are sticky. Other developers start to rely on it. The internal detail becomes external behavior. You’ve added surface area - and lost encapsulation.
This article explores a practical architectural technique to solve such cases elegantly: using closures to provide internal access without exposing internal state, and without bloating your interface. We’ll walk through the problem, naive solutions, and then land on a design pattern that preserves encapsulation, keeps dependencies clean, and minimizes ripple effects in your codebase.
Let’s dive in.
The Problem: One Class, One Secret, One Needy Client
Imagine you’re working with a critical class in your codebase - let’s call it ImportantService. It’s well-designed, well-tested, and widely used across the system. Somewhere deep inside, it holds a private detail - say, a cache map or a connection state - that is intentionally hidden from the outside world.
Now suppose you have a very specific client - maybe a migration job, a diagnostic tool, or an adapter - that needs to interact with that internal detail just once, in one specific place. It doesn’t need full control over the class. It doesn’t even need to know how the field works. It just needs to use it once, responsibly.
But there’s a problem: that field isn’t accessible. The only way to reach it is by modifying ImportantService’s public interface. And that feels wrong.
You hesitate, and rightfully so. Because modifying a public interface means opening a door that was previously closed. And once that door is open, it rarely gets closed again. Even if your intention was to use it just once, you can’t stop other parts of the codebase from wandering through it later.
So you’re stuck:
- You don’t want to break encapsulation.
- You do need access in one place.
- And you’re not sure how to solve this cleanly.
That’s the problem we’re going to tackle.
Naïve Solution: Just Expose the Field
The most straightforward way to solve this is deceptively simple:
Just add a new method to the public interface.
For example, you might write:
class ImportantService {
private val cache = mutableMapOf<String, String>()
fun getCache(): MutableMap<String, String> {
return cache
}
}
Now your client can interact with the internal cache freely. Problem solved?
Not quite.
You’ve just violated the principle of encapsulation - and done so permanently. What was once an implementation detail is now a public API. Even if your intention was to use this method in only one place, you’ve effectively told every other developer:
“Hey, feel free to reach into this internal structure whenever you like.”
This creates three major problems:
- Fragility - The internal structure can no longer change freely. If you swap cache for a different mechanism later, you’ll break all clients relying on getCache().
- Misuse Risk - Other parts of the codebase might start using the exposed method in ways you didn’t anticipate - maybe even mutating shared state.
- Interface Pollution - The class’s public interface becomes bloated with methods that serve niche needs, making it harder to understand and harder to maintain.
This approach works in the short term but almost always causes regret later. It’s a technical shortcut with long-term cost.
And most importantly: it introduces a contract where none was meant to exist. The moment you expose something, you own it - forever.
Better But Clumsy: Interface Splitting and Casting
If exposing a private field directly is too risky, a slightly better solution might be to split the interface. That is, define two interfaces:
- A public interface that contains only the safe, general-purpose methods used by the majority of the system.
- A specialized interface that includes access to the internal detail - used only where truly needed.
It could look like this:
interface PublicAPI {
fun doSomething()
}
interface InternalAPI : PublicAPI {
fun getCache(): MutableMap<String, String>
}
class ImportantService : InternalAPI {
private val cache = mutableMapOf<String, String>()
override fun doSomething() {
// ...
}
override fun getCache(): MutableMap<String, String> = cache
}
In your codebase, you expose ImportantService only as PublicAPI. But in the one place that needs getCache(), you can do a cast:
val service: PublicAPI = getImportantService()
val internal = service as? InternalAPI
internal?.getCache()?.put("debug", "value")
This approach does preserve encapsulation to an extent - the getCache() method isn’t visible unless you explicitly cast to InternalAPI.
But it comes with its own set of problems:
- Unsafe Type Casting - Even though you “know” the type at runtime, you’re opting out of compile-time safety. That’s a slippery slope and a code smell in most modern systems.
- Leaky Abstractions - You’ve now introduced multiple views of the same object. If other developers find and misuse the InternalAPI, you’re back to polluting your architecture.
- Refactoring Overhead - You’ve complicated your class hierarchy and added extra interfaces to maintain, all to solve a one-off case.
In theory, interface segregation is a clean architectural practice. But in this scenario - where the need is rare, isolated, and very specific - it can feel like overkill. Worse, the as? cast becomes a tacit admission:
“We broke the type system a little, but it’s probably fine.”
There must be a better way.
If you’re enjoying this so far, there’s a lot more in
Elegant Trick: Using Closures to Encapsulate Access
Instead of modifying the interface or relying on unsafe casts, we can flip the problem:
What if we don’t expose the internal detail, but instead expose a controlled interaction with it?
This is where closures (or lambdas) come in.
Rather than letting the client access the internal field, we let the internal field access the client logic - but only in a very narrow and safe way.
Let’s take the same ImportantService, but this time, we give it a method that accepts a function:
class ImportantService {
private val cache = mutableMapOf<String, String>()
fun <R> withCache(action: (MutableMap<String, String>) -> R): R {
return action(cache)
}
}
Now in the client:
val service = ImportantService()
service.withCache { cache ->
cache["debug"] = "value"
}
This looks similar to accessing the cache directly, but it’s a different animal architecturally.
Why is this better?
- Controlled Exposure The internal detail is still private. You’re only giving clients a momentary, scoped interaction with it - and only when you choose to.
- No Interface Pollution You didn’t add a new getter. You didn’t expand your public API. The class’s surface area remains tight.
- No Type Leaks No casting, no subclassing, no interface proliferation. Everything is encapsulated within the boundary of the method.
- Clear Intent By naming the method withCache, you signal that this is a controlled and intentional handoff - not an invitation to poke around.
Bonus: Functional Composition
You can combine this pattern with other functional tools - mapping, chaining, filtering - to do expressive work with internal state without ever revealing it.
This is already a much cleaner solution. But it has a hidden cost we’ll explore next - and it involves dependency direction.
But Wait: Inverted Dependencies
At first glance, the closure-based approach seems perfect: it keeps your internal field private, avoids interface pollution, and provides clients with just enough power to get their job done.
But there’s a subtle shift happening here - one that could quietly violate a key architectural principle: dependency direction.
Let’s look again at the method:
fun <R> withCache(action: (MutableMap<String, String>) -> R): R {
return action(cache)
}
Who’s in control here?
The client defines the action, i.e. the logic that operates on the cache.
The ImportantService receives and executes that logic.
This means the core class - the thing we want to keep stable and authoritative - is now depending on a function provided by an external client.
That’s an inversion of control. And not the good kind.
In traditional architecture, the stable component should not depend on the volatile one. That’s the essence of the Stable Dependencies Principle. And here, we just flipped that - the ImportantService now calls out to a client-defined function.
Why is that a problem?
- Hidden Coupling - Now the core class indirectly relies on logic defined elsewhere. This creates temporal and behavioral coupling that’s hard to trace.
- Change Fragility - If the client’s closure changes in a way that breaks assumptions, it can affect the core class, even if its own code hasn’t changed.
- Harder to Test in Isolation - Testing the core class now requires mocking or simulating the injected closure logic, which might not be desirable.
So while closures give us encapsulation, they come at the cost of reversing the dependency graph.
To keep things clean, we need to restore the direction - without losing the flexibility. And that’s exactly what we’ll tackle next.
The Final Abstraction: A Dedicated Closure Carrier
To resolve the dependency inversion without giving up the elegance of closures, we introduce a new architectural element:
a small, dedicated abstraction that acts as a neutral carrier of logic.
Instead of passing the closure from the client directly into the ImportantService, we wrap that logic inside a purpose-built object - let’s call it CacheAction.
fun interface CacheAction<R> {
fun execute(cache: MutableMap<String, String>): R
}
This interface does one thing: defines a contract for interacting with the internal cache. It is not the client, and it is not the service - it’s an abstraction between them.
Now, the ImportantService depends on CacheAction, not on an arbitrary client-provided lambda:
class ImportantService {
private val cache = mutableMapOf<String, String>()
fun <R> perform(action: CacheAction<R>): R {
return action.execute(cache)
}
}
And on the client side:
val action = CacheAction<String> { cache ->
cache["debug"] = "value"
"done"
}
val result = service.perform(action)
Why is this better?
- Dependency Flow is Restored The service depends only on the abstraction (CacheAction), which is stable and controlled. It doesn’t care where the implementation comes from.
- Encapsulation is Preserved The cache is still private. No getters, no leaks.
- Interface is Clean and Intention-Revealing The method name perform + the typed parameter make the intent explicit: you’re performing an action on behalf of the service, using its private parts.
- Testability is Improved You can now test ImportantService with stub CacheActions, or test different CacheAction implementations independently.
- Optional Reuse and Registry In larger systems, you can even register reusable CacheActions - or compose them - giving you plugin-like extensibility without ever exposing internals.
This pattern gives you the power of closures, the safety of clean dependencies, and the expressiveness of functional composition - all while keeping your architecture tidy.
We’ve now solved the original problem without polluting the interface, without unsafe casts, and without inverting control in the wrong direction.
Let’s wrap it up.
Summary: Extend Without Breaking
Let’s recap the journey. We started with a simple but frustrating problem:
How do you give a specific client access to a private part of a class without compromising the design of the system?
We explored several options:
- Exposing a getter - quick but harmful. It breaks encapsulation and pollutes the interface.
- Splitting interfaces and casting - safer in theory, but clunky and error-prone in practice.
- Using closures - elegant and concise, but introduces inverted dependencies.
- Introducing a dedicated abstraction - the best of all worlds: encapsulated behavior, clean dependency flow, and composability.
When to use this pattern
This isn’t a tool for every situation. But it’s a great fit when:
- You need to access internal state in a very limited scope.
- You want to avoid expanding the public API.
- You care about preserving architectural boundaries and avoiding coupling.
- You prefer explicit contracts over ad hoc conventions.
It’s especially useful in large codebases or long-lived systems, where interface cleanliness and dependency direction have real consequences.
Closing thought
Architecture is about trade-offs. But sometimes, with a bit of creativity, we can have our cake and eat it too - extending functionality without breaking design, hiding complexity without losing power, and building systems that are both flexible and principled.
Closures, when used thoughtfully, are one of those quiet superpowers.
