System Design LLDWhat Is Encapsulation

What Is Encapsulation?

LevelBeginner

Duration50 mins

TopicWhat Is Encapsulation

3 / 4

Hiding Implementation Details

The Power of Secrets

Every well-designed module keeps secrets.

When you use your smartphone, you tap icons and type messages. You don't manipulate the electrical signals directly. You don't access memory addresses or manage battery voltage levels. These implementation details are hidden from you—and that's precisely why you can use the phone at all.

If every internal detail were exposed, the cognitive load would be unbearable. You'd need to understand electromagnetic signals just to send a text. The hiding of details is what makes complex systems usable.

In software, the principle is identical. Classes that expose their internal implementation details become impossible to change, difficult to understand, and dangerous to use. Classes that hide their internals behind stable interfaces become resilient, maintainable, and safe.

This page explores the second pillar of encapsulation: information hiding through access control. We'll learn what to hide, how to hide it, and why secrets are the foundation of maintainable software.

What You Will Learn

By the end of this page, you will understand access modifiers and their semantics, apply the principle of least privilege to class design, identify what should be hidden and what should be exposed, understand how hiding enables change and reduces coupling, and recognize the symptoms of insufficient hiding.

The Mechanics of Hiding: Access Modifiers

Most object-oriented languages provide access modifiers—keywords that control the visibility of class members. While syntax varies, the concepts are universal:

Access Modifiers Across Languages
Visibility	Java/C#	Python	TypeScript	C++	Who Can Access
Public	`public`	No prefix	`public`	`public:`	Anyone, anywhere
Protected	`protected`	`_prefix`	`protected`	`protected:`	Class + subclasses
Package/Internal	`(default)`/`internal`	N/A	N/A	N/A	Same package/module
Private	`private`	`__prefix`	`private`	`private:`	Only the class itself

The spectrum of visibility:

Access modifiers create a spectrum from fully hidden to fully exposed:

Most Hidden ←――――――――――――――――――――――→ Most Exposed
   private → protected → package → public

Each step toward public exposure:

Increases the risk that external code will depend on that member
Decreases your freedom to change that member
Expands the surface area of potential bugs
Raises the cognitive load for users of your class

access_modifiers_example.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
class BankAccount {
    // PRIVATE: Deepest secrets - internal data representation
    private balance: number;
    private transactionLog: Transaction[];
    private overdraftLimit: number;
    
    // PROTECTED: Secrets shared with subclasses
    protected accountType: AccountType;
    protected interestRate: number;
    
    // PUBLIC: The contract this class offers to the world
    public readonly accountNumber: string;
    
    public deposit(amount: number): DepositResult {
        // External code calls this...
        this.validateAmount(amount);           // ...but can't call this
        this.balance += amount;                // ...or access this
        this.recordTransaction('deposit', amount);  // ...or modify this
        return new DepositResult(true, this.getBalance());
    }
    
    public getBalance(): number {
        // Public accessor - controlled window into private state
        // Could apply transformations, caching, access logging, etc.
        return this.balance;
    }
    
    // PRIVATE: Implementation details hidden from everyone
    private validateAmount(amount: number): void {
        if (amount <= 0) {
            throw new InvalidAmountError("Amount must be positive");
        }
    }
    
    private recordTransaction(type: string, amount: number): void {
        this.transactionLog.push(new Transaction(type, amount, new Date()));
    }
}

The Default Should Be Private

When designing a class, start with all members private. Only increase visibility when there's a proven need. This "private by default" approach ensures you never accidentally expose internals. Making something public later is easy; making something private later is often impossible without breaking clients.

What to Hide: The Essential List

Not everything needs hiding, but some things absolutely must be hidden. Here's a systematic guide:

Must Always Hide

•Raw State Variables — The actual data storage (fields). External code should never directly read or write balance; it should use deposit(), withdraw(), getBalance().
•Data Representation Choices — Whether you store amounts as integers (cents) or decimals, dates as timestamps or objects, users as IDs or full objects—these are internal choices.
•Invariant Enforcement Logic — The validation and consistency checks that maintain object validity. If exposed, callers could bypass them.
•Caching and Optimization Details — Whether you cache computed values, use lazy initialization, or precompute results—these are implementation optimizations.
•Helper Methods — Internal utilities that decompose complex logic. These exist for code organization, not as part of the public contract.
•Third-Party Dependencies — If your class uses a specific library internally, hide that dependency. Don't let it leak into your public interface.

Should Expose

•Domain Operations — The meaningful actions the object can perform: deposit(), withdraw(), transfer(). These form the behavioral contract.
•Stable Queries — Ways to ask about object state that won't change semantically: getBalance(), isActive(), getOwner().
•Configuration Points — Aspects legitimately customized from outside: constructor parameters, builder patterns, strategy injections.
•Immutable Identity — Fixed properties that identify the object: accountNumber, id, type (when truly immutable).

The core question:

For every member, ask: "If I expose this, what assumptions will clients make? What happens if I need to change this?"

If changing it would break clients, consider whether they should be depending on it at all. Often the answer is no—and hiding is the solution.

Why Hiding Enables Change

The deepest reason to hide implementation details is to preserve your freedom to change. Every detail you expose becomes a constraint you cannot violate without breaking clients.

Consider this evolution:

evolution_with_hiding.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// VERSION 1: Simple implementation
class PriceCalculator {
    private basePrice: number;
    private taxRate: number;
    
    getTotal(): number {
        return this.basePrice * (1 + this.taxRate);
    }
}
 
// VERSION 2: Added caching (internal optimization)
class PriceCalculator {
    private basePrice: number;
    private taxRate: number;
    private cachedTotal: number | null = null;  // NEW!
    
    getTotal(): number {
        if (this.cachedTotal === null) {
            this.cachedTotal = this.basePrice * (1 + this.taxRate);
        }
        return this.cachedTotal;
    }
    
    private invalidateCache(): void {  // NEW!
        this.cachedTotal = null;
    }
}
 
// VERSION 3: Changed to use BigDecimal for precision (internal change)
class PriceCalculator {
    private basePrice: BigDecimal;  // CHANGED type
    private taxRate: BigDecimal;    // CHANGED type
    private cachedTotal: BigDecimal | null = null;
    
    getTotal(): number {  // Same signature!
        if (this.cachedTotal === null) {
            this.cachedTotal = this.basePrice.multiply(
                BigDecimal.ONE.add(this.taxRate)
            );
        }
        return this.cachedTotal.toNumber();  // Convert for backwards compat
    }
}
 
// ✅ All versions are drop-in compatible!
// Clients only call getTotal() - they never knew or cared about internals

Because the internal representation was hidden, we could:

Add caching without changing the interface
Change the numeric type for precision
Modify validation rules
Refactor helper methods

All without any client code knowing or caring.

Now imagine if basePrice had been public. Clients would be accessing it directly. The moment you change its type from number to BigDecimal, every client breaks. You've lost the freedom to evolve.

Hyrum's Law

"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." — Hyrum Wright, Google. This is why hiding is so critical. Any exposed detail WILL be depended on, regardless of whether you intended it to be part of the contract.

The Coupling-Hiding Connection

Coupling is the degree of interdependence between software modules. High coupling means changes in one module ripple through many others. Low coupling means modules can change independently.

Hiding reduces coupling by limiting what external code can depend on.

Converting Mermaid diagram...

In the exposed design:

Each client couples to specific internals
Changing any field requires updating multiple clients
Adding a field changes nothing; renaming requires searching all clients
The class cannot evolve independently

In the hidden design:

All clients couple only to the public API
Internals can change freely
Only API changes affect clients
The class evolves with impunity

Change Impact: Hidden vs Exposed
Change Type	Exposed Internals	Hidden Internals
Rename internal field	Break all clients using that field	Zero impact - change one file
Change field type	Break all clients reading/writing that field	Zero impact - internal only
Add caching	Potentially break clients expecting fresh computation	Zero impact - optimization is internal
Change algorithm	Might break clients depending on intermediate states	Zero impact - result is same
Add validation	Might break clients setting invalid values directly	Zero impact - API enforces rules

Measure Your Coupling

A quick coupling test: if you wanted to change your class's internal representation, how many other files would need updating? If the answer is more than one (the class itself), you have coupling through exposed internals. Proper hiding brings this number to exactly one.

The Getter/Setter Debate

A common misconception: "If I make fields private and add getters and setters, I've encapsulated."

This is often false. Blindly adding getters and setters can provide almost no encapsulation benefit. Let's analyze:

getters_illusion.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// ❌ FAKE ENCAPSULATION: Getters/setters for everything
class Order {
    private items: OrderItem[];
    private status: string;
    private total: number;
    
    // These provide ZERO protection
    getItems(): OrderItem[] { return this.items; }      // Exposes mutable array!
    setItems(items: OrderItem[]) { this.items = items; } // No validation!
    
    getStatus(): string { return this.status; }
    setStatus(status: string) { this.status = status; } // Any string!
    
    getTotal(): number { return this.total; }
    setTotal(total: number) { this.total = total; }     // Can break invariant!
}
 
// External code can do all of this:
order.setStatus("banana");              // Invalid status!
order.setTotal(-500);                   // Negative total!
order.getItems().push(maliciousItem);   // Modified internal array!
order.getItems().length = 0;            // Cleared items!
 
// This is worse than public fields because it's LONGER CODE
// with the same vulnerability.

When getters are acceptable:

Legitimate Getter Use Cases

•Immutable data — If the returned value cannot be modified (primitives, strings, immutable objects), getting it is safe.
•Defensive copies — Return a copy of mutable data, not the original: return [...this.items] or return Object.freeze({...this.data}).
•Computed/derived values — Values calculated on-the-fly from internal state: getTotal() that sums items rather than returning a stored field.
•Framework requirements — Some frameworks (ORMs, serialization) require getters. Accept this as necessary compromise, but be aware of the tradeoff.

When setters are rarely acceptable:

The Problem with Setters

•Bypass invariants — Setters allow clients to set invalid combinations of state. setTotal() can create an Order where total doesn't match items.
•Encourage Tell/Ask violation — With setters, clients fetch data, make decisions, then set. Without them, clients tell the object to perform actions.
•Create mutable objects artificially — Setters discourage immutability. Often, what seems to need mutation actually needs constructor parameters or builder patterns.
•Hide transactional intent — Calling setStatus('cancelled') hides the business operation. cancel() method is clearer and can enforce cancellation rules.

The Setter Replacement

Instead of setters, provide domain-meaningful methods: replace setStatus() with confirm(), ship(), cancel(), return(). Replace setTotal() with calculateTotal() that's called internally. Replace setItems() with addItem(), removeItem(), clearItems(). Each method enforces its own rules.

Hiding in Practice: Defensive Techniques

Beyond access modifiers, several techniques reinforce information hiding:

Defensive Hiding Techniques

•Defensive Copying — When returning mutable objects from getters, return a copy. When accepting mutable objects in setters/constructors, store a copy. This prevents external code from maintaining references to your internals.
•Immutable Views — Return read-only wrappers around collections: Collections.unmodifiableList() in Java, Object.freeze() in JavaScript, ReadonlyArray<T> in TypeScript.
•Copy-on-Write — Delay copying until modification is actually requested. Efficient when reads vastly outnumber writes.
•Value Objects — Return immutable value objects rather than accessing primitives. Instead of getX() and getY(), return a Point object.
•Interface Segregation — Expose narrow interfaces rather than the full class. A ReadableAccount interface exposes only getBalance(), while the full BankAccount class includes deposit() and withdraw().

defensive_techniques.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
class Employee {
    private name: string;
    private skills: Set<string>;
    private startDate: Date;
    private salary: Money;  // Value object instead of number
    
    // ✅ Defensive copy on input
    constructor(name: string, skills: string[], startDate: Date) {
        this.name = name;
        this.skills = new Set(skills);           // Copy the array into a Set
        this.startDate = new Date(startDate.getTime());  // Copy the Date
        this.salary = Money.zero();
    }
    
    // ✅ Defensive copy on output
    getSkills(): ReadonlySet<string> {
        return this.skills;  // TypeScript ReadonlySet prevents mutations
    }
    
    getStartDate(): Date {
        return new Date(this.startDate.getTime());  // Return a copy
    }
    
    // ✅ Value object return - immutable by design
    getSalary(): Money {
        return this.salary;  // Money is immutable, safe to return
    }
    
    // ✅ Command method instead of setter
    adjustSalary(adjustment: SalaryAdjustment): void {
        if (!adjustment.isApproved()) {
            throw new UnauthorizedError("Salary adjustment not approved");
        }
        this.salary = adjustment.apply(this.salary);
        this.recordAudit(adjustment);
    }
    
    private recordAudit(adjustment: SalaryAdjustment): void {
        // Internal auditing logic
    }
}
 
// Value object: immutable, no setters, equality by value
class Money {
    private readonly amount: number;
    private readonly currency: string;
    
    constructor(amount: number, currency: string) {
        if (amount < 0) throw new Error("Money cannot be negative");
        this.amount = amount;
        this.currency = currency;
    }
    
    add(other: Money): Money {
        if (this.currency !== other.currency) {
            throw new CurrencyMismatchError();
        }
        return new Money(this.amount + other.amount, this.currency);
    }
    
    static zero(): Money {
        return new Money(0, 'USD');
    }
}

Signs of Insufficient Hiding

How do you know if a codebase has hiding problems? Look for these symptoms:

Symptoms of Failed Information Hiding

•Shotgun Surgery — A single logical change requires editing many classes because they all depend on the changed class's internals.
•Parallel Class Hierarchies — Changes to one hierarchy (e.g., domain classes) require matching changes to another (e.g., serialization classes) because internals are exposed.
•Train Wrecks — Code chains like order.getCustomer().getAddress().getCity().toUpperCase() — reaching deep into object graphs because internals are exposed.
•Primitive Obsession — Classes expose raw primitives (int, string) instead of meaningful types, making it easy to misuse values.
•Feature Envy — Methods that spend more time accessing another class's data than their own—a sign the data should be private and the method should move.
•Inappropriate Intimacy — Classes that seem to know too much about each other's internals, accessing private details through package visibility or reflection.

train_wreck_example.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// ❌ TRAIN WRECK: Chain of exposed internals
function calculateShipping(order: Order): number {
    // We're reaching into customer, into address, into country, into region...
    const region = order.getCustomer()
                        .getAddress()
                        .getCountry()
                        .getRegion();
    
    // And into items, into first item, into weight...
    const weight = order.getItems()[0].getWeight();
    
    return this.shippingRates.get(region) * weight;
}
 
// ✅ PROPER HIDING: Ask the object that knows
function calculateShipping(order: Order): number {
    // Order knows its shipping destination and weight
    // We don't need to know how it knows
    return order.calculateShippingCost(this.shippingRates);
}
 
// Inside Order:
calculateShippingCost(rates: ShippingRates): number {
    const region = this.customer.getShippingRegion();  // Customer knows its region
    const weight = this.getTotalWeight();              // Order knows its weight
    return rates.calculate(region, weight);
}

Law of Demeter

The 'Law of Demeter' (or 'Principle of Least Knowledge') formalizes train wreck avoidance: a method should only call methods on (1) itself, (2) its parameters, (3) objects it creates, (4) its direct components. Never call methods on objects returned by other methods—that's reaching into someone else's internals.

Summary: Hiding Implementation Details

We've explored the second pillar of encapsulation in depth. Here are the essential takeaways:

Key Takeaways

•Access modifiers control visibility — Use private by default. Only increase visibility when there's a proven need.
•Hide implementation, expose behavior — Internal data structures, helper methods, and optimization details are secrets. Domain operations and stable queries are the public contract.
•Hiding enables change — Every exposed detail becomes a constraint. Hidden details can be refactored, optimized, or completely redesigned without breaking clients.
•Hiding reduces coupling — Clients can only depend on public API. Changes to internals don't ripple through the codebase.
•Getters and setters are often fake encapsulation — Trivial accessors provide the illusion of hiding while exposing everything. Use domain methods instead.
•Use defensive techniques — Defensive copying, immutable views, and value objects reinforce hiding even when returning data.
•Recognize symptoms of insufficient hiding — Shotgun surgery, train wrecks, and feature envy indicate encapsulation violations.

What's next:

We've covered the definition of encapsulation, bundling data with behavior, and hiding implementation details. The next page brings everything together by examining why encapsulation matters at the system level—its impact on maintainability, testability, security, and team scalability.

Page Complete

You now understand how to hide implementation details effectively—not just through access modifiers, but through thoughtful API design, defensive techniques, and recognition of encapsulation violations. Your classes can now evolve independently, protected from the chaos of uncontrolled access.

3 / 4

Loading learning content...

System Design LLDWhat Is Encapsulation

What Is Encapsulation?

LevelBeginner

Duration50 mins

TopicWhat Is Encapsulation

3 / 4

Hiding Implementation Details

The Power of Secrets

Every well-designed module keeps secrets.

What You Will Learn

The Mechanics of Hiding: Access Modifiers

Most object-oriented languages provide access modifiers—keywords that control the visibility of class members. While syntax varies, the concepts are universal:

Access Modifiers Across Languages
Visibility	Java/C#	Python	TypeScript	C++	Who Can Access
Public	`public`	No prefix	`public`	`public:`	Anyone, anywhere
Protected	`protected`	`_prefix`	`protected`	`protected:`	Class + subclasses
Package/Internal	`(default)`/`internal`	N/A	N/A	N/A	Same package/module
Private	`private`	`__prefix`	`private`	`private:`	Only the class itself

The spectrum of visibility:

Access modifiers create a spectrum from fully hidden to fully exposed:

Most Hidden ←――――――――――――――――――――――→ Most Exposed
   private → protected → package → public

Each step toward public exposure:

Increases the risk that external code will depend on that member
Decreases your freedom to change that member
Expands the surface area of potential bugs
Raises the cognitive load for users of your class

access_modifiers_example.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
class BankAccount {
    // PRIVATE: Deepest secrets - internal data representation
    private balance: number;
    private transactionLog: Transaction[];
    private overdraftLimit: number;
    
    // PROTECTED: Secrets shared with subclasses
    protected accountType: AccountType;
    protected interestRate: number;
    
    // PUBLIC: The contract this class offers to the world
    public readonly accountNumber: string;
    
    public deposit(amount: number): DepositResult {
        // External code calls this...
        this.validateAmount(amount);           // ...but can't call this
        this.balance += amount;                // ...or access this
        this.recordTransaction('deposit', amount);  // ...or modify this
        return new DepositResult(true, this.getBalance());
    }
    
    public getBalance(): number {
        // Public accessor - controlled window into private state
        // Could apply transformations, caching, access logging, etc.
        return this.balance;
    }
    
    // PRIVATE: Implementation details hidden from everyone
    private validateAmount(amount: number): void {
        if (amount <= 0) {
            throw new InvalidAmountError("Amount must be positive");
        }
    }
    
    private recordTransaction(type: string, amount: number): void {
        this.transactionLog.push(new Transaction(type, amount, new Date()));
    }
}

The Default Should Be Private

What to Hide: The Essential List

Not everything needs hiding, but some things absolutely must be hidden. Here's a systematic guide:

Must Always Hide

