Должны ли все данные быть закрытыми модификаторами доступа при инкапсуляции

# Инкапсуляция и модификаторы доступа: Когда делать данные приватными?

Это частый вопрос, и ответ не такой простой, как кажется: не обязательно все данные должны быть private, но большинство должны быть. Давайте разберемся, когда какой модификатор использовать.

Основные модификаторы доступа в Java

public      // Видна везде
protected   // Видна в пакете и подклассах
package     // Видна только в пакете (default, нет модификатора)
private     // Видна только в классе

Правило инкапсуляции: private (по умолчанию) + getter/setter

1. Private поля + публичные методы (классический подход)

// ✅ ПРАВИЛЬНО
public class User {
    private String email;      // Private поле
    private int age;           // Private поле
    private boolean active;    // Private поле
    
    // Публичные getter'ы
    public String getEmail() {
        return email;
    }
    
    // Контролируемый setter с валидацией
    public void setEmail(String email) {
        if (email == null || !email.contains("@")) {
            throw new IllegalArgumentException("Некорректный email");
        }
        this.email = email;
    }
    
    public int getAge() {
        return age;
    }
    
    public void setAge(int age) {
        if (age < 0 || age > 150) {
            throw new IllegalArgumentException("Некорректный возраст");
        }
        this.age = age;
    }
}

// Преимущества:
// - Контроль над изменением данных
// - Можно добавить валидацию
// - Можно логировать изменения
// - Можно рефакторить внутреннюю структуру

2. Public поля (антипаттерн)

// ❌ НЕПРАВИЛЬНО
public class User {
    public String email;  // Публичное поле
    public int age;       // Публичное поле
}

// Проблемы:
// - Нет контроля над значениями
user.age = -5; // Никакой проверки!
user.email = ""; // Невалидный email, но работает

// - Невозможно рефакторить
// Если позже решим хранить email в зашифрованном виде,
// придётся менять весь код, где используется user.email

// - Нет защиты
user.email = null; // NullPointerException позже

Когда использовать каждый модификатор?

1. Private (большинство случаев)

public class BankAccount {
    // ✅ Private поля — данные защищены
    private String accountNumber;
    private BigDecimal balance;        // Критичные данные!
    private LocalDateTime lastUpdated;
    
    private boolean isActive;          // Внутреннее состояние
    private List<Transaction> history; // Мутабельная коллекция
    
    // Публичные методы с контролем
    public BigDecimal getBalance() {
        return balance; // Только чтение
    }
    
    public void withdraw(BigDecimal amount) {
        if (amount.compareTo(balance) > 0) {
            throw new IllegalArgumentException("Недостаточно средств");
        }
        if (!isActive) {
            throw new IllegalStateException("Счёт закрыт");
        }
        balance = balance.subtract(amount);
        lastUpdated = LocalDateTime.now();
    }
    
    public void deposit(BigDecimal amount) {
        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Сумма должна быть положительной");
        }
        balance = balance.add(amount);
        lastUpdated = LocalDateTime.now();
    }
    
    public List<Transaction> getHistory() {
        // ✅ Возвращаем неизменяемую копию, не саму коллекцию
        return List.copyOf(history);
    }
}

2. Package-private (редко, для утилит)

// ✅ Package-private для вспомогательных классов внутри пакета
public class UserService {
    
    // Package-private метод, видна в пакете com.example.user
    void sendWelcomeEmail(User user) {
        // Внутренняя помощь, не для публичного API
    }
}

// Package-private конструктор
class InternalHelper {  // No public — видна только в пакете
    InternalHelper() { // Package-private конструктор
    }
}

3. Protected (при наследовании)

// ✅ Protected для методов, которые переопределяют подклассы
public abstract class PaymentProcessor {
    
    // Это может переопределить подкласс
    protected abstract void validatePayment(Payment payment);
    
    // Публичный метод использует protected
    public final void processPayment(Payment payment) {
        validatePayment(payment); // Вызывает переопределённый метод
        completeTransaction();
    }
    
    protected void completeTransaction() {
        // Может быть переопределено подклассом
    }
}

// Подкласс
public class CreditCardProcessor extends PaymentProcessor {
    @Override
    protected void validatePayment(Payment payment) {
        // Своя реализация валидации
    }
}

4. Public (только для публичного API)

// ✅ Public только для методов, которые вызывают снаружи
public class FileUtility {
    
    // Публичный API
    public String readFile(String path) {
        // ...
    }
    
    // Приватные помощники
    private void validatePath(String path) { }
    private String decodeContent(String content) { }
}

