L'incapsulamento significa raggruppare i dati e i metodi che operano su di essi all'interno di una sola unità (una classe) e nascondere lo stato interno dietro un'interfaccia pubblica controllata. Chi chiama interagisce attraverso i metodi, non manipolando direttamente i campi.
Se chiunque può modificare un campo direttamente, non puoi mai garantire che l'oggetto rimanga valido. L'incapsulamento permette alla classe di applicare i propri invarianti.
public class Account {
private double balance; // hidden: no direct access
public void withdraw(double amount) {
if (amount <= 0) // guard the invariant
throw new IllegalArgumentException("amount must be positive");
if (amount > balance)
throw new IllegalStateException("insufficient funds");
balance -= amount; // only valid changes get through
}
public double getBalance() { return balance; }
}
// Without encapsulation, this would be possible and disastrous:
account.balance = -5000; // bypasses every rule
Poiché balance è privato, l'unico percorso per modificarlo passa attraverso withdraw, che protegge le regole.
L'incapsulamento non significa "aggiungere un getter/setter per ogni campo". Esporre un setter per tutto è appena meglio dei campi pubblici. Esponi il comportamento, non lo stato grezzo.
L'incapsulamento mantiene gli invarianti in un unico posto, quindi un bug nella gestione del saldo può trovarsi solo dentro Account, non sparso in tutto il codebase.
Ti permette anche di cambiare la rappresentazione interna più tardi (memorizzare i centesimi come intero, aggiungere logging) senza rompere chi chiama, perché dipendono solo dall'interfaccia pubblica.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona