Access Modifiers - Learning Module

Loading content...

0/246

Package/Internal — Language-Specific Access

Beyond the Universal Three

Public, private, and protected exist in nearly every object-oriented language. But modern programming languages recognize that these three levels aren't always enough. Sometimes you need visibility that spans multiple classes working closely together — without exposing them to the entire outside world.

Enter package-private (Java), internal (C#), module (Kotlin/Swift), and various other language-specific access levels. These modifiers create visibility boundaries at a higher level than the class — at the package, module, or assembly level.

What You Will Learn

By the end of this page, you will understand: • Java's default (package-private) access and when to use it • C#'s internal modifier and the assembly concept • Kotlin and Swift's module-based visibility • How package/module visibility enables encapsulation at scale • Design patterns that leverage package-level access • Best practices for organizing code into packages/modules

Java's Package-Private Access

In Java, when you declare a member without any access modifier, it has package-private (also called "default") access. This means it's visible to all classes in the same package, but invisible to classes in other packages.

Package-Private Visibility:

What Package-Private Allows

•All classes in the same package — Full access, regardless of inheritance
•NOT subclasses in other packages — Unlike protected, no cross-package inheritance access
•Implicitly applied — Just omit the modifier; there's no 'package' keyword
•Package = folder structure — In Java, package corresponds to directory path

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
// File: com/myapp/user/UserRepository.java
package com.myapp.user;
 
// Public class - accessible from anywhere
public class UserRepository {
    
    // Package-private field - accessible only in com.myapp.user
    List<User> cachedUsers;
    
    // Package-private method - used by sibling classes
    void invalidateCache() {
        cachedUsers = null;
    }
    
    // Public method - part of the external API
    public User findById(String id) {
        if (cachedUsers != null) {
            return findInCache(id);
        }
        return loadFromDatabase(id);
    }
    
    // Package-private - other classes in package can call
    User loadFromDatabase(String id) {
        // Database access logic
        return new User(id);
    }
    
    // Private - only this class
    private User findInCache(String id) {
        return cachedUsers.stream()
            .filter(u -> u.getId().equals(id))
            .findFirst()
            .orElse(null);
    }
}
 
// File: com/myapp/user/UserService.java (SAME PACKAGE)
package com.myapp.user;
 
public class UserService {
    private UserRepository repository = new UserRepository();
    
    public void refreshUser(String id) {
        // ✅ Can access package-private method
        repository.invalidateCache();
        
        // ✅ Can access package-private method
        User user = repository.loadFromDatabase(id);
        
        // ❌ Cannot access private method
        // repository.findInCache(id);  // Error!
    }
}
 
// File: com/myapp/order/OrderService.java (DIFFERENT PACKAGE)
package com.myapp.order;
 
import com.myapp.user.UserRepository;
 
public class OrderService {
    private UserRepository userRepo = new UserRepository();
    
    public void processOrder(String userId) {
        // ✅ Can access public method
        User user = userRepo.findById(userId);
        
        // ❌ Cannot access package-private members
        // userRepo.invalidateCache();       // Error!
        // userRepo.loadFromDatabase(userId); // Error!
        // userRepo.cachedUsers;              // Error!
    }
}

Package = Encapsulation Unit

Package-private access treats the package as a unit of encapsulation. Within a package, classes collaborate freely. Across packages, only public (and protected through inheritance) is visible. This enables internal implementation sharing while maintaining clean external APIs.

When to Use Package-Private

Package-private access fills a specific need: sharing implementation between related classes without exposing it to the world. It's surprisingly powerful and underutilized.

Primary Use Cases:

Package-Private Use Cases
Use Case	Description	Example
Implementation Classes	Helpers that support public classes but shouldn't be used directly	UserValidator used by UserService, not exported
Test Access	Allow test classes (in same package) to access internals	Tests can call package-private setup methods
Sibling Collaboration	Classes that implement a feature together	OrderProcessor and OrderValidator sharing state
Factory Internals	Concrete classes created by public factories	Private implementations behind public interface
Package Cohesion	Force all usage through a single public entry point	One public facade, many package-private workers

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
// Package: com.payments
 
// PUBLIC: The only entry point for external code
public class PaymentGateway {
    // Package-private dependencies - wired internally
    private final CardValidator cardValidator = new CardValidator();
    private final FraudDetector fraudDetector = new FraudDetector();
    private final TransactionProcessor processor = new TransactionProcessor();
    
    public PaymentResult processPayment(PaymentRequest request) {
        ValidationResult validation = cardValidator.validate(request.getCard());
        if (!validation.isValid()) {
            return PaymentResult.invalid(validation.getErrors());
        }
        
        RiskAssessment risk = fraudDetector.assess(request);
        if (risk.isHighRisk()) {
            return PaymentResult.rejected("Flagged for fraud review");
        }
        
        return processor.process(request);
    }
}
 
// PACKAGE-PRIVATE: Implementation detail - not public API
class CardValidator {
    ValidationResult validate(Card card) {
        List<String> errors = new ArrayList<>();
        
        if (!isValidLuhn(card.getNumber())) {
            errors.add("Invalid card number");
        }
        if (isExpired(card.getExpiry())) {
            errors.add("Card expired");
        }
        
        return new ValidationResult(errors);
    }
    
    // Package-private - used by test classes
    boolean isValidLuhn(String cardNumber) {
        // Luhn algorithm implementation
        return true;
    }
    
    private boolean isExpired(YearMonth expiry) {
        return expiry.isBefore(YearMonth.now());
    }
}
 
// PACKAGE-PRIVATE: Another internal component
class FraudDetector {
    RiskAssessment assess(PaymentRequest request) {
        double riskScore = calculateRiskScore(request);
        return new RiskAssessment(riskScore);
    }
    
    // Package-private for testing
    double calculateRiskScore(PaymentRequest request) {
        // Complex scoring logic
        return 0.1;
    }
}
 
// PACKAGE-PRIVATE: Transaction processing
class TransactionProcessor {
    PaymentResult process(PaymentRequest request) {
        // Actual payment processing
        return PaymentResult.success(generateTransactionId());
    }
    
    String generateTransactionId() {
        return UUID.randomUUID().toString();
    }
}
 
// External code sees ONLY PaymentGateway:
// PaymentGateway gateway = new PaymentGateway();
// gateway.processPayment(request);  // ✅ Works
// CardValidator validator = new CardValidator();  // ❌ Error: CardValidator is not public

Package-Private for Test Access

A powerful pattern: when your test classes are in the same package as the production code (but in a different source folder like src/test/java), they can access package-private members. This lets you test internal logic without making it public.

// Production code: src/main/java/com/app/Calculator.java
class Calculator {
    int internalAdd(int a, int b) { return a + b; }
}

// Test code: src/test/java/com/app/CalculatorTest.java
class CalculatorTest {
    @Test void testInternalAdd() {
        Calculator calc = new Calculator();
        assertEquals(5, calc.internalAdd(2, 3)); // ✅ Works!
    }
}

C#'s Internal Modifier

C# uses internal for assembly-level visibility. An assembly in C# is a compiled unit — typically a DLL or EXE file. Internal members are visible within the entire assembly but hidden from other assemblies.

Key Difference from Java:

Java's packages are compile-time constructs; C#'s assemblies are deployment units. This means internal visibility is enforced at the binary level, not just the source level.

C# Access Modifier Spectrum:

C# Access Modifiers
Modifier	Visibility	Use Case
public	Everywhere	Public API
private	Declaring class only	Implementation details
protected	Class + subclasses	Inheritance hooks
internal	Same assembly	Implementation shared across namespaces
protected internal	Same assembly OR subclasses	Flexible framework extension
private protected	Same assembly AND subclass	Strict internal inheritance

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
// File: MyLibrary/PaymentModule/PaymentService.cs
namespace MyLibrary.PaymentModule
{
    // Public class - exported from the assembly
    public class PaymentService
    {
        // Internal: visible within MyLibrary.dll, not to consumers
        internal static readonly ILogger Logger = LoggerFactory.Create();
        
        private readonly IPaymentProcessor _processor;
        
        public PaymentService(IPaymentProcessor processor)
        {
            _processor = processor;
        }
        
        public PaymentResult ProcessPayment(PaymentRequest request)
        {
            // Using internal member
            Logger.LogInfo("Processing payment: {}", request.Id);
            
            return _processor.Process(request);
        }
    }
}
 
// File: MyLibrary/Utilities/InternalHelper.cs
namespace MyLibrary.Utilities
{
    // Internal class - cannot be seen outside MyLibrary.dll
    internal class InternalHelper
    {
        internal static string FormatCurrency(decimal amount)
        {
            return $"${amount: N2
                            }";
        }
        
        internal static bool IsValidEmail(string email)
        {
                            return email.Contains("@") && email.Contains(".");
                        }
    }
}
 
// File: MyLibrary/ValidationModule/Validator.cs
namespace MyLibrary.ValidationModule
{
            public class Validator
    {
            // Internal from different namespace - works! Same assembly.
            public bool ValidateEmail(string email) {
                // ✅ Can access InternalHelper from Utilities namespace
                return Utilities.InternalHelper.IsValidEmail(email);
            }
        }
}
 
// File: ConsumerApp/Program.cs (DIFFERENT ASSEMBLY)
using MyLibrary.PaymentModule;
using MyLibrary.ValidationModule;
 
namespace ConsumerApp {
    class Program {
        static void Main() {
            // ✅ Can use public classes
            var service = new PaymentService(new MockProcessor());
            var validator = new Validator();
 
            // ❌ Cannot access internal members
            // PaymentService.Logger.LogInfo("...");  // Error!
            // MyLibrary.Utilities.InternalHelper.FormatCurrency(100);  // Error!
        }
    }
} 

Testing Internal Members in C#

C# has a great testing feature: InternalsVisibleTo. Add this to your library's AssemblyInfo.cs:

[assembly: InternalsVisibleTo("MyLibrary.Tests")]

Now your test assembly can access all internal members! This is the idiomatic way to test internal code in C# — much cleaner than reflection hacks.

Kotlin and Swift Module Access

Modern languages like Kotlin and Swift have refined the module concept, making it a first-class visibility boundary.

Kotlin's Approach:

Kotlin uses internal for module visibility. In Kotlin, a module is a set of source files compiled together:

A Gradle or Maven project
An IntelliJ IDEA module
A set of sources compiled in one Kotlin compiler invocation

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
// Module: payment-core
 
// Internal class - visible within payment-core module only
internal class PaymentValidator {
    fun validate(request: PaymentRequest): ValidationResult {
        return if (isValid(request)) {
            ValidationResult.Valid
        } else {
            ValidationResult.Invalid("Invalid payment data")
        }
    }
    
    internal fun isValid(request: PaymentRequest): Boolean {
        return request.amount > 0 && request.currency.isNotBlank()
    }
}
 
// Public class - the exported API
class PaymentProcessor {
    // Private - only PaymentProcessor uses this
    private val validator = PaymentValidator()
    
    // Public - external modules call this
    fun processPayment(request: PaymentRequest): PaymentResult {
        val validation = validator.validate(request)
        
        return when (validation) {
            is ValidationResult.Valid -> executePayment(request)
            is ValidationResult.Invalid -> PaymentResult.Error(validation.reason)
        }
    }
    
    // Internal - other classes in payment-core can access
    internal fun executePayment(request: PaymentRequest): PaymentResult {
        // Core payment logic
        return PaymentResult.Success(generateId())
    }
    
    private fun generateId(): String = java.util.UUID.randomUUID().toString()
}
 
// Another file in payment-core (same module)
internal class PaymentLogger {
    fun log(processor: PaymentProcessor, request: PaymentRequest) {
        // ✅ Can access internal member
        processor.executePayment(request)
    }
}
 
// In consumer module (different Gradle project):
// val validator = PaymentValidator()  // ❌ Error: internal
// processor.executePayment(request)   // ❌ Error: internal
// processor.processPayment(request)   // ✅ Works: public

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
// Swift has five access levels (most restrictive to least):
// private, fileprivate, internal (default), public, open
 
// Module: PaymentFramework
 
// Internal (default) - visible within PaymentFramework module
class PaymentValidator {
    func validate(_ request: PaymentRequest) -> Bool {
        return request.amount > 0
    }
}
 
// Public - visible to importers, but NOT subclassable outside module
public class PaymentProcessor {
    private let validator = PaymentValidator()
    
    public init() {}
    
    // Public: callable from outside the module
    public func process(_ request: PaymentRequest) -> PaymentResult {
        guard validator.validate(request) else {
            return .failure("Invalid request")
        }
        return execute(request)
    }
    
    // Internal: other PaymentFramework code can call this
    func execute(_ request: PaymentRequest) -> PaymentResult {
        return .success(generateId())
    }
    
    // Fileprivate: only code in THIS FILE can access
    fileprivate func generateId() -> String {
        return UUID().uuidString
    }
    
    // Private: only this class can access
    private let config = Configuration()
}
 
// Open: can be subclassed AND overridden outside the module
open class ExtensibleProcessor: PaymentProcessor {
    open func customProcess(_ request: PaymentRequest) -> PaymentResult {
        // Subclasses outside the module can override this
        return process(request)
    }
}
 
// Consumer code (different module):
import PaymentFramework
 
let processor = PaymentProcessor()
processor.process(request)  // ✅ Public
// processor.execute(request)  // ❌ Internal
// PaymentValidator()  // ❌ Internal class
 
class MyProcessor: ExtensibleProcessor {
    override func customProcess(_ request: PaymentRequest) -> PaymentResult {
        // ✅ Can override: method is 'open'
        return super.customProcess(request)
    }
    
    // override func process(...)  // ❌ Can't override: 'public' not 'open'
}

Swift's public vs open

Swift distinguishes between public and open:

• public: Visible outside the module but cannot be subclassed/overridden outside • open: Visible AND can be subclassed/overridden outside the module

This gives library authors control over what clients can extend. Use open only for intentional extension points.

Package Design Principles

Package and module boundaries are architectural decisions. How you organize code into packages determines what can see what, affecting maintainability and API design.

Core Principles:

Package Organization Principles

•Package by Feature, not by Layer — Group classes by what they do (user, payment, order), not by type (models, services, controllers). This keeps related code together.
•Minimize Public Surface — Each package should export as few public classes as possible. Internal implementation can be complex; the public interface should be simple.
•Package as Unit of Change — Classes that change together should be in the same package. This minimizes ripple effects from changes.
•Depend on Abstractions — Packages should depend on interfaces/abstract classes, not concrete implementations. This allows package internals to evolve independently.
•No Circular Dependencies — Package A should not depend on package B if B depends on A. This creates a mess of coupling.

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
// Feature-based package organization
 
// com.myapp.user package
// └── User.java                    (public)  - Domain entity
// └── UserRepository.java          (public)  - Data access interface
// └── UserService.java             (public)  - External API
// └── UserValidator.java           (package) - Internal validation
// └── UserRepositoryImpl.java      (package) - Internal implementation
// └── UserMapper.java              (package) - Internal DTO mapping
 
package com.myapp.user;
 
// PUBLIC: The interface external packages depend on
public interface UserRepository {
    User findById(String id);
    void save(User user);
    List<User> findAll();
}
 
// PUBLIC: The external service API
public class UserService {
    private final UserRepository repository;
    private final UserValidator validator;  // Package-private dependency
    
    public UserService(UserRepository repository) {
        this.repository = repository;
        this.validator = new UserValidator();
    }
    
    public User createUser(CreateUserRequest request) {
        validator.validate(request);  // Internal validation
        User user = UserMapper.toEntity(request);  // Internal mapping
        repository.save(user);
        return user;
    }
}
 
// PACKAGE-PRIVATE: Implementation detail
class UserValidator {
    void validate(CreateUserRequest request) {
        if (request.getEmail() == null || !request.getEmail().contains("@")) {
            throw new ValidationException("Invalid email");
        }
        if (request.getName() == null || request.getName().isBlank()) {
            throw new ValidationException("Name required");
        }
    }
}
 
