✨ This article is part of a broader discussion in my book Safe by Design: Explorations in Software Architecture and Expressiveness. If you like it, you might enjoy the full read for free on GitHub. This article is part of a broader discussion in my book Safe by Design: Explorations in Software Architecture and Expressiveness Safe by Design: Explorations in Software Architecture and Expressiveness Safe by Design: Explorations in Software Architecture and Expressiveness . If you like it, you might enjoy the full read for free on GitHub. Introduction: Rethinking Access Control Encapsulation is one of the core pillars of object-oriented programming. It is commonly introduced through the use of access modifiers — private, protected, public, and so on — which restrict visibility of internal implementation details. Most popular object-oriented languages provide access modifiers as the default tool for enforcing encapsulation. private protected public While this approach is effective, it tends to obscure a deeper and arguably more powerful mechanism: the use of explicit interfaces or protocols. Instead of relying on visibility constraints embedded in the language syntax, we can define behavioral contracts directly and intentionally — and often with greater precision and flexibility. This article offers an alternative perspective on access control, suggesting that access modifiers are, in many cases, just a shorthand for declaring implicit interfaces. We’ll explore how switching from implicit to explicit contracts can improve modularity, enhance design clarity, and even allow us to imagine programming languages that work without private or protected at all. private protected Access Modifiers as Implicit Interfaces Access modifiers give us fine-grained control over which parts of a class are visible to the outside world. A private method is hidden from everyone except the class itself. A protected method is visible to subclasses. Package-private (in languages like Java) further narrows or expands visibility based on the module boundary. These modifiers form a visibility matrix, controlling how internal details are exposed. private protected Package-private But here’s the key observation: each combination of access levels effectively defines a contract — a set of methods that a particular group of clients is allowed to use. This is conceptually identical to an interface. contract For example, when a class exposes one method as public and keeps the rest private, it’s silently declaring, “This is the only thing you’re allowed to call.” The contract is there — it’s just invisible. public private invisible Access modifiers are, in this sense, a mechanism for declaring implicit interfaces. The problem is that they are invisible to tooling and to readers. They offer no way to reason about multiple views of the same object — something explicit interfaces handle much better. implicit The Power of Explicit Interfaces Interfaces (or protocols, depending on the language) let us define clearly what capabilities an object exposes — and to whom. Instead of burying access control inside the implementation using private or protected, we can expose different behaviors through multiple public interfaces. This makes the contract visible, composable, and testable. private protected visible composable testable Interfaces offer several advantages: Clarity: Clients only see the functionality they are supposed to use. No hidden methods leaking through reflection or subclassing.
Flexibility: Different clients can interact with the same object through different interfaces, depending on context.
Polymorphism: Explicit interfaces enable runtime substitution, mocking, and dependency inversion — all core ideas in modern software design.
Encapsulation without obscurity: By expressing visibility through interfaces rather than modifiers, we separate what is exposed from how it’s implemented. Clarity: Clients only see the functionality they are supposed to use. No hidden methods leaking through reflection or subclassing. Clarity Flexibility: Different clients can interact with the same object through different interfaces, depending on context. Flexibility Polymorphism: Explicit interfaces enable runtime substitution, mocking, and dependency inversion — all core ideas in modern software design. Polymorphism Encapsulation without obscurity: By expressing visibility through interfaces rather than modifiers, we separate what is exposed from how it’s implemented. Encapsulation without obscurity what how In effect, interfaces give us a more declarative, higher-level alternative to access modifiers. And unlike modifiers, interfaces scale well in large codebases, across modules, teams, and versions. 📘 If you’re enjoying this so far, there’s a lot more in the book — same tone, just deeper. It’s right here if you want to peek. If you’re enjoying this so far, there’s a lot more in the book — same tone, just deeper. It’s right here here if you want to peek. A Concrete Example Let’s take a simple class that uses traditional access modifiers to hide internal details: public class ConsistentObject {
    public void methodA() { /* ... */ }
    protected void methodB() { /* ... */ }
    void methodC() { /* ... */ } // package-private
    private void methodD() { /* ... */ }
} public class ConsistentObject {
    public void methodA() { /* ... */ }
    protected void methodB() { /* ... */ }
    void methodC() { /* ... */ } // package-private
    private void methodD() { /* ... */ }
} This class defines different visibility levels using Java’s modifiers. But what if we rewrote the same intent using interfaces? public interface IPublicConsistentObject {
    void methodA();
}
public interface IProtectedConsistentObject extends IPublicConsistentObject {
    void methodB();
}
public interface IDefaultConsistentObject extends IProtectedConsistentObject {
    void methodC();
}
class ConsistentObject implements IDefaultConsistentObject {
    public void methodA() { /* ... */ }
    public void methodB() { /* ... */ }
    public void methodC() { /* ... */ }
    public void methodD() { /* ... */ }
} public interface IPublicConsistentObject {
    void methodA();
}
public interface IProtectedConsistentObject extends IPublicConsistentObject {
    void methodB();
}
public interface IDefaultConsistentObject extends IProtectedConsistentObject {
    void methodC();
}
class ConsistentObject implements IDefaultConsistentObject {
    public void methodA() { /* ... */ }
    public void methodB() { /* ... */ }
    public void methodC() { /* ... */ }
    public void methodD() { /* ... */ }
} Here, each interface builds on the previous one, modeling increasingly privileged access. The important difference is that now the contracts are explicit and reusable. Instead of relying on compiler-enforced visibility, we guide client interaction by choosing which interface to provide. explicit and reusable A consumer of this class might only receive a reference of type IPublicConsistentObject, and therefore would only see methodA() — even though the underlying object knows how to do more. IPublicConsistentObject methodA() This model makes dependencies more honest and design more modular. The Limitation: Constructors and Instantiation There’s one area where access modifiers still feel necessary: controlling object creation. controlling object creation Constructors can’t be abstracted as easily as methods. You can’t define a constructor in an interface, and you can’t delegate instantiation to a consumer the same way you do method calls. That’s why private constructors (and protected ones, in some cases) remain common — especially when enforcing factory patterns, singletons, or internal lifecycle rules. private protected But even this limitation is manageable. If we embrace factory functions or dependency injection, we decouple creation from usage: factory functions dependency injection interface PublicAPI {
    fun doStuff()
}
private class InternalImplementation : PublicAPI {
    override fun doStuff() { /* ... */ }
}
fun createInstance(): PublicAPI {
    return InternalImplementation()
} interface PublicAPI {
    fun doStuff()
}
private class InternalImplementation : PublicAPI {
    override fun doStuff() { /* ... */ }
}
fun createInstance(): PublicAPI {
    return InternalImplementation()
} In this model, the internal class remains private, and the only way to obtain it is through the createInstance() factory. Clients never need to know — or care — how it was constructed. private createInstance() This approach makes the object lifecycle part of the module’s explicit API. It also aligns naturally with principles like Inversion of Control, and is widely used in dependency-injection frameworks. Inversion of Control In short, we don’t need private constructors. We just need to move the responsibility of creation one level higher. private Conclusion: In Defense of Public Everything Access modifiers have long been seen as essential to safe and clean code. But they’re ultimately a low-level mechanism for expressing high-level ideas — contracts, roles, and boundaries. low-level mechanism By shifting from implicit contracts enforced through visibility, to explicit contracts expressed via interfaces and factory functions, we unlock several benefits: implicit contracts explicit contracts Clearer APIs
Greater flexibility across modules
Better separation of concerns
Easier testing, mocking, and substitution Clearer APIs Greater flexibility across modules Better separation of concerns Easier testing, mocking, and substitution This doesn’t mean private and protected are inherently bad. But they’re a shortcut — a legacy of language design choices made before interface-based composition became mainstream. private protected We can imagine a language that omits access modifiers entirely and instead relies on structured APIs to express visibility. In that world, encapsulation would still be possible — arguably even more robust — because everything would be explicit, composable, and visible by design. And maybe that’s a world worth building toward. If you enjoyed this article, you might like my book Safe by Design: Explorations in Software Architecture and Expressiveness. It dives deeper into topics like this one — contracts, type safety, architectural clarity, and the philosophy behind better code. Safe by Design: Explorations in Software Architecture and Expressiveness Safe by Design: Explorations in Software Architecture and Expressiveness Safe by Design: Explorations in Software Architecture and Expressiveness 👉 Check it out on GitHub GitHub

Public

GitHub

Rethinking Encapsulation: From Private to Public by Design

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Designing a Flexible Ability System in Games Using the Chain of Responsibility Pattern

10 Lessons from 10 Years of AWS (part 1)

10 Lessons from 10 Years of AWS (part 2)

111 Stories To Learn About Architecture

13 Expert Tips to Improve Your Web Application Performance Today

4 Skills You Need to Become a Distinguished Developer

Designing a Flexible Ability System in Games Using the Chain of Responsibility Pattern

10 Lessons from 10 Years of AWS (part 1)

10 Lessons from 10 Years of AWS (part 2)

111 Stories To Learn About Architecture

13 Expert Tips to Improve Your Web Application Performance Today

4 Skills You Need to Become a Distinguished Developer

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps