System Design (LLD)Access Modifiers and Visibility

Access Modifiers and Visibility

LevelBeginner

Duration60 mins

TopicAccess Modifiers and Visibility

2 / 4

Private — Accessible Within Class Only

The Foundation of Encapsulation

If public access is an open door, private access is a locked vault. A private member is completely hidden from the outside world — only the class that defines it can see or use it. Not subclasses, not other classes in the same package, not even the closest collaborators. Only the class itself.

This extreme restriction might seem limiting, but it's actually liberating. Private access gives you absolute freedom to change internal implementation without affecting any external code. It's the cornerstone of encapsulation — one of the four pillars of object-oriented programming.

What You Will Learn

By the end of this page, you will understand: • What private access means and how it works across languages • Why private is the default choice for most class members • How private access enables safe refactoring and evolution • The relationship between private access and encapsulation • Real-world patterns that rely on private members • Common mistakes and how to avoid them

Understanding Private Access

The private access modifier creates the most restrictive visibility scope possible. A private member is only accessible within the class where it's declared. No exceptions.

The Private Visibility Rule:

When a member is declared private:

What Private Access Means

•Only the declaring class can access it — code inside the class's curly braces
•Subclasses cannot access it — even direct children that inherit from the class
•Same-package classes cannot access it — package boundaries don't grant access
•External client code cannot access it — completely invisible to users of the class
•Reflection can access it — but only with explicit permission-bypassing (a deliberate violation)

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
public class BankAccount {
    // Private fields — internal state, invisible outside
    private String accountNumber;
    private double balance;
    private List<Transaction> transactionHistory;
    
    // Private constant — internal configuration
    private static final double OVERDRAFT_LIMIT = -1000.0;
    
    // Public constructor — the only way to create an account
    public BankAccount(String accountNumber, double initialDeposit) {
        this.accountNumber = accountNumber;
        this.balance = initialDeposit;
        this.transactionHistory = new ArrayList<>();
        recordTransaction("INITIAL_DEPOSIT", initialDeposit);
    }
    
    // Public method — part of the class's API
    public void deposit(double amount) {
        validatePositiveAmount(amount);  // Calling private method
        this.balance += amount;          // Accessing private field
        recordTransaction("DEPOSIT", amount);
    }
    
    public boolean withdraw(double amount) {
        validatePositiveAmount(amount);
        if (this.balance - amount < OVERDRAFT_LIMIT) {
            return false;  // Accessing private constant
        }
        this.balance -= amount;
        recordTransaction("WITHDRAWAL", -amount);
        return true;
    }
    
    // Public getter — controlled read-only access to private state
    public double getBalance() {
        return this.balance;
    }
    
    // Private helper method — internal logic, not exposed
    private void validatePositiveAmount(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Amount must be positive");
        }
    }
    
    // Private helper method — internal record keeping
    private void recordTransaction(String type, double amount) {
        transactionHistory.add(new Transaction(type, amount, Instant.now()));
    }
}
 
// Outside the class — what's accessible?
public class BankingService {
    public void processPayment(BankAccount account, double amount) {
        // ✅ Can call public methods
        account.deposit(amount);
        double balance = account.getBalance();
        
        // ❌ COMPILE ERROR: Cannot access private members
        // account.balance = 1000000;           // Cannot access field
        // account.accountNumber = "HACKED";    // Cannot access field
        // account.validatePositiveAmount(50);  // Cannot access method
        // account.transactionHistory.clear();  // Cannot access field
    }
}

Language Syntax Variations

Private access syntax varies across languages:

• Java/C#: private void method() — explicit keyword • C++: private: section in class declaration • Python: _single_underscore (convention), __double_underscore (name mangling) • TypeScript: private keyword or # prefix for hard private • Kotlin: private keyword • JavaScript: # prefix for class fields (ES2022+)

Why Private Should Be Your Default

One of the most important design principles in object-oriented programming is this: start with private, open up only when necessary. This isn't just convention — it's a fundamental strategy for building maintainable software.

The Default-to-Private Philosophy:

Benefits of Private-by-Default

•Freedom to change — Private members can be renamed, retyped, removed, or restructured without affecting any external code. This enables fearless refactoring.
•Reduced cognitive load — When reading a class, you know private members are purely internal. You don't need to trace their usage across the codebase.
•Smaller API surface — The less you expose, the simpler your class is to understand and use. Private helps you maintain a minimal public interface.
•Enforced invariants — By making state private and controlling access through methods, you can ensure your object is never in an invalid state.
•Clear responsibility — Private members signal intent: 'This is implementation detail, not a feature.' Other developers won't accidentally depend on it.
•Easier testing — Counterintuitively, private makes testing easier. You test public behavior, not private implementation. Tests become more stable.

Wrong: Public by Default

•Fields are public for 'convenience'
•All methods are public 'just in case'
•Internal helpers are exposed
•Changing anything risks breaking clients
•The class's true API is unclear

Right: Private by Default

•All fields are private (always)
•Methods start private until needed publicly
•Helpers remain hidden
•Free to refactor internals anytime
•Public methods clearly define the API

The "Need to Know" Principle

Ask yourself: "Does code outside this class need to access this member?" If the answer isn't a clear yes, make it private. You can always loosen access later — but once something is public and in use, you can't easily take it back.

Private Access and Encapsulation

Encapsulation is the bundling of data and the methods that operate on that data within a single unit (a class), while restricting direct access to some of the object's components. Private access is the primary mechanism for achieving encapsulation.

The Encapsulation Equation:

Encapsulation = Private State + Public Behavior

By making fields private and providing controlled access through methods, you create a protective barrier around your object's internal state. This barrier has profound implications for software quality.

How Private Access Enables Encapsulation
Encapsulation Goal	How Private Achieves It	Real-World Analogy
Hide implementation details	Private members are invisible to external code	Car hides engine internals behind pedals and steering wheel
Control state changes	State can only change through public methods with validation	ATM validates PIN before allowing withdrawals
Ensure invariants	Methods maintain rules that fields alone cannot	Thermostat ensures temp never exceeds safety limit
Enable evolution	Internal changes don't affect external code	Phone updates OS without changing how you use apps
Reduce complexity	External code sees only what it needs	TV remote hides circuit complexity behind simple buttons

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
// UNENCAPSULATED: Public state, no protection
public class BadTemperatureSensor {
    public double temperatureCelsius;  // Anyone can set any value!
    
    public double getTemperatureFahrenheit() {
        return temperatureCelsius * 9/5 + 32;
    }
}
 
// What can go wrong:
BadTemperatureSensor sensor = new BadTemperatureSensor();
sensor.temperatureCelsius = -500;  // Below absolute zero? No problem!
sensor.temperatureCelsius = Double.NaN;  // Not a number? Sure!
// System now has corrupt, meaningless data
 
// ENCAPSULATED: Private state, controlled access
public class TemperatureSensor {
    // Absolute zero in Celsius — physical minimum
    private static final double ABSOLUTE_ZERO = -273.15;
    private static final double MAX_TEMP = 1000.0;
    
    // Private state — only this class can modify it
    private double temperatureCelsius;
    private Instant lastReading;
    
    // Constructor validates initial state
    public TemperatureSensor(double initialTemp) {
        setTemperature(initialTemp);  // Uses validation
    }
    
    // Controlled mutation through public method
    public void setTemperature(double celsius) {
        if (celsius < ABSOLUTE_ZERO) {
            throw new IllegalArgumentException(
                "Temperature cannot be below absolute zero: " + celsius);
        }
        if (celsius > MAX_TEMP) {
            throw new IllegalArgumentException(
                "Temperature exceeds sensor maximum: " + celsius);
        }
        if (Double.isNaN(celsius) || Double.isInfinite(celsius)) {
            throw new IllegalArgumentException(
                "Temperature must be a valid number");
        }
        this.temperatureCelsius = celsius;
        this.lastReading = Instant.now();
    }
    
    // Read-only access to state
    public double getTemperatureCelsius() {
        return temperatureCelsius;
    }
    
    public double getTemperatureFahrenheit() {
        return temperatureCelsius * 9.0/5.0 + 32.0;
    }
    
    public double getTemperatureKelvin() {
        return temperatureCelsius - ABSOLUTE_ZERO;
    }
    
    public Instant getLastReadingTime() {
        return lastReading;
    }
}
 
// Now invalid states are IMPOSSIBLE:
TemperatureSensor sensor = new TemperatureSensor(25.0);  // Valid
sensor.setTemperature(-500);  // Throws exception immediately!
// The sensor can NEVER hold an invalid temperature

The Object as a State Machine

When you encapsulate with private access, you transform your class from a mere data container into a state machine. Each public method is a state transition that the class controls. Invalid transitions are rejected. This model makes reasoning about your code much easier — you can prove invariants hold because only your code can change state.

Private Members and Inheritance

One aspect of private access that often confuses developers is its interaction with inheritance. Private members are NOT inherited by subclasses. They exist in the parent class but are completely invisible to children.

This is by design. If subclasses could access private members, they'd become dependent on parent implementation details, creating tight coupling and fragile hierarchies.

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
public class Vehicle {
    // Private state — NOT accessible to subclasses
    private String vin;
    private double fuelLevel;
    
    // Protected state — accessible to subclasses
    protected String model;
    
    public Vehicle(String vin, String model) {
        this.vin = vin;
        this.model = model;
        this.fuelLevel = 0;
    }
    
    // Private method — NOT accessible to subclasses
    private void logMaintenance(String action) {
        System.out.println("[" + vin + "] " + action);
    }
    
    // Public method that uses private internals
    public void refuel(double gallons) {
        this.fuelLevel += gallons;
        logMaintenance("Refueled: " + gallons + " gallons");
    }
    
    // Protected method — CAN be overridden by subclasses
    protected double calculateRange() {
        return fuelLevel * 25;  // 25 miles per gallon default
    }
}
 
public class ElectricCar extends Vehicle {
    private double batteryLevel;
    
    public ElectricCar(String vin, String model) {
        super(vin, model);
        this.batteryLevel = 100;
    }
    
    @Override
    protected double calculateRange() {
        // ✅ Can access protected members
        System.out.println("Calculating range for " + model);
        
        // ❌ COMPILE ERROR: Cannot access private members
        // System.out.println("VIN: " + vin);           // Error!
        // double fuel = fuelLevel;                      // Error!
        // logMaintenance("Range check");               // Error!
        
        return batteryLevel * 3;  // 3 miles per percent
    }
    
    public void charge(double percent) {
        this.batteryLevel = Math.min(100, batteryLevel + percent);
        
        // If we need to log, we must use public/protected methods from parent
        // or define our own logging
    }
}

Why Can't Subclasses Access Private Members?

This restriction serves encapsulation across the inheritance boundary:

Reasons for Private Inheritance Boundary

•Parent can evolve independently — Parents can change private members without breaking any subclass. Imagine having 50 subclasses depending on a private field — changing it would be a nightmare.
•Subclasses stay loosely coupled — Children don't know or care how parents implement things internally. They interact through the public/protected contract.
•Encapsulation preserved at every level — Each class in a hierarchy maintains its own encapsulation. Private means private, even to family.
•Forces proper interface design — If subclasses need access, parents must provide protected methods, encouraging thoughtful API design.

The "Private Exists But Is Invisible" Trap

Private members still exist in memory for subclass instances — they're not removed. The subclass simply can't see or access them. This is important for understanding memory layout and when using reflection. A Dog object still contains any private fields from Animal, even though Dog code can't access them directly.

Private Helper Methods: The Workhorses

Private methods are where the real work happens. While public methods define what a class can do, private methods define how it does it. They handle the messy details, complex logic, and internal bookkeeping that clients should never know about.

Why Private Helpers Matter:

•Code organization — Break complex public methods into smaller, focused private helpers. Each helper does one thing well.
•Code reuse within the class — Multiple public methods can call the same private helper, avoiding duplication.
•Testable components — While you can't unit test private methods directly, you can design them as pure functions that are easy to reason about.
•Implementation flexibility — Private helpers can be changed, renamed, or removed without affecting users of the class.

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
103
104
105
106
107
108
109
public class OrderProcessor {
    private final PaymentGateway paymentGateway;
    private final InventoryService inventory;
    private final NotificationService notifications;
    
    public OrderProcessor(PaymentGateway pg, InventoryService inv, NotificationService notif) {
        this.paymentGateway = pg;
        this.inventory = inv;
        this.notifications = notif;
    }
    
    // PUBLIC API: Simple, clean interface
    public OrderResult processOrder(Order order) {
        // Delegates to private helpers for each step
        ValidationResult validation = validateOrder(order);
        if (!validation.isValid()) {
            return OrderResult.failed(validation.getErrors());
        }
        
        PaymentResult payment = processPayment(order);
        if (!payment.isSuccessful()) {
            return OrderResult.paymentFailed(payment.getError());
        }
        
        fulfillOrder(order);
        sendConfirmation(order, payment);
        
        return OrderResult.success(order.getId());
    }
    
    // PRIVATE HELPER: Validation logic
    private ValidationResult validateOrder(Order order) {
        List<String> errors = new ArrayList<>();
        
        if (order.getItems().isEmpty()) {
            errors.add("Order must contain at least one item");
        }
        
        for (OrderItem item : order.getItems()) {
            if (!inventory.isAvailable(item.getProductId(), item.getQuantity())) {
                errors.add("Insufficient stock for: " + item.getProductId());
            }
        }
        
        if (!isValidShippingAddress(order.getShippingAddress())) {
            errors.add("Invalid shipping address");
        }
        
        return new ValidationResult(errors);
    }
    
    // PRIVATE HELPER: Payment processing
    private PaymentResult processPayment(Order order) {
        double totalAmount = calculateTotalAmount(order);
        return paymentGateway.charge(order.getPaymentMethod(), totalAmount);
    }
    
    // PRIVATE HELPER: Pure calculation
    private double calculateTotalAmount(Order order) {
        double subtotal = order.getItems().stream()
            .mapToDouble(item -> item.getPrice() * item.getQuantity())
            .sum();
        
        double tax = calculateTax(subtotal, order.getShippingAddress());
        double shipping = calculateShipping(order);
        
        return subtotal + tax + shipping;
    }
    
    // PRIVATE HELPER: Tax calculation (could be very complex)
    private double calculateTax(double subtotal, Address address) {
        // Tax rates by state/country - internal implementation detail
        double rate = TaxRateTable.getRateFor(address.getState());
        return subtotal * rate;
    }
    
    // PRIVATE HELPER: Shipping calculation
    private double calculateShipping(Order order) {
        double weight = order.getItems().stream()
            .mapToDouble(OrderItem::getWeight)
            .sum();
        return ShippingCalculator.calculate(weight, order.getShippingMethod());
    }
    
    // PRIVATE HELPER: Fulfillment
    private void fulfillOrder(Order order) {
        for (OrderItem item : order.getItems()) {
            inventory.reserve(item.getProductId(), item.getQuantity());
        }
        // Queue for warehouse processing
    }
    
    // PRIVATE HELPER: Notifications
    private void sendConfirmation(Order order, PaymentResult payment) {
        String message = formatConfirmationEmail(order, payment);
        notifications.sendEmail(order.getCustomerEmail(), "Order Confirmed", message);
    }
    
    // PRIVATE HELPER: Address validation
    private boolean isValidShippingAddress(Address address) {
        return address != null &&
               address.getStreet() != null &&
               address.getCity() != null &&
               address.getZipCode() != null &&
               address.getState() != null;
    }
    
    // ... more private helpers
}

The Single Public Method Pattern

Notice how processOrder() is the only public method, but there are many private helpers. This pattern creates a class with:

• High cohesion — Everything relates to order processing • Low coupling — External code only knows about one method • Easy testing — One public method to test, with all edge cases • Clear purpose — The class's job is obvious from its API

Private Constructors: Controlling Object Creation

Private constructors are a powerful technique that gives you complete control over how objects of your class are created. By making the constructor private, you force all object creation to go through methods you define.

Use Cases for Private Constructors:

Private Constructor Patterns
Pattern	Purpose	Example
Singleton	Ensure only one instance exists	Database connection pool, Logger
Factory Method	Complex or validated construction	LocalDateTime.of(), Optional.empty()
Builder Pattern	Step-by-step object construction	StringBuilder, HttpRequest.Builder
Utility Class	Non-instantiable static-only class	Math, Collections, Arrays
Enum Simulation	Controlled set of instances (pre-Java 5)	Boolean.TRUE, Boolean.FALSE

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
103
104
105
106
107
108
109
110
111
// PATTERN 1: Singleton — Only one instance ever
public class ApplicationConfig {
    private static final ApplicationConfig INSTANCE = new ApplicationConfig();
    
    // Private: no one can call new ApplicationConfig()
    private ApplicationConfig() {
        // Load configuration from file/environment
    }
    
    // Only way to get an instance
    public static ApplicationConfig getInstance() {
        return INSTANCE;
    }
    
    public String getProperty(String key) {
        // ...
    }
}
 
// PATTERN 2: Factory Methods — Validated/Named Construction
public class EmailAddress {
    private final String localPart;
    private final String domain;
    
    // Private: forces use of factory methods
    private EmailAddress(String local, String domain) {
        this.localPart = local;
        this.domain = domain;
    }
    
    // Factory with validation
    public static EmailAddress of(String email) {
        Objects.requireNonNull(email, "Email cannot be null");
        
        int atIndex = email.indexOf('@');
        if (atIndex <= 0 || atIndex >= email.length() - 1) {
            throw new IllegalArgumentException("Invalid email format: " + email);
        }
        
        String local = email.substring(0, atIndex);
        String domain = email.substring(atIndex + 1);
        
        if (!isValidDomain(domain)) {
            throw new IllegalArgumentException("Invalid domain: " + domain);
        }
        
        return new EmailAddress(local, domain);
    }
    
    // Non-throwing alternative
    public static Optional<EmailAddress> tryParse(String email) {
        try {
            return Optional.of(of(email));
        } catch (IllegalArgumentException e) {
            return Optional.empty();
        }
    }
    
    private static boolean isValidDomain(String domain) {
        return domain.matches("[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}");
    }
}
 
// PATTERN 3: Utility Class — Never Instantiated
public final class StringUtils {
    // Private constructor prevents instantiation
    private StringUtils() {
        throw new AssertionError("Cannot instantiate utility class");
    }
    
    public static boolean isBlank(String str) {
        return str == null || str.trim().isEmpty();
    }
    
    public static String capitalize(String str) {
        if (isBlank(str)) return str;
        return Character.toUpperCase(str.charAt(0)) + str.substring(1).toLowerCase();
    }
    
    public static String reverse(String str) {
        if (str == null) return null;
        return new StringBuilder(str).reverse().toString();
    }
}
 
// PATTERN 4: Controlled Instances (Flyweight-like)
public class HttpStatus {
    private static final Map<Integer, HttpStatus> CACHE = new HashMap<>();
    
    private final int code;
    private final String message;
    
    // Private: use of() factory
    private HttpStatus(int code, String message) {
        this.code = code;
        this.message = message;
    }
    
    // Well-known constants
    public static final HttpStatus OK = of(200, "OK");
    public static final HttpStatus NOT_FOUND = of(404, "Not Found");
    public static final HttpStatus INTERNAL_ERROR = of(500, "Internal Server Error");
    
    // Factory that caches instances
    public static synchronized HttpStatus of(int code, String message) {
        return CACHE.computeIfAbsent(code, c -> new HttpStatus(c, message));
    }
    
    public int getCode() { return code; }
    public String getMessage() { return message; }
}

Private Constructor in Abstract Classes

While you can have a private constructor in an abstract class, it serves a different purpose. It means only nested classes within the abstract class can subclass it — external subclassing is impossible. This is useful for controlled hierarchies but uncommon.

Testing Strategies for Private Members

A common question: "How do I unit test private methods?" The short answer is: you don't test private methods directly. The longer answer involves understanding why and what to do instead.

The Testing Philosophy:

Private Methods and Testing

•Test behavior, not implementation — Private methods are implementation details. Tests should verify what the class does, not how it does it.
•Public API is the contract — Your tests should use the same interface as real clients: public methods only.
•Refactoring freedom — If tests depend on private methods, refactoring becomes impossible without rewriting tests. That defeats the purpose of testing.
•Coverage through public methods — Every private method should be reachable via public methods. If it's not, the private method is dead code.

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
// The class under test
public class PasswordValidator {
    private static final int MIN_LENGTH = 8;
    private static final Pattern UPPERCASE = Pattern.compile("[A-Z]");
    private static final Pattern LOWERCASE = Pattern.compile("[a-z]");
    private static final Pattern DIGIT = Pattern.compile("[0-9]");
    private static final Pattern SPECIAL = Pattern.compile("[!@#$%^&*]");
    
    // Public API
    public ValidationResult validate(String password) {
        List<String> failures = new ArrayList<>();
        
        if (!checkLength(password)) {
            failures.add("Must be at least " + MIN_LENGTH + " characters");
        }
        if (!checkUppercase(password)) {
            failures.add("Must contain uppercase letter");
        }
        if (!checkLowercase(password)) {
            failures.add("Must contain lowercase letter");
        }
        if (!checkDigit(password)) {
            failures.add("Must contain digit");
        }
        if (!checkSpecial(password)) {
            failures.add("Must contain special character");
        }
        
        return new ValidationResult(failures.isEmpty(), failures);
    }
    
    // Private helpers — NOT tested directly
    private boolean checkLength(String pw) {
        return pw != null && pw.length() >= MIN_LENGTH;
    }
    
    private boolean checkUppercase(String pw) {
        return pw != null && UPPERCASE.matcher(pw).find();
    }
    
    private boolean checkLowercase(String pw) {
        return pw != null && LOWERCASE.matcher(pw).find();
    }
    
    private boolean checkDigit(String pw) {
        return pw != null && DIGIT.matcher(pw).find();
    }
    
    private boolean checkSpecial(String pw) {
        return pw != null && SPECIAL.matcher(pw).find();
    }
}
 
// The tests — all through public API
class PasswordValidatorTest {
    private final PasswordValidator validator = new PasswordValidator();
    
    @Test
    void validPassword_passesAllChecks() {
        // This implicitly tests all private helpers
        ValidationResult result = validator.validate("StrongP@ss1");
        assertTrue(result.isValid());
        assertTrue(result.getFailures().isEmpty());
    }
    
    @Test
    void shortPassword_failsLengthCheck() {
        // Tests checkLength() indirectly
        ValidationResult result = validator.validate("Ab1!");
        assertFalse(result.isValid());
        assertTrue(result.getFailures().stream()
            .anyMatch(f -> f.contains("8 characters")));
    }
    
    @Test
    void noUppercase_failsUppercaseCheck() {
        // Tests checkUppercase() indirectly
        ValidationResult result = validator.validate("lowercase1!");
        assertFalse(result.isValid());
        assertTrue(result.getFailures().stream()
            .anyMatch(f -> f.contains("uppercase")));
    }
    
    @Test
    void nullPassword_failsAllChecks() {
        ValidationResult result = validator.validate(null);
        assertFalse(result.isValid());
        assertEquals(5, result.getFailures().size());
    }
    
    @Test
    void multipleFailures_allReported() {
        // No special, no digit
        ValidationResult result = validator.validate("NoDigitNoSpecial");
        assertFalse(result.isValid());
        assertEquals(2, result.getFailures().size());
    }
}

When to Extract for Testing

If a private method is so complex that you really want to unit test it, that's a design smell. Consider:

Extract to a new class — The logic might deserve its own class with public methods
Make it package-private — Allows testing while still hiding from external packages
Question the design — Complex private methods often indicate the class is doing too much

Summary: Mastering Private Access

We've explored private access in depth — the most restrictive visibility level and the foundation of encapsulation. Let's consolidate the essential knowledge:

Key Takeaways

•Private means class-only — Only code within the declaring class can access private members. Not subclasses, not same-package classes, no one else.
•Default to private — Make everything private until you have a clear reason to expose it. You can always loosen access later.
•Private enables encapsulation — By hiding state and exposing behavior, you control how objects change and ensure invariants.
•Private members aren't inherited — Subclasses can't see or access parent's private members, keeping inheritance loosely coupled.
•Private helpers enable clean code — Break complex methods into focused private helpers. They're the workhorses of your implementation.
•Private constructors control creation — Patterns like Singleton, Factory, and Utility classes rely on private constructors.
•Test through public API — Private methods are tested indirectly through the public methods that use them.

What's Next:

We've covered the two extremes: public (accessible everywhere) and private (accessible only within the class). But what about the middle ground? The protected access modifier offers visibility to subclasses while hiding members from the outside world. It's essential for designing inheritance hierarchies and we'll explore it next.

Page Complete

You now have a comprehensive understanding of private access — the foundation of encapsulation. Private members give you freedom to change, control over state, and clean separation between what your class does and how it does it. This is fundamental knowledge for building maintainable object-oriented systems.

2 / 4

Loading learning content...

System Design (LLD)Access Modifiers and Visibility

Access Modifiers and Visibility

LevelBeginner

Duration60 mins

TopicAccess Modifiers and Visibility

2 / 4

Private — Accessible Within Class Only

The Foundation of Encapsulation

What You Will Learn

Understanding Private Access

The private access modifier creates the most restrictive visibility scope possible. A private member is only accessible within the class where it's declared. No exceptions.

The Private Visibility Rule:

When a member is declared private:

What Private Access Means

•Only the declaring class can access it — code inside the class's curly braces
•Subclasses cannot access it — even direct children that inherit from the class
•Same-package classes cannot access it — package boundaries don't grant access
•External client code cannot access it — completely invisible to users of the class
•Reflection can access it — but only with explicit permission-bypassing (a deliberate violation)

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
public class BankAccount {
    // Private fields — internal state, invisible outside
    private String accountNumber;
    private double balance;
    private List<Transaction> transactionHistory;
    
    // Private constant — internal configuration
    private static final double OVERDRAFT_LIMIT = -1000.0;
    
    // Public constructor — the only way to create an account
    public BankAccount(String accountNumber, double initialDeposit) {
        this.accountNumber = accountNumber;
        this.balance = initialDeposit;
        this.transactionHistory = new ArrayList<>();
        recordTransaction("INITIAL_DEPOSIT", initialDeposit);
    }
    
    // Public method — part of the class's API
    public void deposit(double amount) {
        validatePositiveAmount(amount);  // Calling private method
        this.balance += amount;          // Accessing private field
        recordTransaction("DEPOSIT", amount);
    }
    
    public boolean withdraw(double amount) {
        validatePositiveAmount(amount);
        if (this.balance - amount < OVERDRAFT_LIMIT) {
            return false;  // Accessing private constant
        }
        this.balance -= amount;
        recordTransaction("WITHDRAWAL", -amount);
        return true;
    }
    
    // Public getter — controlled read-only access to private state
    public double getBalance() {
        return this.balance;
    }
    
    // Private helper method — internal logic, not exposed
    private void validatePositiveAmount(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Amount must be positive");
        }
    }
    
    // Private helper method — internal record keeping
    private void recordTransaction(String type, double amount) {
        transactionHistory.add(new Transaction(type, amount, Instant.now()));
    }
}
 
// Outside the class — what's accessible?
public class BankingService {
    public void processPayment(BankAccount account, double amount) {
        // ✅ Can call public methods
        account.deposit(amount);
        double balance = account.getBalance();
        
        // ❌ COMPILE ERROR: Cannot access private members
        // account.balance = 1000000;           // Cannot access field
        // account.accountNumber = "HACKED";    // Cannot access field
        // account.validatePositiveAmount(50);  // Cannot access method
        // account.transactionHistory.clear();  // Cannot access field
    }
}

Language Syntax Variations

Private access syntax varies across languages:

Why Private Should Be Your Default

The Default-to-Private Philosophy:

Benefits of Private-by-Default

•Freedom to change — Private members can be renamed, retyped, removed, or restructured without affecting any external code. This enables fearless refactoring.
•Reduced cognitive load — When reading a class, you know private members are purely internal. You don't need to trace their usage across the codebase.
•Smaller API surface — The less you expose, the simpler your class is to understand and use. Private helps you maintain a minimal public interface.
•Enforced invariants — By making state private and controlling access through methods, you can ensure your object is never in an invalid state.
•Clear responsibility — Private members signal intent: 'This is implementation detail, not a feature.' Other developers won't accidentally depend on it.
•Easier testing — Counterintuitively, private makes testing easier. You test public behavior, not private implementation. Tests become more stable.

Wrong: Public by Default

•Fields are public for 'convenience'
•All methods are public 'just in case'
•Internal helpers are exposed
•Changing anything risks breaking clients
•The class's true API is unclear

Right: Private by Default

•All fields are private (always)
•Methods start private until needed publicly
•Helpers remain hidden
•Free to refactor internals anytime
•Public methods clearly define the API

The "Need to Know" Principle

Private Access and Encapsulation

The Encapsulation Equation:

Encapsulation = Private State + Public Behavior

How Private Access Enables Encapsulation
Encapsulation Goal	How Private Achieves It	Real-World Analogy
Hide implementation details	Private members are invisible to external code	Car hides engine internals behind pedals and steering wheel
Control state changes	State can only change through public methods with validation	ATM validates PIN before allowing withdrawals
Ensure invariants	Methods maintain rules that fields alone cannot	Thermostat ensures temp never exceeds safety limit
Enable evolution	Internal changes don't affect external code	Phone updates OS without changing how you use apps
Reduce complexity	External code sees only what it needs	TV remote hides circuit complexity behind simple buttons

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
// UNENCAPSULATED: Public state, no protection
public class BadTemperatureSensor {
    public double temperatureCelsius;  // Anyone can set any value!
    
    public double getTemperatureFahrenheit() {
        return temperatureCelsius * 9/5 + 32;
    }
}
 
// What can go wrong:
BadTemperatureSensor sensor = new BadTemperatureSensor();
sensor.temperatureCelsius = -500;  // Below absolute zero? No problem!
sensor.temperatureCelsius = Double.NaN;  // Not a number? Sure!
// System now has corrupt, meaningless data
 
// ENCAPSULATED: Private state, controlled access
public class TemperatureSensor {
    // Absolute zero in Celsius — physical minimum
    private static final double ABSOLUTE_ZERO = -273.15;
    private static final double MAX_TEMP = 1000.0;
    
    // Private state — only this class can modify it
    private double temperatureCelsius;
    private Instant lastReading;
    
    // Constructor validates initial state
    public TemperatureSensor(double initialTemp) {
        setTemperature(initialTemp);  // Uses validation
    }
    
    // Controlled mutation through public method
    public void setTemperature(double celsius) {
        if (celsius < ABSOLUTE_ZERO) {
            throw new IllegalArgumentException(
                "Temperature cannot be below absolute zero: " + celsius);
        }
        if (celsius > MAX_TEMP) {
            throw new IllegalArgumentException(
                "Temperature exceeds sensor maximum: " + celsius);
        }
        if (Double.isNaN(celsius) || Double.isInfinite(celsius)) {
            throw new IllegalArgumentException(
                "Temperature must be a valid number");
        }
        this.temperatureCelsius = celsius;
        this.lastReading = Instant.now();
    }
    
    // Read-only access to state
    public double getTemperatureCelsius() {
        return temperatureCelsius;
    }
    
    public double getTemperatureFahrenheit() {
        return temperatureCelsius * 9.0/5.0 + 32.0;
    }
    
    public double getTemperatureKelvin() {
        return temperatureCelsius - ABSOLUTE_ZERO;
    }
    
    public Instant getLastReadingTime() {
        return lastReading;
    }
}
 
// Now invalid states are IMPOSSIBLE:
TemperatureSensor sensor = new TemperatureSensor(25.0);  // Valid
sensor.setTemperature(-500);  // Throws exception immediately!
// The sensor can NEVER hold an invalid temperature

The Object as a State Machine

Private Members and Inheritance

This is by design. If subclasses could access private members, they'd become dependent on parent implementation details, creating tight coupling and fragile hierarchies.

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
public class Vehicle {
    // Private state — NOT accessible to subclasses
    private String vin;
    private double fuelLevel;
    
    // Protected state — accessible to subclasses
    protected String model;
    
    public Vehicle(String vin, String model) {
        this.vin = vin;
        this.model = model;
        this.fuelLevel = 0;
    }
    
    // Private method — NOT accessible to subclasses
    private void logMaintenance(String action) {
        System.out.println("[" + vin + "] " + action);
    }
    
    // Public method that uses private internals
    public void refuel(double gallons) {
        this.fuelLevel += gallons;
        logMaintenance("Refueled: " + gallons + " gallons");
    }
    
    // Protected method — CAN be overridden by subclasses
    protected double calculateRange() {
        return fuelLevel * 25;  // 25 miles per gallon default
    }
}
 
public class ElectricCar extends Vehicle {
    private double batteryLevel;
    
    public ElectricCar(String vin, String model) {
        super(vin, model);
        this.batteryLevel = 100;
    }
    
    @Override
    protected double calculateRange() {
        // ✅ Can access protected members
        System.out.println("Calculating range for " + model);
        
        // ❌ COMPILE ERROR: Cannot access private members
        // System.out.println("VIN: " + vin);           // Error!
        // double fuel = fuelLevel;                      // Error!
        // logMaintenance("Range check");               // Error!
        
        return batteryLevel * 3;  // 3 miles per percent
    }
    
    public void charge(double percent) {
        this.batteryLevel = Math.min(100, batteryLevel + percent);
        
        // If we need to log, we must use public/protected methods from parent
        // or define our own logging
    }
}

Why Can't Subclasses Access Private Members?

This restriction serves encapsulation across the inheritance boundary:

Reasons for Private Inheritance Boundary

•Parent can evolve independently — Parents can change private members without breaking any subclass. Imagine having 50 subclasses depending on a private field — changing it would be a nightmare.
•Subclasses stay loosely coupled — Children don't know or care how parents implement things internally. They interact through the public/protected contract.
•Encapsulation preserved at every level — Each class in a hierarchy maintains its own encapsulation. Private means private, even to family.
•Forces proper interface design — If subclasses need access, parents must provide protected methods, encouraging thoughtful API design.

The "Private Exists But Is Invisible" Trap

Private Helper Methods: The Workhorses

Why Private Helpers Matter:

•Code organization — Break complex public methods into smaller, focused private helpers. Each helper does one thing well.
•Code reuse within the class — Multiple public methods can call the same private helper, avoiding duplication.
•Testable components — While you can't unit test private methods directly, you can design them as pure functions that are easy to reason about.
•Implementation flexibility — Private helpers can be changed, renamed, or removed without affecting users of the class.

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
103
104
105
106
107
108
109
public class OrderProcessor {
    private final PaymentGateway paymentGateway;
    private final InventoryService inventory;
    private final NotificationService notifications;
    
    public OrderProcessor(PaymentGateway pg, InventoryService inv, NotificationService notif) {
        this.paymentGateway = pg;
        this.inventory = inv;
        this.notifications = notif;
    }
    