// PACKAGE-PRIVATE: Implementation detail
class UserRepositoryImpl implements UserRepository {
    private final DataSource dataSource;
    
    UserRepositoryImpl(DataSource dataSource) {
        this.dataSource = dataSource;
    }
    
    @Override
    public User findById(String id) {
        // JDBC implementation
        return null;
    }
    // ...
}
 
// PACKAGE-PRIVATE: Internal utility
class UserMapper {
    static User toEntity(CreateUserRequest request) {
        return new User(request.getName(), request.getEmail());
    }
    
    static UserDTO toDTO(User user) {
        return new UserDTO(user.getId(), user.getName(), user.getEmail());
    }
}

Anti-Pattern: Package-per-Layer

Avoid organizing by layer (controllers, services, repositories). This scatters related code:

❌ com.app.controllers.UserController ❌ com.app.services.UserService ❌ com.app.repositories.UserRepository

Each layer becomes a package with many unrelated classes, and everything must be public because packages can't share internal members.

✅ Instead: com.app.user.{UserController, UserService, UserRepository}

Cross-Language Comparison

Let's consolidate how different languages handle the "more than class, less than public" visibility scope.

Comprehensive Comparison:

Package/Module Access Across Languages
Language	Keyword	Boundary	Test Access Strategy
Java	(no keyword)	Package	Test in same package different folder
C#	internal	Assembly (DLL)	InternalsVisibleTo attribute
Kotlin	internal	Compilation module	Same module, different source set
Swift	(default)	Framework/Module	Same module, different target
TypeScript	N/A	No equivalent	No true private/internal enforcement
Python	_ prefix (convention)	Module (file)	No enforcement, convention only
Go	lowercase	Package	Test in same package (*_test.go)
Rust	pub(crate)	Crate	Tests in same crate

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
// TypeScript: No true internal access (everything can be imported)
// Workaround: Use barrels (index.ts) to control exports
 
// src/payments/internal/processor.ts
export class PaymentProcessor {  // Technically exportable
    process(request: PaymentRequest): PaymentResult {
        return { success: true };
    }
}
 
// src/payments/internal/validator.ts
export class PaymentValidator {  // Technically exportable
    validate(request: PaymentRequest): boolean {
        return true;
    }
}
 
// src/payments/index.ts (barrel file)
// Only export what should be public
export { PaymentProcessor } from './internal/processor';
// PaymentValidator is NOT exported - effectively "internal"
 
// Consumer must import from the barrel:
import { PaymentProcessor } from '@mylib/payments';
// import { PaymentValidator } from '@mylib/payments';  // Error: not exported
// import { PaymentValidator } from '@mylib/payments/internal/validator'; // Works but linted against
 
// ============================================
 
# Python: Convention-based internal marking
 
# payments/processor.py
class PaymentProcessor:
    """Public API class."""
    
    def process(self, request):
        validator = _InternalValidator()  # Internal class
        if validator.validate(request):
            return self._execute(request)  # Internal method
        return {"error": "Invalid request"}
    
    def _execute(self, request):
        """Internal method - indicated by single underscore."""
        return {"success": True}
 
class _InternalValidator:
    """Internal class - indicated by leading underscore."""
    
    def validate(self, request):
        return request.get("amount", 0) > 0
 
# payments/__init__.py
# Control what's publicly exported
from .processor import PaymentProcessor
# _InternalValidator is NOT imported - conventionally internal
 
# Usage:
from payments import PaymentProcessor  # ✅ Works
from payments.processor import _InternalValidator  # Works but discouraged

Designing Effective Visibility Boundaries

Choosing the right visibility for each member is a design decision that affects your codebase's maintainability. Here's a systematic approach:

The Visibility Decision Framework:

Choosing Visibility Step by Step

•Start with private — Every new member starts private. This is the safest default.
•Promote to package/internal if siblings need it — If other classes in the same package/module need access, and they're truly related implementation, use package-private or internal.
•Promote to protected if subclasses need it — Only if you're explicitly designing for inheritance and subclasses need to customize behavior.
•Promote to public only for the true API — Public is a commitment. Once public, changing it breaks clients. Reserve it for the features you truly want to expose.
•Document the contract for anything non-private — If others can see it, document what it does, what it requires, and what guarantees it provides.

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
public class Order {
    // Question: Who needs to access this?
    
