Encapsulation
The principle of bundling data and behavior together while hiding internal implementation details behind a well-defined public interface.
Also known as: Information Hiding, Data Hiding, Encapsulation Principle
Category: Software Development
Tags: software-development, principles, design-patterns, architecture, object-oriented-programming
Explanation
Encapsulation is one of the fundamental principles of object-oriented programming and, more broadly, of good system design. It has two complementary aspects: bundling related data and operations together, and hiding internal details so that the rest of the system interacts only through a well-defined interface.
## The Two Aspects
### 1. Bundling
Related data and the operations that act on that data are grouped together into a single unit (class, module, service). This ensures that the logic for managing a piece of data lives alongside the data itself, rather than being scattered across the codebase.
### 2. Information hiding
The internal state and implementation details of a module are hidden from the outside world. Other modules interact only through a public interface (API). They don't know — and don't need to know — how things work inside.
## Why Encapsulation Matters
- **Change safety**: Internal implementations can be modified or optimized without affecting any code that uses the module, as long as the public interface stays stable
- **Reduced complexity**: Users of a module deal with a simple interface instead of understanding all internal details
- **Data integrity**: Internal state can't be corrupted by external code because access is controlled through methods that enforce invariants
- **Clear boundaries**: Encapsulation makes it obvious what is public (the contract) versus private (the implementation)
## In Practice
```
// Poor encapsulation: internal state exposed
user.balance = user.balance - amount; // Can set negative balance!
// Good encapsulation: behavior through interface
user.withdraw(amount); // Validates, enforces rules, updates safely
```
## Encapsulation Beyond OOP
The principle extends far beyond classes:
- **Functions**: Accept parameters, return results, hide internal logic
- **Modules/packages**: Export a public API, keep internals private
- **Microservices**: Expose endpoints, hide database schemas and implementation
- **APIs**: Provide stable contracts while allowing internal evolution
- **Organizations**: Teams encapsulate expertise behind clear interfaces (requests, deliverables)
## Encapsulation and Related Principles
| Principle | Relationship |
|---|---|
| **Information hiding** | The 'hiding' aspect of encapsulation (Parnas, 1972) |
| **Abstraction** | Encapsulation enables abstraction by hiding complexity behind simple interfaces |
| **Cohesion** | Encapsulated modules tend to be cohesive — their internals serve one purpose |
| **Coupling** | Good encapsulation reduces coupling — modules depend on interfaces, not implementations |
| **SRP** | A well-encapsulated module has a single responsibility |
## Common Violations
- **Getters/setters for everything**: Exposing all internal state through accessors defeats the purpose
- **Leaky abstractions**: Internal details bleeding through the interface
- **Public fields**: Direct access to internal data without validation or control
- **God objects**: Large objects that encapsulate too much, becoming hard to understand
- **Anemic domain models**: Objects that are just data containers with no behavior, leaving logic scattered elsewhere
Related Concepts
← Back to all concepts