System Design (HLD)Encapsulation in Practice

Encapsulation in Practice

LevelIntermediate

Duration60 mins

TopicEncapsulation in Practice

2 / 4

Common Encapsulation Mistakes

Learning from Mistakes

Encapsulation seems straightforward in principle—make fields private, provide methods. Yet in practice, encapsulation violations appear constantly in production codebases. These aren't random errors; they follow predictable patterns born from time pressure, incomplete understanding, or insidious code evolution.

Understanding these common mistakes is essential because:

You'll encounter them — Legacy code and even new code from less experienced developers contains these patterns
You'll be tempted by them — Some violations feel convenient in the moment
You need to fix them — Refactoring poor encapsulation requires recognizing it first

What You Will Learn

By the end of this page, you'll be able to identify the most common encapsulation anti-patterns, understand why each pattern is problematic, recognize the symptoms in code reviews, and know the standard fixes for each mistake.

Mistake 1: Exposing Internal Collections

This is arguably the most common encapsulation mistake, even among experienced developers. It occurs when a class returns a reference to an internal mutable collection, allowing external code to modify class internals directly.

The Problem

Team.java (Broken Encapsulation)
Java
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
// ❌ ENCAPSULATION LEAK - Internal collection exposed
public class Team {
    private String name;
    private List<Player> players;  // Private... but not really
    
    public Team(String name) {
        this.name = name;
        this.players = new ArrayList<>();
    }
    
    // This looks harmless but completely breaks encapsulation
    public List<Player> getPlayers() {
        return players;  // Returns the ACTUAL internal list!
    }
    
    public void addPlayer(Player player) {
        if (players.size() >= 25) {
            throw new TeamFullException("Roster limit reached");
        }
        if (player.getSalary() > getSalaryCap()) {
            throw new SalaryCapException("Would exceed salary cap");
        }
        players.add(player);
    }
}
 
// External code can now bypass ALL business rules
class SneakyClient {
    public void breakTheRules(Team team) {
        List<Player> roster = team.getPlayers();
        
        // Add 100 players, ignoring roster limits
        for (int i = 0; i < 100; i++) {
            roster.add(new Player("Player" + i, 50_000_000));
        }
        
        // Clear the entire roster
        roster.clear();
        
        // Add a null player (causes NPEs later)
        roster.add(null);
        
        // Replace with a completely different list implementation
        // that behaves unexpectedly
        roster.sort(null);  // Changes internal order
    }
}

Why This Happens

Developers often think 'the field is private, so I'm safe.' But private only protects the reference—the pointer to the list. Once you hand out that pointer via a getter, anyone can modify the list's contents. The field is still private, but the data it points to is completely exposed.

The Fix: Defensive Copies or Unmodifiable Views

Team.java (Fixed)
Java
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
// ✅ PROPER ENCAPSULATION - Collection protected
public class Team {
    private String name;
    private final List<Player> players;
    
    public Team(String name) {
        this.name = name;
        this.players = new ArrayList<>();
    }
    
    // Option 1: Return unmodifiable view
    public List<Player> getPlayers() {
        return Collections.unmodifiableList(players);
    }
    
    // Option 2: Return defensive copy (safer but more memory)
    public List<Player> getPlayersCopy() {
        return new ArrayList<>(players);
    }
    
    // Option 3: Return stream (can't modify, encourages functional style)
    public Stream<Player> players() {
        return players.stream();
    }
    
    // All modifications go through controlled methods
    public void addPlayer(Player player) {
        Objects.requireNonNull(player, "Player cannot be null");
        if (players.size() >= 25) {
            throw new TeamFullException("Roster limit reached");
        }
        if (player.getSalary() > getSalaryCap()) {
            throw new SalaryCapException("Would exceed salary cap");
        }
        players.add(player);
    }
    
    public boolean removePlayer(String playerId) {
        return players.removeIf(p -> p.getId().equals(playerId));
    }
}

Choosing the Right Protection Strategy

•Unmodifiable view — Lightweight, reflects current state, but client might cache and see changes. Best for 'read current snapshot' cases.
•Defensive copy — Isolated from changes, but costs memory proportional to collection size. Best when client needs stable data for extended processing.
•Stream — Encourages functional processing, naturally discourages storing. Best for clients who want to filter/map/reduce.

Mistake 2: Mechanical Getter/Setter Generation

Auto-generating getters and setters for every field creates the illusion of encapsulation without any actual benefit. If every field has a public getter and setter, the class is effectively a struct with extra ceremony.

The Anti-Pattern

Employee.java (False Encapsulation)
Java
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
// ❌ FAKE ENCAPSULATION - Every field exposed through accessors
public class Employee {
    private String id;
    private String firstName;
    private String lastName;
    private String email;
    private String department;
    private double salary;
    private Date hireDate;
    private String managerId;
    private boolean isActive;
    
    // Lombok @Data or IDE-generated accessors for ALL fields
    public String getId() { return id; }
    public void setId(String id) { this.id = id; }
    
    public String getFirstName() { return firstName; }
    public void setFirstName(String firstName) { this.firstName = firstName; }
    
    public String getLastName() { return lastName; }
    public void setLastName(String lastName) { this.lastName = lastName; }
    
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }  // No validation!
    
    public double getSalary() { return salary; }
    public void setSalary(double salary) { this.salary = salary; }  // Negative salary? Sure!
    
    public Date getHireDate() { return hireDate; }
    public void setHireDate(Date hireDate) { this.hireDate = hireDate; }  // Future date? Fine!
    
    public boolean isActive() { return isActive; }
    public void setActive(boolean active) { this.isActive = active; }  // No termination process!
    
    // ... all the same for remaining fields
}
 
// Client code does whatever it wants
class HRSystem {
    public void processPayroll(Employee emp) {
        // Setting salary to negative steals money?
        emp.setSalary(-50000);
        
        // Changing hire date for backdated benefits?
        emp.setHireDate(Date.from(Instant.EPOCH));
        
        // Reactivating terminated employees?
        emp.setActive(true);
        
        // Changing employee ID breaks database relations
        emp.setId("FAKE_ID");
    }
}

The Core Problem

When every field has a setter, the class cannot maintain invariants. It's just a data bag that any external code can corrupt. The private fields provide zero protection—they're just a layer of indirection that adds boilerplate without benefit.

The Fix: Intentional Accessors Based on Domain Needs

Employee.java (Proper Encapsulation)
Java
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
// ✅ INTENTIONAL ENCAPSULATION - Only expose what's needed
public final class Employee {
    private final String id;  // Immutable - no setter
    private String firstName;
    private String lastName;
    private Email email;  // Value object with validation
    private Department department;
    private Money salary;  // Value object prevents negative
    private final LocalDate hireDate;  // Immutable - no setter
    private String managerId;
    private EmploymentStatus status;
    
    // Constructor validates all initial state
    public Employee(String id, String firstName, String lastName, 
                    Email email, Department department, Money initialSalary) {
        this.id = validateId(id);
        this.firstName = validateName(firstName, "First name");
        this.lastName = validateName(lastName, "Last name");
        this.email = Objects.requireNonNull(email);
        this.department = Objects.requireNonNull(department);
        this.salary = validateSalary(initialSalary);
        this.hireDate = LocalDate.now();
        this.status = EmploymentStatus.ACTIVE;
    }
    
    // Read-only access to identity
    public String getId() { return id; }
    public LocalDate getHireDate() { return hireDate; }
    
    // Derived property
    public String getFullName() {
        return firstName + " " + lastName;
    }
    
    // Domain operations that enforce rules
    public void updateContactInfo(String firstName, String lastName, Email email) {
        this.firstName = validateName(firstName, "First name");
        this.lastName = validateName(lastName, "Last name");
        this.email = Objects.requireNonNull(email);
    }
    
    public void transfer(Department newDepartment, String newManagerId) {
        if (this.status != EmploymentStatus.ACTIVE) {
            throw new InvalidOperationException("Cannot transfer inactive employee");
        }
        this.department = Objects.requireNonNull(newDepartment);
        this.managerId = newManagerId;
    }
    
    public void adjustSalary(Money newSalary, String approvedBy) {
        Money validated = validateSalary(newSalary);
        Money difference = validated.subtract(this.salary);
        
        // Significant changes might need extra approval
        if (difference.abs().isGreaterThan(Money.of(10000))) {
            requireExecutiveApproval(approvedBy);
        }
        
        this.salary = validated;
    }
    
    public void terminate(LocalDate effectiveDate, String reason) {
        if (this.status == EmploymentStatus.TERMINATED) {
            throw new InvalidOperationException("Already terminated");
        }
        if (effectiveDate.isBefore(LocalDate.now())) {
            throw new InvalidOperationException("Cannot backdate termination");
        }
        this.status = EmploymentStatus.TERMINATED;
        // Trigger downstream processes
    }
    
    // Controlled status check - no setter, only through operations
    public boolean isActive() {
        return status == EmploymentStatus.ACTIVE;
    }
    
    // Private validation
    private String validateId(String id) {
        if (id == null || !id.matches("EMP-\\d{6}")) {
            throw new IllegalArgumentException("Invalid employee ID format");
        }
        return id;
    }
    
    private String validateName(String name, String field) {
        if (name == null || name.trim().isEmpty() || name.length() > 100) {
            throw new IllegalArgumentException(field + " is invalid");
        }
        return name.trim();
    }
    
    private Money validateSalary(Money salary) {
        if (salary == null || salary.isNegative()) {
            throw new IllegalArgumentException("Salary must be non-negative");
        }
        if (salary.isGreaterThan(Money.of(10_000_000))) {
            throw new IllegalArgumentException("Salary exceeds maximum limit");
        }
        return salary;
    }
}

Key Improvements

•Identity is immutable — id and hireDate have no setters; they're final and set at construction.
•No raw setters — Instead of setSalary(), we have adjustSalary() with approval tracking.
•Domain operations — transfer() and terminate() are meaningful operations, not data manipulation.
•Value objects — Email and Money types carry their own validation; you can't create invalid ones.
•Status transitions are controlled — You can't just setActive(true); you must go through proper operations.

Mistake 3: Leaking Mutable Objects Through Getters

Similar to exposing collections, this mistake occurs when getters return mutable objects that external code can modify, thereby changing the internal state of your class.

The Problem

Appointment.java (Mutable Leak)
Java
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
// ❌ MUTABLE OBJECT LEAK - Date objects are mutable!
public class Appointment {
    private String title;
    private Date startTime;  // java.util.Date is MUTABLE
    private Date endTime;
    
    public Appointment(String title, Date startTime, Date endTime) {
        this.title = title;
        this.startTime = startTime;  // Stores the reference!
        this.endTime = endTime;
    }
    
    public Date getStartTime() {
        return startTime;  // Returns the internal reference!
    }
    
    public Date getEndTime() {
        return endTime;
    }
    
    public int getDurationMinutes() {
        return (int) ((endTime.getTime() - startTime.getTime()) / 60000);
    }
}
 
// Client code can corrupt appointments
class CalendarHacker {
    public void manipulateAppointment(Appointment apt) {
        // Get the internal Date object
        Date start = apt.getStartTime();
        
        // Modify it directly - changes the Appointment!
        start.setTime(0);  // Now starts at epoch (1970)!
        start.setYear(2050 - 1900);  // Now in the future!
        
        // The Appointment's internal state is corrupted
        // getDurationMinutes() now returns nonsense
    }
    
    public void constructorLeak() {
        Date start = new Date();
        Date end = new Date(start.getTime() + 3600000);
        
        Appointment apt = new Appointment("Meeting", start, end);
        
        // Modify the Date we passed in
        start.setTime(0);  // Corrupts the appointment!
        
        // The appointment now has an invalid startTime
    }
}

Double Exposure

This class is vulnerable on TWO fronts: 1) The constructor stores references to external Date objects, so callers can modify them after construction. 2) The getters return internal references, so callers can modify them after retrieval. Both paths corrupt private state.

The Fix: Defensive Copy or Immutable Types

Appointment.java (Fixed)
Java
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
// ✅ OPTION 1: Defensive copy with mutable Date
public class Appointment {
    private String title;
    private Date startTime;
    private Date endTime;
    
    public Appointment(String title, Date startTime, Date endTime) {
        this.title = title;
        // Defensive copy on INPUT - don't store the caller's reference
        this.startTime = new Date(startTime.getTime());
        this.endTime = new Date(endTime.getTime());
        validate();
    }
    
    public Date getStartTime() {
        // Defensive copy on OUTPUT - don't expose internal reference
        return new Date(startTime.getTime());
    }
    
    public Date getEndTime() {
        return new Date(endTime.getTime());
    }
    
    private void validate() {
        if (endTime.before(startTime)) {
            throw new IllegalArgumentException("End must be after start");
        }
    }
}
 
// ✅ OPTION 2 (BETTER): Use immutable types from java.time
public class Appointment {
    private final String title;
    private final Instant startTime;  // Immutable!
    private final Instant endTime;    // Immutable!
    
    public Appointment(String title, Instant startTime, Instant endTime) {
        this.title = Objects.requireNonNull(title);
        this.startTime = Objects.requireNonNull(startTime);
        this.endTime = Objects.requireNonNull(endTime);
        
        if (endTime.isBefore(startTime)) {
            throw new IllegalArgumentException("End must be after start");
        }
    }
    
    // Safe to return - Instant is immutable, cannot be modified
    public Instant getStartTime() { return startTime; }
    public Instant getEndTime() { return endTime; }
    
    public Duration getDuration() {
        return Duration.between(startTime, endTime);
    }
}

Prefer Immutable Types

The modern java.time package (Instant, LocalDate, LocalDateTime, etc.) provides immutable date/time types. Using them eliminates this entire class of bugs. The same principle applies to other domains: prefer immutable value objects over mutable ones.

Mistake 4: Hiding Business Logic in Getters

Getters should be simple data access. When they contain complex business logic, they create hidden side effects and unpredictable behavior.

The Problem

ShippingOrder.java (Logic in Getter)
Java
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
// ❌ BUSINESS LOGIC HIDING - Getter does way too much
public class ShippingOrder {
    private String orderId;
    private List<OrderItem> items;
    private Address destination;
    private ShippingRate cachedRate;
    
    // This 'getter' is actually a complex operation
    public Money getShippingCost() {
        // Makes external API call!
        if (cachedRate == null || cachedRate.isExpired()) {
            cachedRate = shippingService.calculateRate(
                items, 
                destination, 
                LocalDate.now()
            );
        }
        
        // Applies discounts based on membership
        Money baseCost = cachedRate.getAmount();
        Customer customer = customerService.findById(customerId);
        
        if (customer.isPremiumMember()) {
            baseCost = baseCost.multiply(0.8);  // 20% off
        }
        
        // Applies promotions
        Optional<Promotion> promo = promotionService.getActivePromotion();
        if (promo.isPresent()) {
            baseCost = promo.get().apply(baseCost);
        }
        
        // Updates analytics
        analyticsService.trackShippingCalculation(orderId, baseCost);
        
        return baseCost;
    }
}
 
// Problems this causes:
class OrderProcessor {
    public void processOrder(ShippingOrder order) {
        // Looks like a simple getter call...
        Money shipping1 = order.getShippingCost();
        
        // But calling it again might return different results!
        Money shipping2 = order.getShippingCost();  // Different if promotion expired
        
        // Each call makes API calls, hits databases, tracks analytics
        // Performance disaster when called in a loop
        for (int i = 0; i < 100; i++) {
            doSomethingWith(order.getShippingCost());  // 100 API calls!
        }
    }
}

Hidden Complexity Problems

This 'getter' violates the principle of least surprise: Non-deterministic — Can return different values for the same object state. Side effects — Makes API calls and tracks analytics. Performance trap — Expensive operation disguised as simple property access. Testing nightmare — Requires mocking multiple external services.

The Fix: Separate Calculation from Access

ShippingOrder.java (Fixed)
Java
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
65
66
67
68
69
// ✅ CLEAR SEPARATION - Explicit calculation vs simple access
public class ShippingOrder {
    private String orderId;
    private List<OrderItem> items;
    private Address destination;
    private ShippingQuote approvedQuote;  // Stored result, not cache
    
    // Simple getter - just returns stored data
    public Optional<ShippingQuote> getApprovedQuote() {
        return Optional.ofNullable(approvedQuote);
    }
    
    public Money getShippingCost() {
        if (approvedQuote == null) {
            throw new IllegalStateException(
                "Shipping cost not calculated. Call calculateShipping() first."
            );
        }
        return approvedQuote.getFinalCost();
    }
    
    public boolean hasShippingQuote() {
        return approvedQuote != null;
    }
    
    // Explicit operation - clearly a calculation with external dependencies
    public ShippingQuote calculateShipping(ShippingCalculator calculator) {
        ShippingQuote quote = calculator.calculate(this);
        // Don't auto-apply; let caller decide
        return quote;
    }
    
    // Explicit operation - clearly commits to a quote
    public void applyShippingQuote(ShippingQuote quote) {
        if (!quote.isValid()) {
            throw new QuoteExpiredException("Quote has expired");
        }
        if (!quote.getOrderId().equals(this.orderId)) {
            throw new InvalidQuoteException("Quote is for different order");
        }
        this.approvedQuote = quote;
    }
}
 
// External service handles complex calculation
public class ShippingCalculator {
    private final ShippingService shippingService;
    private final CustomerService customerService;
    private final PromotionService promotionService;
    
    public ShippingQuote calculate(ShippingOrder order) {
        Money baseCost = shippingService.getRate(order);
        
        Customer customer = customerService.findById(order.getCustomerId());
        Money memberDiscount = calculateMemberDiscount(baseCost, customer);
        
        Optional<Promotion> promo = promotionService.getActivePromotion();
        Money promoDiscount = promo.map(p -> p.calculateDiscount(baseCost))
                                   .orElse(Money.ZERO);
        
        return ShippingQuote.builder()
            .orderId(order.getId())
            .baseCost(baseCost)
            .memberDiscount(memberDiscount)
            .promotionalDiscount(promoDiscount)
            .validUntil(Instant.now().plus(Duration.ofHours(24)))
            .build();
    }
}

Benefits of Separation

•Getters are predictable — getShippingCost() always returns the same stored value for the same order state.
•Operations are explicit — calculateShipping() clearly indicates it's doing work with external dependencies.
•Dependencies are visible — The calculator requires services, making testing straightforward.
•Caching is controlled — The quote is explicitly stored and has explicit validity.

Mistake 5: Allowing Inconsistent Object State

When setters can be called independently, objects can end up in states that violate business rules—combinations of field values that should be impossible.

The Problem

DateRange.java (Inconsistent State)
Java
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
// ❌ INVARIANT VIOLATIONS - Object can enter invalid states
public class DateRange {
    private LocalDate startDate;
    private LocalDate endDate;
    
    public DateRange(LocalDate start, LocalDate end) {
        this.startDate = start;
        this.endDate = end;
        // Validation in constructor is good, but...
        if (end.isBefore(start)) {
            throw new IllegalArgumentException("End must be after start");
        }
    }
    
    // These setters allow invariant violation!
    public void setStartDate(LocalDate start) {
        this.startDate = start;
        // What if start is now after endDate?
    }
    
    public void setEndDate(LocalDate end) {
        this.endDate = end;
        // What if end is now before startDate?
    }
    
    public long getDaysBetween() {
        // This might return negative if invariant is violated!
        return ChronoUnit.DAYS.between(startDate, endDate);
    }
}
 
// Watch invariant violation in action
class Problem {
    public void breakInvariant(DateRange range) {
        // Valid initial: Jan 1 to Jan 31
        
        // Set end to Jan 15
        range.setEndDate(LocalDate.of(2024, 1, 15));  // Still valid
        
        // Now set start to Jan 20
        range.setStartDate(LocalDate.of(2024, 1, 20));  // BROKEN!
        
        // Now start (Jan 20) is AFTER end (Jan 15)
        long days = range.getDaysBetween();  // Returns -5!
    }
}

The Fix: Immutable or Atomic Updates

DateRange.java (Fixed)
Java
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
65
66
67
// ✅ OPTION 1: Immutable object - changes create new instances
public final class DateRange {
    private final LocalDate startDate;
    private final LocalDate endDate;
    
    public DateRange(LocalDate start, LocalDate end) {
        if (start == null || end == null) {
            throw new IllegalArgumentException("Dates cannot be null");
        }
        if (end.isBefore(start)) {
            throw new IllegalArgumentException("End must be after start");
        }
        this.startDate = start;
        this.endDate = end;
    }
    
    // No setters - return new validated instances instead
    public DateRange withStartDate(LocalDate newStart) {
        return new DateRange(newStart, this.endDate);  // Validates in constructor
    }
    
    public DateRange withEndDate(LocalDate newEnd) {
        return new DateRange(this.startDate, newEnd);  // Validates in constructor
    }
    
    public DateRange extendBy(long days) {
        return new DateRange(this.startDate, this.endDate.plusDays(days));
    }
    
    // Safe to expose - fields are immutable
    public LocalDate getStartDate() { return startDate; }
    public LocalDate getEndDate() { return endDate; }
    
    public long getDaysBetween() {
        return ChronoUnit.DAYS.between(startDate, endDate);  // Always valid
    }
}
 
// ✅ OPTION 2: Atomic update method when mutability needed
public class MutableDateRange {
    private LocalDate startDate;
    private LocalDate endDate;
    
    public MutableDateRange(LocalDate start, LocalDate end) {
        setRange(start, end);  // Use atomic setter
    }
    
    // Only way to change dates - must provide both, validates together
    public synchronized void setRange(LocalDate start, LocalDate end) {
        if (start == null || end == null) {
            throw new IllegalArgumentException("Dates cannot be null");
        }
        if (end.isBefore(start)) {
            throw new IllegalArgumentException("End must be after start");
        }
        this.startDate = start;
        this.endDate = end;
    }
    
    // Read-only access
    public LocalDate getStartDate() { return startDate; }
    public LocalDate getEndDate() { return endDate; }
    
    // Never allow individual field changes
    // NO setStartDate()
    // NO setEndDate()
}

Invariant Protection Strategies

Immutability (Option 1) eliminates the problem entirely—objects are always valid because they can't change. Atomic updates (Option 2) applies when you need mutability—related fields must be updated together through a single validated method.

Summary: Encapsulation Mistakes to Avoid

Let's consolidate the five major encapsulation mistakes and their solutions:

Encapsulation Anti-Patterns Summary
Mistake	Symptom	Fix
Exposing internal collections	Getters return `List`, `Set`, `Map` directly	Return unmodifiable views, defensive copies, or streams
Mechanical getter/setter generation	Every field has public get/set, no validation	Remove unnecessary accessors, use domain operations
Leaking mutable objects	Returning Date, arrays, or other mutable types	Use defensive copies or prefer immutable types
Business logic in getters	Getters make API calls, have side effects	Separate calculation methods from data access
Inconsistent state through setters	Individual setters for related fields	Use immutable objects or atomic update methods

Key Takeaways

•Private fields are necessary but not sufficient — You can still leak encapsulation through what you return.
•Getters and setters are not free — Each one is a commitment to an interface; add them deliberately.
•Mutable objects require defensive copying — Or better yet, use immutable alternatives.
•Getters should be boring — Simple data access, no surprises, no side effects.
•Related fields need coordinated updates — Validate invariants across all changes.

What's next:

Now that we can recognize encapsulation mistakes, the next page covers how to systematically refactor poorly encapsulated code. We'll walk through the transformation process step by step, showing how to safely improve encapsulation in existing systems.

Page Complete

You can now identify the most common encapsulation violations in code. Use this knowledge during code reviews to catch these issues early, and when examining your own designs to prevent these mistakes before they're written.

2 / 4

Loading learning content...

System Design (HLD)Encapsulation in Practice

Encapsulation in Practice

LevelIntermediate

Duration60 mins

TopicEncapsulation in Practice

2 / 4

Common Encapsulation Mistakes

Learning from Mistakes

Understanding these common mistakes is essential because:

You'll encounter them — Legacy code and even new code from less experienced developers contains these patterns
You'll be tempted by them — Some violations feel convenient in the moment
You need to fix them — Refactoring poor encapsulation requires recognizing it first

What You Will Learn

Mistake 1: Exposing Internal Collections

The Problem

Team.java (Broken Encapsulation)
Java
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
// ❌ ENCAPSULATION LEAK - Internal collection exposed
public class Team {
    private String name;
    private List<Player> players;  // Private... but not really
    
    public Team(String name) {
        this.name = name;
        this.players = new ArrayList<>();
    }
    
    // This looks harmless but completely breaks encapsulation
    public List<Player> getPlayers() {
        return players;  // Returns the ACTUAL internal list!
    }
    
    public void addPlayer(Player player) {
        if (players.size() >= 25) {
            throw new TeamFullException("Roster limit reached");
        }
        if (player.getSalary() > getSalaryCap()) {
            throw new SalaryCapException("Would exceed salary cap");
        }
        players.add(player);
    }
}
 
// External code can now bypass ALL business rules
class SneakyClient {
    public void breakTheRules(Team team) {
        List<Player> roster = team.getPlayers();
        
        // Add 100 players, ignoring roster limits
        for (int i = 0; i < 100; i++) {
            roster.add(new Player("Player" + i, 50_000_000));
        }
        
        // Clear the entire roster
        roster.clear();
        
        // Add a null player (causes NPEs later)
        roster.add(null);
        
        // Replace with a completely different list implementation
        // that behaves unexpectedly
        roster.sort(null);  // Changes internal order
    }
}

Why This Happens

The Fix: Defensive Copies or Unmodifiable Views

Team.java (Fixed)
Java
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
// ✅ PROPER ENCAPSULATION - Collection protected
public class Team {
    private String name;
    private final List<Player> players;
    
    public Team(String name) {
        this.name = name;
        this.players = new ArrayList<>();
    }
    
    // Option 1: Return unmodifiable view
    public List<Player> getPlayers() {
        return Collections.unmodifiableList(players);
    }
    
    // Option 2: Return defensive copy (safer but more memory)
    public List<Player> getPlayersCopy() {
        return new ArrayList<>(players);
    }
    
    // Option 3: Return stream (can't modify, encourages functional style)
    public Stream<Player> players() {
        return players.stream();
    }
    
    // All modifications go through controlled methods
    public void addPlayer(Player player) {
        Objects.requireNonNull(player, "Player cannot be null");
        if (players.size() >= 25) {
            throw new TeamFullException("Roster limit reached");
        }
        if (player.getSalary() > getSalaryCap()) {
            throw new SalaryCapException("Would exceed salary cap");
        }
        players.add(player);
    }
    
    public boolean removePlayer(String playerId) {
        return players.removeIf(p -> p.getId().equals(playerId));
    }
}

Choosing the Right Protection Strategy

•Unmodifiable view — Lightweight, reflects current state, but client might cache and see changes. Best for 'read current snapshot' cases.
•Defensive copy — Isolated from changes, but costs memory proportional to collection size. Best when client needs stable data for extended processing.
•Stream — Encourages functional processing, naturally discourages storing. Best for clients who want to filter/map/reduce.

Mistake 2: Mechanical Getter/Setter Generation

The Anti-Pattern

Employee.java (False Encapsulation)
Java
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
// ❌ FAKE ENCAPSULATION - Every field exposed through accessors
public class Employee {
    private String id;
    private String firstName;
    private String lastName;
    private String email;
    private String department;
    private double salary;
    private Date hireDate;
    private String managerId;
    private boolean isActive;
    
    // Lombok @Data or IDE-generated accessors for ALL fields
    public String getId() { return id; }
    public void setId(String id) { this.id = id; }
    
    public String getFirstName() { return firstName; }
    public void setFirstName(String firstName) { this.firstName = firstName; }
    
    public String getLastName() { return lastName; }
    public void setLastName(String lastName) { this.lastName = lastName; }
    
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }  // No validation!
    
    public double getSalary() { return salary; }
    public void setSalary(double salary) { this.salary = salary; }  // Negative salary? Sure!
    
    public Date getHireDate() { return hireDate; }
    public void setHireDate(Date hireDate) { this.hireDate = hireDate; }  // Future date? Fine!
    
    public boolean isActive() { return isActive; }
    public void setActive(boolean active) { this.isActive = active; }  // No termination process!
    
    // ... all the same for remaining fields
}
 
// Client code does whatever it wants
class HRSystem {
    public void processPayroll(Employee emp) {
        // Setting salary to negative steals money?
        emp.setSalary(-50000);
        
        // Changing hire date for backdated benefits?
        emp.setHireDate(Date.from(Instant.EPOCH));
        
        // Reactivating terminated employees?
        emp.setActive(true);
        
        // Changing employee ID breaks database relations
        emp.setId("FAKE_ID");
    }
}

The Core Problem

The Fix: Intentional Accessors Based on Domain Needs

Employee.java (Proper Encapsulation)
Java
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
// ✅ INTENTIONAL ENCAPSULATION - Only expose what's needed
public final class Employee {
    private final String id;  // Immutable - no setter
    private String firstName;
    private String lastName;
    private Email email;  // Value object with validation
    private Department department;
    private Money salary;  // Value object prevents negative
    private final LocalDate hireDate;  // Immutable - no setter
    private String managerId;
    private EmploymentStatus status;
    
    // Constructor validates all initial state
    public Employee(String id, String firstName, String lastName, 
                    Email email, Department department, Money initialSalary) {
        this.id = validateId(id);
        this.firstName = validateName(firstName, "First name");
        this.lastName = validateName(lastName, "Last name");
        this.email = Objects.requireNonNull(email);
        this.department = Objects.requireNonNull(department);
        this.salary = validateSalary(initialSalary);
        this.hireDate = LocalDate.now();
        this.status = EmploymentStatus.ACTIVE;
    }
    
    // Read-only access to identity
    public String getId() { return id; }
    public LocalDate getHireDate() { return hireDate; }
    
    // Derived property
    public String getFullName() {
        return firstName + " " + lastName;
    }
    
    // Domain operations that enforce rules
    public void updateContactInfo(String firstName, String lastName, Email email) {
        this.firstName = validateName(firstName, "First name");
        this.lastName = validateName(lastName, "Last name");
        this.email = Objects.requireNonNull(email);
    }
    
    public void transfer(Department newDepartment, String newManagerId) {
        if (this.status != EmploymentStatus.ACTIVE) {
            throw new InvalidOperationException("Cannot transfer inactive employee");
        }
        this.department = Objects.requireNonNull(newDepartment);
        this.managerId = newManagerId;
    }
    
    public void adjustSalary(Money newSalary, String approvedBy) {
        Money validated = validateSalary(newSalary);
        Money difference = validated.subtract(this.salary);
        
        // Significant changes might need extra approval
        if (difference.abs().isGreaterThan(Money.of(10000))) {
            requireExecutiveApproval(approvedBy);
        }
        
        this.salary = validated;
    }
    
    public void terminate(LocalDate effectiveDate, String reason) {
        if (this.status == EmploymentStatus.TERMINATED) {
            throw new InvalidOperationException("Already terminated");
        }
        if (effectiveDate.isBefore(LocalDate.now())) {
            throw new InvalidOperationException("Cannot backdate termination");
        }
        this.status = EmploymentStatus.TERMINATED;
        // Trigger downstream processes
    }
    
    // Controlled status check - no setter, only through operations
    public boolean isActive() {
        return status == EmploymentStatus.ACTIVE;
    }
    
    // Private validation
    private String validateId(String id) {
        if (id == null || !id.matches("EMP-\\d{6}")) {
            throw new IllegalArgumentException("Invalid employee ID format");
        }
        return id;
    }
    
    private String validateName(String name, String field) {
        if (name == null || name.trim().isEmpty() || name.length() > 100) {
            throw new IllegalArgumentException(field + " is invalid");
        }
        return name.trim();
    }
    
    private Money validateSalary(Money salary) {
        if (salary == null || salary.isNegative()) {
            throw new IllegalArgumentException("Salary must be non-negative");
        }
        if (salary.isGreaterThan(Money.of(10_000_000))) {
            throw new IllegalArgumentException("Salary exceeds maximum limit");
        }
        return salary;
    }
}

Key Improvements

•Identity is immutable — id and hireDate have no setters; they're final and set at construction.
•No raw setters — Instead of setSalary(), we have adjustSalary() with approval tracking.
•Domain operations — transfer() and terminate() are meaningful operations, not data manipulation.
•Value objects — Email and Money types carry their own validation; you can't create invalid ones.
•Status transitions are controlled — You can't just setActive(true); you must go through proper operations.

Mistake 3: Leaking Mutable Objects Through Getters

Similar to exposing collections, this mistake occurs when getters return mutable objects that external code can modify, thereby changing the internal state of your class.

The Problem

Appointment.java (Mutable Leak)
Java
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
// ❌ MUTABLE OBJECT LEAK - Date objects are mutable!
public class Appointment {
    private String title;
    private Date startTime;  // java.util.Date is MUTABLE
    private Date endTime;
    
    public Appointment(String title, Date startTime, Date endTime) {
        this.title = title;
        this.startTime = startTime;  // Stores the reference!
        this.endTime = endTime;
    }
    
    public Date getStartTime() {
        return startTime;  // Returns the internal reference!
    }
    
    public Date getEndTime() {
        return endTime;
    }
    
    public int getDurationMinutes() {
        return (int) ((endTime.getTime() - startTime.getTime()) / 60000);
    }
}
 
// Client code can corrupt appointments
class CalendarHacker {
    public void manipulateAppointment(Appointment apt) {
        // Get the internal Date object
        Date start = apt.getStartTime();
        
        // Modify it directly - changes the Appointment!
        start.setTime(0);  // Now starts at epoch (1970)!
        start.setYear(2050 - 1900);  // Now in the future!
        
        // The Appointment's internal state is corrupted
        // getDurationMinutes() now returns nonsense
    }
    
    public void constructorLeak() {
        Date start = new Date();
        Date end = new Date(start.getTime() + 3600000);
        
        Appointment apt = new Appointment("Meeting", start, end);
        
        // Modify the Date we passed in
        start.setTime(0);  // Corrupts the appointment!
        
        // The appointment now has an invalid startTime
    }
}

Double Exposure

The Fix: Defensive Copy or Immutable Types

Appointment.java (Fixed)
Java
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
// ✅ OPTION 1: Defensive copy with mutable Date
public class Appointment {
    private String title;
    private Date startTime;
    private Date endTime;
    
    public Appointment(String title, Date startTime, Date endTime) {
        this.title = title;
        // Defensive copy on INPUT - don't store the caller's reference
        this.startTime = new Date(startTime.getTime());
        this.endTime = new Date(endTime.getTime());
        validate();
    }
    
    public Date getStartTime() {
        // Defensive copy on OUTPUT - don't expose internal reference
        return new Date(startTime.getTime());
    }
    
    public Date getEndTime() {
        return new Date(endTime.getTime());
    }
    
    private void validate() {
        if (endTime.before(startTime)) {
            throw new IllegalArgumentException("End must be after start");
        }
    }
}
 
// ✅ OPTION 2 (BETTER): Use immutable types from java.time
public class Appointment {
    private final String title;
    private final Instant startTime;  // Immutable!
    private final Instant endTime;    // Immutable!
    
    public Appointment(String title, Instant startTime, Instant endTime) {
        this.title = Objects.requireNonNull(title);
        this.startTime = Objects.requireNonNull(startTime);
        this.endTime = Objects.requireNonNull(endTime);
        
        if (endTime.isBefore(startTime)) {
            throw new IllegalArgumentException("End must be after start");
        }
    }
    
    // Safe to return - Instant is immutable, cannot be modified
    public Instant getStartTime() { return startTime; }
    public Instant getEndTime() { return endTime; }
    
    public Duration getDuration() {
        return Duration.between(startTime, endTime);
    }
}

Prefer Immutable Types

Mistake 4: Hiding Business Logic in Getters

Getters should be simple data access. When they contain complex business logic, they create hidden side effects and unpredictable behavior.

The Problem

ShippingOrder.java (Logic in Getter)
Java
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
// ❌ BUSINESS LOGIC HIDING - Getter does way too much
public class ShippingOrder {
    private String orderId;
    private List<OrderItem> items;
    private Address destination;
    private ShippingRate cachedRate;
    
    // This 'getter' is actually a complex operation
    public Money getShippingCost() {
        // Makes external API call!
        if (cachedRate == null || cachedRate.isExpired()) {
            cachedRate = shippingService.calculateRate(
                items, 
                destination, 
                LocalDate.now()
            );
        }
        
        // Applies discounts based on membership
        Money baseCost = cachedRate.getAmount();
        Customer customer = customerService.findById(customerId);
        
        if (customer.isPremiumMember()) {
            baseCost = baseCost.multiply(0.8);  // 20% off
        }
        
        // Applies promotions
        Optional<Promotion> promo = promotionService.getActivePromotion();
        if (promo.isPresent()) {
            baseCost = promo.get().apply(baseCost);
        }
        
        // Updates analytics
        analyticsService.trackShippingCalculation(orderId, baseCost);
        
        return baseCost;
    }
}
 
// Problems this causes:
class OrderProcessor {
    public void processOrder(ShippingOrder order) {
        // Looks like a simple getter call...
        Money shipping1 = order.getShippingCost();
        
        // But calling it again might return different results!
        Money shipping2 = order.getShippingCost();  // Different if promotion expired
        
        // Each call makes API calls, hits databases, tracks analytics
        // Performance disaster when called in a loop
        for (int i = 0; i < 100; i++) {
            doSomethingWith(order.getShippingCost());  // 100 API calls!
        }
    }
}

Hidden Complexity Problems

The Fix: Separate Calculation from Access

ShippingOrder.java (Fixed)
Java
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
65
66
67
68
69
// ✅ CLEAR SEPARATION - Explicit calculation vs simple access
public class ShippingOrder {
    private String orderId;
    private List<OrderItem> items;
    private Address destination;
    private ShippingQuote approvedQuote;  // Stored result, not cache
    
    // Simple getter - just returns stored data
    public Optional<ShippingQuote> getApprovedQuote() {
        return Optional.ofNullable(approvedQuote);
    }
    
    public Money getShippingCost() {
        if (approvedQuote == null) {
            throw new IllegalStateException(
                "Shipping cost not calculated. Call calculateShipping() first."
            );
        }
        return approvedQuote.getFinalCost();
    }
    
    public boolean hasShippingQuote() {
        return approvedQuote != null;
    }
    
    // Explicit operation - clearly a calculation with external dependencies
    public ShippingQuote calculateShipping(ShippingCalculator calculator) {
        ShippingQuote quote = calculator.calculate(this);
        // Don't auto-apply; let caller decide
        return quote;
    }
    
    // Explicit operation - clearly commits to a quote
    public void applyShippingQuote(ShippingQuote quote) {
        if (!quote.isValid()) {
            throw new QuoteExpiredException("Quote has expired");
        }
        if (!quote.getOrderId().equals(this.orderId)) {
            throw new InvalidQuoteException("Quote is for different order");
        }
        this.approvedQuote = quote;
    }
}
 
// External service handles complex calculation
public class ShippingCalculator {
    private final ShippingService shippingService;
    private final CustomerService customerService;
    private final PromotionService promotionService;
    