Исключения из правила "всё приватное"

1. Константы (final static)

public class Constants {
    // ✅ Public константы в порядке
    public static final String APP_NAME = "MyApp";
    public static final int MAX_USERS = 1000;
    public static final double PI = 3.14159;
    
    // Они не изменяются, так что безопасны
}

2. Value Objects и Records

// ✅ Records могут иметь публичные поля (неизменяемость гарантирована)
public record Point(int x, int y) { }

// Это OK потому что:
// - Все поля final
// - Нет setter'ов
// - Они immutable

Point p = new Point(10, 20);
System.out.println(p.x); // Публичное поле OK

3. Immutable классы

// ✅ Если класс полностью immutable, можно использовать публичные final поля
public final class Temperature {
    public final double celsius;  // Public final OK
    public final LocalDateTime timestamp;  // Public final OK
    
    public Temperature(double celsius) {
        this.celsius = celsius;
        this.timestamp = LocalDateTime.now();
    }
    
    // Нет setter'ов, поля final → безопасно
}

Лучшие практики инкапсуляции

1. Скрывайте мутабельные коллекции

// ❌ Опасно
public class Team {
    public List<Player> players = new ArrayList<>(); // Можно менять!
}

Team team = new Team();
team.players.clear(); // Очистили весь список!

// ✅ Правильно
public class Team {
    private List<Player> players = new ArrayList<>();
    
    public void addPlayer(Player player) {
        players.add(player);
    }
    
    public List<Player> getPlayers() {
        return List.copyOf(players); // Неизменяемая копия
    }
}

Team team = new Team();
team.getPlayers().clear(); // Ошибка: UnsupportedOperationException

2. Не возвращайте внутренние объекты напрямую

// ❌ Возвращаем внутренний объект
public class User {
    private Address address;
    
    public Address getAddress() {
        return address; // Кто-то может изменить!
    }
}

User user = service.getUser();
user.getAddress().setZipCode("12345"); // Меняем зарплату другого пользователя

// ✅ Возвращаем копию или неизменяемую версию
public class User {
    private Address address;
    
    public AddressDto getAddress() {
        return new AddressDto(address); // Копируем данные
    }
}

3. Валидация в setter'ах

// ✅ Контролируем инвариант класса
public class Product {
    private String name;
    private BigDecimal price;
    private int quantity;
    
    public void setPrice(BigDecimal price) {
        // Гарантируем позитивную цену
        if (price.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Цена должна быть > 0");
        }
        this.price = price;
    }
    
    public void setQuantity(int quantity) {
        if (quantity < 0) {
            throw new IllegalArgumentException("Количество не может быть отрицательным");
        }
        this.quantity = quantity;
    }
}

Уровни доступа в иерархии

package com.company.service;

// Интерфейс — публичный API
public interface UserService {              // PUBLIC
    User findById(Long id);
}

// Реализация — пакетный уровень
class UserServiceImpl implements UserService {  // PACKAGE
    
    private UserRepository repository;      // PRIVATE
    private UserValidator validator;       // PRIVATE
    
    @Override
    public User findById(Long id) {         // PUBLIC (из интерфейса)
        validate(id);
        return repository.find(id);
    }
    
    private void validate(Long id) {        // PRIVATE (только внутри)
        validator.validate(id);
    }
}

// Так никто не может использовать UserServiceImpl напрямую
// Они видят только интерфейс UserService (контракт)

Параллель с реальной жизнью

BankAccount (Банковский счёт)

✅ Private (закрыто):
- Баланс
- Номер счёта
- История транзакций

✅ Public с контролем:
- Метод снятия денег (с проверкой баланса)
- Метод пополнения (с проверкой суммы)
- Просмотр баланса (только чтение)

❌ Public без контроля:
- Прямой доступ к балансу
- Возможность менять баланс как угодно
- Это приводит к хаосу

Выводы

✅ Делайте приватными:

• Все поля класса (по умолчанию)
• Вспомогательные методы
• Внутреннее состояние

✅ Делайте публичными:

• Методы, которые являются частью контракта
• Методы, которые нужны пользователям класса

❌ Не делайте публичными:

• Мутабельные поля
• Поля без валидации
• Внутренние детали реализации

✅ Инкапсуляция = контроль:

• Контроль над валидацией
• Контроль над консистентностью данных
• Возможность менять реализацию
• Защита от ошибок

Правило большого пальца: Если вы думаете делать что-то public, сначала сделайте private, а потом откройте только если действительно нужно.