    // PUBLIC API: Simple, clean interface
    public OrderResult processOrder(Order order) {
        // Delegates to private helpers for each step
        ValidationResult validation = validateOrder(order);
        if (!validation.isValid()) {
            return OrderResult.failed(validation.getErrors());
        }
        
        PaymentResult payment = processPayment(order);
        if (!payment.isSuccessful()) {
            return OrderResult.paymentFailed(payment.getError());
        }
        
        fulfillOrder(order);
        sendConfirmation(order, payment);
        
        return OrderResult.success(order.getId());
    }
    
    // PRIVATE HELPER: Validation logic
    private ValidationResult validateOrder(Order order) {
        List<String> errors = new ArrayList<>();
        
        if (order.getItems().isEmpty()) {
            errors.add("Order must contain at least one item");
        }
        
        for (OrderItem item : order.getItems()) {
            if (!inventory.isAvailable(item.getProductId(), item.getQuantity())) {
                errors.add("Insufficient stock for: " + item.getProductId());
            }
        }
        
        if (!isValidShippingAddress(order.getShippingAddress())) {
            errors.add("Invalid shipping address");
        }
        
        return new ValidationResult(errors);
    }
    
    // PRIVATE HELPER: Payment processing
    private PaymentResult processPayment(Order order) {
        double totalAmount = calculateTotalAmount(order);
        return paymentGateway.charge(order.getPaymentMethod(), totalAmount);
    }
    
    // PRIVATE HELPER: Pure calculation
    private double calculateTotalAmount(Order order) {
        double subtotal = order.getItems().stream()
            .mapToDouble(item -> item.getPrice() * item.getQuantity())
            .sum();
        
        double tax = calculateTax(subtotal, order.getShippingAddress());
        double shipping = calculateShipping(order);
        
        return subtotal + tax + shipping;
    }
    
    // PRIVATE HELPER: Tax calculation (could be very complex)
    private double calculateTax(double subtotal, Address address) {
        // Tax rates by state/country - internal implementation detail
        double rate = TaxRateTable.getRateFor(address.getState());
        return subtotal * rate;
    }
    
    // PRIVATE HELPER: Shipping calculation
    private double calculateShipping(Order order) {
        double weight = order.getItems().stream()
            .mapToDouble(OrderItem::getWeight)
            .sum();
        return ShippingCalculator.calculate(weight, order.getShippingMethod());
    }
    
    // PRIVATE HELPER: Fulfillment
    private void fulfillOrder(Order order) {
        for (OrderItem item : order.getItems()) {
            inventory.reserve(item.getProductId(), item.getQuantity());
        }
        // Queue for warehouse processing
    }
    
    // PRIVATE HELPER: Notifications
    private void sendConfirmation(Order order, PaymentResult payment) {
        String message = formatConfirmationEmail(order, payment);
        notifications.sendEmail(order.getCustomerEmail(), "Order Confirmed", message);
    }
    
    // PRIVATE HELPER: Address validation
    private boolean isValidShippingAddress(Address address) {
        return address != null &&
               address.getStreet() != null &&
               address.getCity() != null &&
               address.getZipCode() != null &&
               address.getState() != null;
    }
    
    // ... more private helpers
}

The Single Public Method Pattern

Notice how processOrder() is the only public method, but there are many private helpers. This pattern creates a class with:

Private Constructors: Controlling Object Creation

Use Cases for Private Constructors:

Private Constructor Patterns
Pattern	Purpose	Example
Singleton	Ensure only one instance exists	Database connection pool, Logger
Factory Method	Complex or validated construction	LocalDateTime.of(), Optional.empty()
Builder Pattern	Step-by-step object construction	StringBuilder, HttpRequest.Builder
Utility Class	Non-instantiable static-only class	Math, Collections, Arrays
Enum Simulation	Controlled set of instances (pre-Java 5)	Boolean.TRUE, Boolean.FALSE

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
103
104
105
106
107
108
109
110
111
// PATTERN 1: Singleton — Only one instance ever
public class ApplicationConfig {
    private static final ApplicationConfig INSTANCE = new ApplicationConfig();
    
    // Private: no one can call new ApplicationConfig()
    private ApplicationConfig() {
        // Load configuration from file/environment
    }
    
    // Only way to get an instance
    public static ApplicationConfig getInstance() {
        return INSTANCE;
    }
    
    public String getProperty(String key) {
        // ...
    }
}
 
// PATTERN 2: Factory Methods — Validated/Named Construction
public class EmailAddress {
    private final String localPart;
    private final String domain;
    
    // Private: forces use of factory methods
    private EmailAddress(String local, String domain) {
        this.localPart = local;
        this.domain = domain;
    }
    
    // Factory with validation
    public static EmailAddress of(String email) {
        Objects.requireNonNull(email, "Email cannot be null");
        
        int atIndex = email.indexOf('@');
        if (atIndex <= 0 || atIndex >= email.length() - 1) {
            throw new IllegalArgumentException("Invalid email format: " + email);
        }
        
        String local = email.substring(0, atIndex);
        String domain = email.substring(atIndex + 1);
        
        if (!isValidDomain(domain)) {
            throw new IllegalArgumentException("Invalid domain: " + domain);
        }
        
        return new EmailAddress(local, domain);
    }
    
    // Non-throwing alternative
    public static Optional<EmailAddress> tryParse(String email) {
        try {
            return Optional.of(of(email));
        } catch (IllegalArgumentException e) {
            return Optional.empty();
        }
    }
    
    private static boolean isValidDomain(String domain) {
        return domain.matches("[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}");
    }
}
 
// PATTERN 3: Utility Class — Never Instantiated
public final class StringUtils {
    // Private constructor prevents instantiation
    private StringUtils() {
        throw new AssertionError("Cannot instantiate utility class");
    }
    
    public static boolean isBlank(String str) {
        return str == null || str.trim().isEmpty();
    }
    