    // PRIVATE: Only Order uses these for internal state
    private final String orderId;
    private final List<OrderItem> items;
    private OrderStatus status;
    private BigDecimal calculatedTotal;
    
    // PRIVATE: Internal validation logic
    private void validateItems(List<OrderItem> items) {
        if (items == null || items.isEmpty()) {
            throw new IllegalArgumentException("Order must have items");
        }
    }
    
    // PACKAGE-PRIVATE: OrderService in same package manages orders
    void transitionTo(OrderStatus newStatus) {
        if (!this.status.canTransitionTo(newStatus)) {
            throw new IllegalStateException("Invalid transition");
        }
        this.status = newStatus;
    }
    
    // PACKAGE-PRIVATE: Accessed by OrderPriceCalculator in same package
    BigDecimal getSubtotal() {
        return items.stream()
            .map(OrderItem::getLineTotal)
            .reduce(BigDecimal.ZERO, BigDecimal::add);
    }
    
    // PROTECTED: Would be used if Order is subclassed (rare for entities)
    // Typically entities aren't subclassed, so this is uncommon
    
    // PUBLIC: The official API clients use
    public String getOrderId() {
        return orderId;
    }
    
    public OrderStatus getStatus() {
        return status;
    }
    
    public BigDecimal getTotal() {
        return calculatedTotal;
    }
    
    public List<OrderItem> getItems() {
        // Defensive copy: internal list stays protected
        return List.copyOf(items);
    }
    
    public void addItem(Product product, int quantity) {
        // Validates and adds, maintaining encapsulation
    }
    
    // Constructor: could be public or package-private depending on creation patterns
    public Order(String orderId, List<OrderItem> items) {
        validateItems(items);
        this.orderId = orderId;
        this.items = new ArrayList<>(items);  // Defensive copy
        this.status = OrderStatus.PENDING;
        recalculateTotal();
    }
    
    private void recalculateTotal() {
        this.calculatedTotal = getSubtotal();  // Uses package-private method
    }
}

When In Doubt: More Restrictive

If you're unsure between two access levels, choose the more restrictive one. You can always loosen access later without breaking anything. Tightening access after the fact breaks every caller that depended on the looser access.

Summary: Mastering Access Modifiers

We've completed our comprehensive exploration of access modifiers — from public's wide-open visibility to private's strict confinement, through protected's inheritance bridge, to package/internal's broader encapsulation units. Let's consolidate the complete picture:

Module Key Takeaways

•Public is a commitment — Anything public becomes part of your API contract. Use sparingly and document thoroughly.
•Private is your default — Start everything private. It gives you maximum flexibility to change implementation.
•Protected is for inheritance — Use when designing extensible hierarchies. Prefer protected methods over protected fields.
•Package/internal bridges the gap — Share implementation between related classes without exposing it globally.
•Languages vary — Java's protected includes package access; C#'s internal is assembly-scoped; Swift distinguishes public from open.
•Package design matters — How you organize code into packages determines what encapsulation is possible.
•When in doubt, restrict more — You can always loosen access later; tightening breaks clients.

Quick Reference: When to Use Each Access Level
Access Level	Use When	Avoid When
public	External code must call it	It's implementation detail
private	Only this class uses it	Subclasses need it
protected	Subclasses customize behavior	No inheritance is intended
package/internal	Same-package classes collaborate	It's truly class-internal

What's Next:

You now have complete mastery of access modifiers — the fundamental mechanism for controlling visibility in object-oriented systems. This knowledge forms the foundation for the next chapter, where we'll explore static vs instance members — understanding when behavior belongs to the class versus individual objects.

Module Complete

You've mastered access modifiers — one of the most important aspects of object-oriented design. You understand not just the syntax, but the why behind each visibility level. This knowledge enables you to design clean, maintainable, and appropriately encapsulated systems. Every class you design from now on will benefit from this understanding.