•Raw State Variables — The actual data storage (fields). External code should never directly read or write balance; it should use deposit(), withdraw(), getBalance().
•Data Representation Choices — Whether you store amounts as integers (cents) or decimals, dates as timestamps or objects, users as IDs or full objects—these are internal choices.
•Invariant Enforcement Logic — The validation and consistency checks that maintain object validity. If exposed, callers could bypass them.
•Caching and Optimization Details — Whether you cache computed values, use lazy initialization, or precompute results—these are implementation optimizations.
•Helper Methods — Internal utilities that decompose complex logic. These exist for code organization, not as part of the public contract.
•Third-Party Dependencies — If your class uses a specific library internally, hide that dependency. Don't let it leak into your public interface.

Should Expose

•Domain Operations — The meaningful actions the object can perform: deposit(), withdraw(), transfer(). These form the behavioral contract.
•Stable Queries — Ways to ask about object state that won't change semantically: getBalance(), isActive(), getOwner().
•Configuration Points — Aspects legitimately customized from outside: constructor parameters, builder patterns, strategy injections.
•Immutable Identity — Fixed properties that identify the object: accountNumber, id, type (when truly immutable).

The core question:

For every member, ask: "If I expose this, what assumptions will clients make? What happens if I need to change this?"

If changing it would break clients, consider whether they should be depending on it at all. Often the answer is no—and hiding is the solution.

Why Hiding Enables Change

The deepest reason to hide implementation details is to preserve your freedom to change. Every detail you expose becomes a constraint you cannot violate without breaking clients.

Consider this evolution:

evolution_with_hiding.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// VERSION 1: Simple implementation
class PriceCalculator {
    private basePrice: number;
    private taxRate: number;
    
    getTotal(): number {
        return this.basePrice * (1 + this.taxRate);
    }
}
 
// VERSION 2: Added caching (internal optimization)
class PriceCalculator {
    private basePrice: number;
    private taxRate: number;
    private cachedTotal: number | null = null;  // NEW!
    
    getTotal(): number {
        if (this.cachedTotal === null) {
            this.cachedTotal = this.basePrice * (1 + this.taxRate);
        }
        return this.cachedTotal;
    }
    
    private invalidateCache(): void {  // NEW!
        this.cachedTotal = null;
    }
}
 
// VERSION 3: Changed to use BigDecimal for precision (internal change)
class PriceCalculator {
    private basePrice: BigDecimal;  // CHANGED type
    private taxRate: BigDecimal;    // CHANGED type
    private cachedTotal: BigDecimal | null = null;
    
    getTotal(): number {  // Same signature!
        if (this.cachedTotal === null) {
            this.cachedTotal = this.basePrice.multiply(
                BigDecimal.ONE.add(this.taxRate)
            );
        }
        return this.cachedTotal.toNumber();  // Convert for backwards compat
    }
}
 
// ✅ All versions are drop-in compatible!
// Clients only call getTotal() - they never knew or cared about internals

Because the internal representation was hidden, we could:

Add caching without changing the interface
Change the numeric type for precision
Modify validation rules
Refactor helper methods

All without any client code knowing or caring.

Hyrum's Law

The Coupling-Hiding Connection

Coupling is the degree of interdependence between software modules. High coupling means changes in one module ripple through many others. Low coupling means modules can change independently.

Hiding reduces coupling by limiting what external code can depend on.

Converting Mermaid diagram...

In the exposed design:

Each client couples to specific internals
Changing any field requires updating multiple clients
Adding a field changes nothing; renaming requires searching all clients
The class cannot evolve independently

In the hidden design:

All clients couple only to the public API
Internals can change freely
Only API changes affect clients
The class evolves with impunity

Change Impact: Hidden vs Exposed
Change Type	Exposed Internals	Hidden Internals
Rename internal field	Break all clients using that field	Zero impact - change one file
Change field type	Break all clients reading/writing that field	Zero impact - internal only
Add caching	Potentially break clients expecting fresh computation	Zero impact - optimization is internal
Change algorithm	Might break clients depending on intermediate states	Zero impact - result is same
Add validation	Might break clients setting invalid values directly	Zero impact - API enforces rules

Measure Your Coupling

The Getter/Setter Debate

A common misconception: "If I make fields private and add getters and setters, I've encapsulated."

This is often false. Blindly adding getters and setters can provide almost no encapsulation benefit. Let's analyze:

getters_illusion.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// ❌ FAKE ENCAPSULATION: Getters/setters for everything
class Order {
    private items: OrderItem[];
    private status: string;
    private total: number;
    
    // These provide ZERO protection
    getItems(): OrderItem[] { return this.items; }      // Exposes mutable array!
    setItems(items: OrderItem[]) { this.items = items; } // No validation!
    
    getStatus(): string { return this.status; }
    setStatus(status: string) { this.status = status; } // Any string!
    
    getTotal(): number { return this.total; }
    setTotal(total: number) { this.total = total; }     // Can break invariant!
}
 
// External code can do all of this:
order.setStatus("banana");              // Invalid status!
order.setTotal(-500);                   // Negative total!
order.getItems().push(maliciousItem);   // Modified internal array!
order.getItems().length = 0;            // Cleared items!
 
// This is worse than public fields because it's LONGER CODE
// with the same vulnerability.

When getters are acceptable:

Legitimate Getter Use Cases

•Immutable data — If the returned value cannot be modified (primitives, strings, immutable objects), getting it is safe.
•Defensive copies — Return a copy of mutable data, not the original: return [...this.items] or return Object.freeze({...this.data}).
•Computed/derived values — Values calculated on-the-fly from internal state: getTotal() that sums items rather than returning a stored field.
•Framework requirements — Some frameworks (ORMs, serialization) require getters. Accept this as necessary compromise, but be aware of the tradeoff.

When setters are rarely acceptable:

The Problem with Setters

•Bypass invariants — Setters allow clients to set invalid combinations of state. setTotal() can create an Order where total doesn't match items.
•Encourage Tell/Ask violation — With setters, clients fetch data, make decisions, then set. Without them, clients tell the object to perform actions.
•Create mutable objects artificially — Setters discourage immutability. Often, what seems to need mutation actually needs constructor parameters or builder patterns.
•Hide transactional intent — Calling setStatus('cancelled') hides the business operation. cancel() method is clearer and can enforce cancellation rules.

The Setter Replacement

Hiding in Practice: Defensive Techniques

Beyond access modifiers, several techniques reinforce information hiding:

Defensive Hiding Techniques

•Defensive Copying — When returning mutable objects from getters, return a copy. When accepting mutable objects in setters/constructors, store a copy. This prevents external code from maintaining references to your internals.
•Immutable Views — Return read-only wrappers around collections: Collections.unmodifiableList() in Java, Object.freeze() in JavaScript, ReadonlyArray<T> in TypeScript.
•Copy-on-Write — Delay copying until modification is actually requested. Efficient when reads vastly outnumber writes.
•Value Objects — Return immutable value objects rather than accessing primitives. Instead of getX() and getY(), return a Point object.
•Interface Segregation — Expose narrow interfaces rather than the full class. A ReadableAccount interface exposes only getBalance(), while the full BankAccount class includes deposit() and withdraw().

defensive_techniques.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
class Employee {
    private name: string;
    private skills: Set<string>;
    private startDate: Date;
    private salary: Money;  // Value object instead of number
    
    // ✅ Defensive copy on input
    constructor(name: string, skills: string[], startDate: Date) {
        this.name = name;
        this.skills = new Set(skills);           // Copy the array into a Set
        this.startDate = new Date(startDate.getTime());  // Copy the Date
        this.salary = Money.zero();
    }
    
    // ✅ Defensive copy on output
    getSkills(): ReadonlySet<string> {
        return this.skills;  // TypeScript ReadonlySet prevents mutations
    }
    
    getStartDate(): Date {
        return new Date(this.startDate.getTime());  // Return a copy
    }
    