    public static String capitalize(String str) {
        if (isBlank(str)) return str;
        return Character.toUpperCase(str.charAt(0)) + str.substring(1).toLowerCase();
    }
    
    public static String reverse(String str) {
        if (str == null) return null;
        return new StringBuilder(str).reverse().toString();
    }
}
 
// PATTERN 4: Controlled Instances (Flyweight-like)
public class HttpStatus {
    private static final Map<Integer, HttpStatus> CACHE = new HashMap<>();
    
    private final int code;
    private final String message;
    
    // Private: use of() factory
    private HttpStatus(int code, String message) {
        this.code = code;
        this.message = message;
    }
    
    // Well-known constants
    public static final HttpStatus OK = of(200, "OK");
    public static final HttpStatus NOT_FOUND = of(404, "Not Found");
    public static final HttpStatus INTERNAL_ERROR = of(500, "Internal Server Error");
    
    // Factory that caches instances
    public static synchronized HttpStatus of(int code, String message) {
        return CACHE.computeIfAbsent(code, c -> new HttpStatus(c, message));
    }
    
    public int getCode() { return code; }
    public String getMessage() { return message; }
}

Private Constructor in Abstract Classes

Testing Strategies for Private Members

A common question: "How do I unit test private methods?" The short answer is: you don't test private methods directly. The longer answer involves understanding why and what to do instead.

The Testing Philosophy:

Private Methods and Testing

•Test behavior, not implementation — Private methods are implementation details. Tests should verify what the class does, not how it does it.
•Public API is the contract — Your tests should use the same interface as real clients: public methods only.
•Refactoring freedom — If tests depend on private methods, refactoring becomes impossible without rewriting tests. That defeats the purpose of testing.
•Coverage through public methods — Every private method should be reachable via public methods. If it's not, the private method is dead code.

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
// The class under test
public class PasswordValidator {
    private static final int MIN_LENGTH = 8;
    private static final Pattern UPPERCASE = Pattern.compile("[A-Z]");
    private static final Pattern LOWERCASE = Pattern.compile("[a-z]");
    private static final Pattern DIGIT = Pattern.compile("[0-9]");
    private static final Pattern SPECIAL = Pattern.compile("[!@#$%^&*]");
    
    // Public API
    public ValidationResult validate(String password) {
        List<String> failures = new ArrayList<>();
        
        if (!checkLength(password)) {
            failures.add("Must be at least " + MIN_LENGTH + " characters");
        }
        if (!checkUppercase(password)) {
            failures.add("Must contain uppercase letter");
        }
        if (!checkLowercase(password)) {
            failures.add("Must contain lowercase letter");
        }
        if (!checkDigit(password)) {
            failures.add("Must contain digit");
        }
        if (!checkSpecial(password)) {
            failures.add("Must contain special character");
        }
        
        return new ValidationResult(failures.isEmpty(), failures);
    }
    
    // Private helpers — NOT tested directly
    private boolean checkLength(String pw) {
        return pw != null && pw.length() >= MIN_LENGTH;
    }
    
    private boolean checkUppercase(String pw) {
        return pw != null && UPPERCASE.matcher(pw).find();
    }
    
    private boolean checkLowercase(String pw) {
        return pw != null && LOWERCASE.matcher(pw).find();
    }
    
    private boolean checkDigit(String pw) {
        return pw != null && DIGIT.matcher(pw).find();
    }
    
    private boolean checkSpecial(String pw) {
        return pw != null && SPECIAL.matcher(pw).find();
    }
}
 
// The tests — all through public API
class PasswordValidatorTest {
    private final PasswordValidator validator = new PasswordValidator();
    
    @Test
    void validPassword_passesAllChecks() {
        // This implicitly tests all private helpers
        ValidationResult result = validator.validate("StrongP@ss1");
        assertTrue(result.isValid());
        assertTrue(result.getFailures().isEmpty());
    }
    
    @Test
    void shortPassword_failsLengthCheck() {
        // Tests checkLength() indirectly
        ValidationResult result = validator.validate("Ab1!");
        assertFalse(result.isValid());
        assertTrue(result.getFailures().stream()
            .anyMatch(f -> f.contains("8 characters")));
    }
    
    @Test
    void noUppercase_failsUppercaseCheck() {
        // Tests checkUppercase() indirectly
        ValidationResult result = validator.validate("lowercase1!");
        assertFalse(result.isValid());
        assertTrue(result.getFailures().stream()
            .anyMatch(f -> f.contains("uppercase")));
    }
    
    @Test
    void nullPassword_failsAllChecks() {
        ValidationResult result = validator.validate(null);
        assertFalse(result.isValid());
        assertEquals(5, result.getFailures().size());
    }
    
    @Test
    void multipleFailures_allReported() {
        // No special, no digit
        ValidationResult result = validator.validate("NoDigitNoSpecial");
        assertFalse(result.isValid());
        assertEquals(2, result.getFailures().size());
    }
}

When to Extract for Testing

If a private method is so complex that you really want to unit test it, that's a design smell. Consider:

Extract to a new class — The logic might deserve its own class with public methods
Make it package-private — Allows testing while still hiding from external packages
Question the design — Complex private methods often indicate the class is doing too much

Summary: Mastering Private Access

We've explored private access in depth — the most restrictive visibility level and the foundation of encapsulation. Let's consolidate the essential knowledge:

Key Takeaways

•Private means class-only — Only code within the declaring class can access private members. Not subclasses, not same-package classes, no one else.
•Default to private — Make everything private until you have a clear reason to expose it. You can always loosen access later.
•Private enables encapsulation — By hiding state and exposing behavior, you control how objects change and ensure invariants.
•Private members aren't inherited — Subclasses can't see or access parent's private members, keeping inheritance loosely coupled.
•Private helpers enable clean code — Break complex methods into focused private helpers. They're the workhorses of your implementation.
•Private constructors control creation — Patterns like Singleton, Factory, and Utility classes rely on private constructors.
•Test through public API — Private methods are tested indirectly through the public methods that use them.

What's Next:

Page Complete

2 / 4