    public ShippingQuote calculate(ShippingOrder order) {
        Money baseCost = shippingService.getRate(order);
        
        Customer customer = customerService.findById(order.getCustomerId());
        Money memberDiscount = calculateMemberDiscount(baseCost, customer);
        
        Optional<Promotion> promo = promotionService.getActivePromotion();
        Money promoDiscount = promo.map(p -> p.calculateDiscount(baseCost))
                                   .orElse(Money.ZERO);
        
        return ShippingQuote.builder()
            .orderId(order.getId())
            .baseCost(baseCost)
            .memberDiscount(memberDiscount)
            .promotionalDiscount(promoDiscount)
            .validUntil(Instant.now().plus(Duration.ofHours(24)))
            .build();
    }
}

Benefits of Separation

•Getters are predictable — getShippingCost() always returns the same stored value for the same order state.
•Operations are explicit — calculateShipping() clearly indicates it's doing work with external dependencies.
•Dependencies are visible — The calculator requires services, making testing straightforward.
•Caching is controlled — The quote is explicitly stored and has explicit validity.

Mistake 5: Allowing Inconsistent Object State

When setters can be called independently, objects can end up in states that violate business rules—combinations of field values that should be impossible.

The Problem

DateRange.java (Inconsistent State)
Java
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
// ❌ INVARIANT VIOLATIONS - Object can enter invalid states
public class DateRange {
    private LocalDate startDate;
    private LocalDate endDate;
    
    public DateRange(LocalDate start, LocalDate end) {
        this.startDate = start;
        this.endDate = end;
        // Validation in constructor is good, but...
        if (end.isBefore(start)) {
            throw new IllegalArgumentException("End must be after start");
        }
    }
    
    // These setters allow invariant violation!
    public void setStartDate(LocalDate start) {
        this.startDate = start;
        // What if start is now after endDate?
    }
    
    public void setEndDate(LocalDate end) {
        this.endDate = end;
        // What if end is now before startDate?
    }
    
    public long getDaysBetween() {
        // This might return negative if invariant is violated!
        return ChronoUnit.DAYS.between(startDate, endDate);
    }
}
 
// Watch invariant violation in action
class Problem {
    public void breakInvariant(DateRange range) {
        // Valid initial: Jan 1 to Jan 31
        
        // Set end to Jan 15
        range.setEndDate(LocalDate.of(2024, 1, 15));  // Still valid
        
        // Now set start to Jan 20
        range.setStartDate(LocalDate.of(2024, 1, 20));  // BROKEN!
        
        // Now start (Jan 20) is AFTER end (Jan 15)
        long days = range.getDaysBetween();  // Returns -5!
    }
}

The Fix: Immutable or Atomic Updates

DateRange.java (Fixed)
Java
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
65
66
67
// ✅ OPTION 1: Immutable object - changes create new instances
public final class DateRange {
    private final LocalDate startDate;
    private final LocalDate endDate;
    
    public DateRange(LocalDate start, LocalDate end) {
        if (start == null || end == null) {
            throw new IllegalArgumentException("Dates cannot be null");
        }
        if (end.isBefore(start)) {
            throw new IllegalArgumentException("End must be after start");
        }
        this.startDate = start;
        this.endDate = end;
    }
    
    // No setters - return new validated instances instead
    public DateRange withStartDate(LocalDate newStart) {
        return new DateRange(newStart, this.endDate);  // Validates in constructor
    }
    
    public DateRange withEndDate(LocalDate newEnd) {
        return new DateRange(this.startDate, newEnd);  // Validates in constructor
    }
    
    public DateRange extendBy(long days) {
        return new DateRange(this.startDate, this.endDate.plusDays(days));
    }
    
    // Safe to expose - fields are immutable
    public LocalDate getStartDate() { return startDate; }
    public LocalDate getEndDate() { return endDate; }
    
    public long getDaysBetween() {
        return ChronoUnit.DAYS.between(startDate, endDate);  // Always valid
    }
}
 
// ✅ OPTION 2: Atomic update method when mutability needed
public class MutableDateRange {
    private LocalDate startDate;
    private LocalDate endDate;
    
    public MutableDateRange(LocalDate start, LocalDate end) {
        setRange(start, end);  // Use atomic setter
    }
    
    // Only way to change dates - must provide both, validates together
    public synchronized void setRange(LocalDate start, LocalDate end) {
        if (start == null || end == null) {
            throw new IllegalArgumentException("Dates cannot be null");
        }
        if (end.isBefore(start)) {
            throw new IllegalArgumentException("End must be after start");
        }
        this.startDate = start;
        this.endDate = end;
    }
    
    // Read-only access
    public LocalDate getStartDate() { return startDate; }
    public LocalDate getEndDate() { return endDate; }
    
    // Never allow individual field changes
    // NO setStartDate()
    // NO setEndDate()
}

Invariant Protection Strategies

Summary: Encapsulation Mistakes to Avoid

Let's consolidate the five major encapsulation mistakes and their solutions:

Encapsulation Anti-Patterns Summary
Mistake	Symptom	Fix
Exposing internal collections	Getters return `List`, `Set`, `Map` directly	Return unmodifiable views, defensive copies, or streams
Mechanical getter/setter generation	Every field has public get/set, no validation	Remove unnecessary accessors, use domain operations
Leaking mutable objects	Returning Date, arrays, or other mutable types	Use defensive copies or prefer immutable types
Business logic in getters	Getters make API calls, have side effects	Separate calculation methods from data access
Inconsistent state through setters	Individual setters for related fields	Use immutable objects or atomic update methods

Key Takeaways

•Private fields are necessary but not sufficient — You can still leak encapsulation through what you return.
•Getters and setters are not free — Each one is a commitment to an interface; add them deliberately.
•Mutable objects require defensive copying — Or better yet, use immutable alternatives.
•Getters should be boring — Simple data access, no surprises, no side effects.
•Related fields need coordinated updates — Validate invariants across all changes.

What's next:

Page Complete

2 / 4