    // ✅ Value object return - immutable by design
    getSalary(): Money {
        return this.salary;  // Money is immutable, safe to return
    }
    
    // ✅ Command method instead of setter
    adjustSalary(adjustment: SalaryAdjustment): void {
        if (!adjustment.isApproved()) {
            throw new UnauthorizedError("Salary adjustment not approved");
        }
        this.salary = adjustment.apply(this.salary);
        this.recordAudit(adjustment);
    }
    
    private recordAudit(adjustment: SalaryAdjustment): void {
        // Internal auditing logic
    }
}
 
// Value object: immutable, no setters, equality by value
class Money {
    private readonly amount: number;
    private readonly currency: string;
    
    constructor(amount: number, currency: string) {
        if (amount < 0) throw new Error("Money cannot be negative");
        this.amount = amount;
        this.currency = currency;
    }
    
    add(other: Money): Money {
        if (this.currency !== other.currency) {
            throw new CurrencyMismatchError();
        }
        return new Money(this.amount + other.amount, this.currency);
    }
    
    static zero(): Money {
        return new Money(0, 'USD');
    }
}

Signs of Insufficient Hiding

How do you know if a codebase has hiding problems? Look for these symptoms:

Symptoms of Failed Information Hiding

•Shotgun Surgery — A single logical change requires editing many classes because they all depend on the changed class's internals.
•Parallel Class Hierarchies — Changes to one hierarchy (e.g., domain classes) require matching changes to another (e.g., serialization classes) because internals are exposed.
•Train Wrecks — Code chains like order.getCustomer().getAddress().getCity().toUpperCase() — reaching deep into object graphs because internals are exposed.
•Primitive Obsession — Classes expose raw primitives (int, string) instead of meaningful types, making it easy to misuse values.
•Feature Envy — Methods that spend more time accessing another class's data than their own—a sign the data should be private and the method should move.
•Inappropriate Intimacy — Classes that seem to know too much about each other's internals, accessing private details through package visibility or reflection.

train_wreck_example.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// ❌ TRAIN WRECK: Chain of exposed internals
function calculateShipping(order: Order): number {
    // We're reaching into customer, into address, into country, into region...
    const region = order.getCustomer()
                        .getAddress()
                        .getCountry()
                        .getRegion();
    
    // And into items, into first item, into weight...
    const weight = order.getItems()[0].getWeight();
    
    return this.shippingRates.get(region) * weight;
}
 
// ✅ PROPER HIDING: Ask the object that knows
function calculateShipping(order: Order): number {
    // Order knows its shipping destination and weight
    // We don't need to know how it knows
    return order.calculateShippingCost(this.shippingRates);
}
 
// Inside Order:
calculateShippingCost(rates: ShippingRates): number {
    const region = this.customer.getShippingRegion();  // Customer knows its region
    const weight = this.getTotalWeight();              // Order knows its weight
    return rates.calculate(region, weight);
}

Law of Demeter

Summary: Hiding Implementation Details

We've explored the second pillar of encapsulation in depth. Here are the essential takeaways:

Key Takeaways

•Access modifiers control visibility — Use private by default. Only increase visibility when there's a proven need.
•Hide implementation, expose behavior — Internal data structures, helper methods, and optimization details are secrets. Domain operations and stable queries are the public contract.
•Hiding enables change — Every exposed detail becomes a constraint. Hidden details can be refactored, optimized, or completely redesigned without breaking clients.
•Hiding reduces coupling — Clients can only depend on public API. Changes to internals don't ripple through the codebase.
•Getters and setters are often fake encapsulation — Trivial accessors provide the illusion of hiding while exposing everything. Use domain methods instead.
•Use defensive techniques — Defensive copying, immutable views, and value objects reinforce hiding even when returning data.
•Recognize symptoms of insufficient hiding — Shotgun surgery, train wrecks, and feature envy indicate encapsulation violations.

What's next:

Page Complete

3 / 4