Core Principles

The four pillars of object-oriented programming: encapsulation, inheritance, polymorphism, and abstraction — illustrated through real-world business domain examples.

---

1. Definition

What is OOP?

Object-Oriented Programming (OOP) is a programming paradigm that organizes data and the operations on it into objects. It is the foundational design of the Java language — java.lang.Object is the root of every class hierarchy.

Why does it exist?

The procedural approach quickly becomes unmanageable in large codebases: data structures and the logic that operates on them become scattered. OOP solves this problem:

• Modularity — independent units that can be developed in isolation
• Reusability — extracting common behavior instead of copy-pasting
• Maintainability — the scope of a change is clearly bounded
• Modeling — natural mapping of business domain concepts to code

Where does it fit?

OOP sits among the main programming paradigms:

• Procedural — example: C
• Object-Oriented — Java, C#, Kotlin ← this topic
• Functional — Haskell, Scala
• Hybrid — Java 8+ and Kotlin combine OOP with FP elements

Modern Java (8+) combines OOP with functional elements — lambda expressions, the Stream API, Optional — but its foundation remains object-oriented.

---

2. Core Concepts

2.1 Encapsulation

Encapsulation is the practice of bundling data and the operations that act on it into a single unit, while restricting direct external access to that data.

Access modifiers

Why does it matter?

• Invariant protection — the object's internal state always stays consistent
• Change management — the internal implementation can be swapped without changing client code
• Minimal API surface — only expose what actually needs to be used

// An encapsulated model of a payment transaction
public class PaymentTransaction {

    // Internal state — cannot be modified directly from outside
    private final String transactionId;
    private BigDecimal amount;
    private Currency currency;
    private TransactionStatus status;

    public PaymentTransaction(String transactionId, BigDecimal amount, Currency currency) {
        // Invariant: amount must be positive
        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Amount must be positive: " + amount);
        }
        this.transactionId = transactionId;
        this.amount = amount;
        this.currency = currency;
        this.status = TransactionStatus.PENDING;
    }

    // State transition protected by business rules
    public void approve() {
        if (this.status != TransactionStatus.PENDING) {
            throw new IllegalStateException(
                "Only a PENDING transaction can be approved, current status: " + this.status
            );
        }
        this.status = TransactionStatus.APPROVED;
    }

    // Getter — amount is readable but cannot be overwritten directly
    public BigDecimal getAmount() {
        return amount;
    }

    // No setAmount()! Amount changes go through a business operation.
    public void applyDiscount(BigDecimal percentage) {
        if (this.status != TransactionStatus.PENDING) {
            throw new IllegalStateException("Discount can only be applied in PENDING status");
        }
        this.amount = this.amount.multiply(BigDecimal.ONE.subtract(percentage));
    }
}

Key takeaway: Don't just write getters/setters — think about which business operations should drive state changes.

---

2.2 Inheritance

Inheritance allows a class to inherit the fields and methods of another class. In Java it is expressed with the extends keyword — single inheritance only (a class can have at most one parent class).

IS-A relationship

Inheritance expresses an IS-A (is a kind of) relationship:

Examples of an IS-A relationship:

• EmailNotificationSender is a NotificationSender
• SmsNotificationSender is a NotificationSender
• PushNotificationSender is a NotificationSender

Method overriding

A subclass can override a parent method if:

• The method signature is the same (name + parameters)
• The return type is identical or narrower (covariant return)
• The access modifier is the same or wider (cannot be narrowed)
• The @Override annotation is not mandatory, but strongly recommended — the compiler will catch typos

// Common logic in the parent class
public abstract class NotificationSender {

    private final AuditLogger auditLogger;

    protected NotificationSender(AuditLogger auditLogger) {
        this.auditLogger = auditLogger;
    }

    // Template Method pattern — the common flow is here; the specific part is supplied by subclasses
    public final void send(Notification notification) {
        validate(notification);
        doSend(notification);                     // abstract — implemented by subclass
        auditLogger.log(notification, channel()); // shared audit log
    }

    protected void validate(Notification notification) {
        if (notification.getRecipient() == null || notification.getRecipient().isBlank()) {
            throw new IllegalArgumentException("Recipient must not be empty");
        }
    }

    // Subclasses provide the actual sending logic
    protected abstract void doSend(Notification notification);
    protected abstract String channel();
}

public class EmailNotificationSender extends NotificationSender {

    private final EmailGateway emailGateway;

    public EmailNotificationSender(AuditLogger auditLogger, EmailGateway emailGateway) {
        super(auditLogger);
        this.emailGateway = emailGateway;
    }

    @Override
    protected void doSend(Notification notification) {
        emailGateway.sendEmail(
            notification.getRecipient(),
            notification.getSubject(),
            notification.getBody()
        );
    }

    @Override
    protected String channel() {
        return "EMAIL";
    }
}

Warning: Inheritance creates tight coupling between parent and subclass. Use it deliberately — → see: 7. Deep Dive.

---

2.3 Polymorphism

Polymorphism means that the same interface can hide different implementations. Java has two forms:

Compile-time (static) polymorphism — Method Overloading

The compiler decides which method to call based on the number and types of parameters:

public class RiskScoreCalculator {

    // Default risk calculation
    public RiskScore calculate(Transaction transaction) {
        return evaluate(transaction, RiskProfile.DEFAULT);
    }

    // Profile-based risk calculation — overloaded version
    public RiskScore calculate(Transaction transaction, RiskProfile profile) {
        return evaluate(transaction, profile);
    }

    // Batch risk calculation — another overload
    public List<RiskScore> calculate(List<Transaction> transactions) {
        return transactions.stream()
            .map(this::calculate)
            .toList();
    }

    private RiskScore evaluate(Transaction tx, RiskProfile profile) {
        // ... risk evaluation logic
        return new RiskScore(tx.getId(), computeScore(tx, profile));
    }
}

Runtime (dynamic) polymorphism — Method Overriding

The JVM decides at runtime which implementation to invoke (virtual method dispatch):

// Interface — the contract
public interface PaymentProcessor {
    PaymentResult process(PaymentRequest request);
    boolean supports(PaymentMethod method);
}

// Implementation: card payment
public class CardPaymentProcessor implements PaymentProcessor {

    @Override
    public PaymentResult process(PaymentRequest request) {
        // Validate card details, tokenize, call acquirer
        CardDetails card = request.getCardDetails();
        AuthResponse auth = acquirerGateway.authorize(card, request.getAmount());
        return new PaymentResult(auth.isSuccessful(), auth.getAuthCode());
    }

    @Override
    public boolean supports(PaymentMethod method) {
        return method == PaymentMethod.CREDIT_CARD || method == PaymentMethod.DEBIT_CARD;
    }
}

// Implementation: bank transfer
public class BankTransferProcessor implements PaymentProcessor {

    @Override
    public PaymentResult process(PaymentRequest request) {
        // Validate IBAN, call SEPA/ACH
        BankAccount account = request.getBankAccount();
        TransferResult result = bankingGateway.initiateTransfer(account, request.getAmount());
        return new PaymentResult(result.isAccepted(), result.getReferenceId());
    }

    @Override
    public boolean supports(PaymentMethod method) {
        return method == PaymentMethod.BANK_TRANSFER;
    }
}

// Usage — the calling code doesn't know (or care) which implementation runs
public class PaymentService {

    private final List<PaymentProcessor> processors;

    public PaymentService(List<PaymentProcessor> processors) {
        this.processors = processors;
    }

    public PaymentResult processPayment(PaymentRequest request) {
        // Decided at runtime which processor runs
        return processors.stream()
            .filter(p -> p.supports(request.getMethod()))
            .findFirst()
            .orElseThrow(() -> new UnsupportedPaymentMethodException(request.getMethod()))
            .process(request);
    }
}

---

2.4 Abstraction

Abstraction is the practice of exposing essential details while hiding irrelevant ones. Java provides two tools for this:

Abstract class vs Interface

When to use which?

• Abstract class → when there is shared state or shared logic that subclasses will reuse (e.g., NotificationSender above — has a shared auditLogger)
• Interface → when defining a behavioral contract that any class — even unrelated ones — can implement (e.g., PaymentProcessor — card and bank transfer are completely different classes)

// Interface — pure behavioral contract
public interface RiskEvaluator {
    RiskLevel evaluate(Transaction transaction);
    String evaluatorName();
}

// Abstract class — shared logic and state
public abstract class AbstractRiskEvaluator implements RiskEvaluator {

    private final RiskThresholdConfig config;
    private final MetricsCollector metrics;

    protected AbstractRiskEvaluator(RiskThresholdConfig config, MetricsCollector metrics) {
        this.config = config;
        this.metrics = metrics;
    }

    @Override
    public final RiskLevel evaluate(Transaction transaction) {
        long start = System.nanoTime();
        try {
            double score = computeScore(transaction);   // subclass logic
            return mapToLevel(score);                    // shared mapping
        } finally {
            metrics.record(evaluatorName(), System.nanoTime() - start);
        }
    }

    // Subclasses provide their own scoring logic
    protected abstract double computeScore(Transaction transaction);

    // Shared mapping — converts a score into a RiskLevel based on config
    private RiskLevel mapToLevel(double score) {
        if (score >= config.getHighThreshold()) return RiskLevel.HIGH;
        if (score >= config.getMediumThreshold()) return RiskLevel.MEDIUM;
        return RiskLevel.LOW;
    }

    protected RiskThresholdConfig getConfig() {
        return config;
    }
}

// Concrete implementation — velocity-based risk
public class VelocityRiskEvaluator extends AbstractRiskEvaluator {

    private final TransactionHistoryRepository historyRepo;

    public VelocityRiskEvaluator(RiskThresholdConfig config, MetricsCollector metrics,
                                  TransactionHistoryRepository historyRepo) {
        super(config, metrics);
        this.historyRepo = historyRepo;
    }

    @Override
    protected double computeScore(Transaction transaction) {
        // Based on the number of transactions in the last 24 hours
        int recentCount = historyRepo.countRecent(transaction.getUserId(), Duration.ofHours(24));
        int limit = getConfig().getVelocityLimit();
        return Math.min((double) recentCount / limit, 1.0);
    }

    @Override
    public String evaluatorName() {
        return "VELOCITY";
    }
}

---

3. Practical Usage

When to use each pillar

When NOT to use

---

4. Code Examples

4.1 Encapsulation — Immutable value object

/**
 * Immutable monetary amount — fully encapsulated.
 * Once created it cannot be modified; thread-safe.
 */
public final class Money {

    private final BigDecimal amount;
    private final Currency currency;

    public Money(BigDecimal amount, Currency currency) {
        Objects.requireNonNull(amount, "Amount must not be null");
        Objects.requireNonNull(currency, "Currency must not be null");
        // Two decimal places, banker's rounding
        this.amount = amount.setScale(2, RoundingMode.HALF_EVEN);
        this.currency = currency;
    }

    // Business operation — returns a new object (immutable)
    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new CurrencyMismatchException(this.currency, other.currency);
        }
        return new Money(this.amount.add(other.amount), this.currency);
    }

    public Money multiply(int quantity) {
        return new Money(this.amount.multiply(BigDecimal.valueOf(quantity)), this.currency);
    }

    public boolean isGreaterThan(Money other) {
        ensureSameCurrency(other);
        return this.amount.compareTo(other.amount) > 0;
    }

    private void ensureSameCurrency(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new CurrencyMismatchException(this.currency, other.currency);
        }
    }

    // Read-only — no setters
    public BigDecimal getAmount() { return amount; }
    public Currency getCurrency() { return currency; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Money money)) return false;
        return amount.compareTo(money.amount) == 0 && currency.equals(money.currency);
    }

    @Override
    public int hashCode() {
        return Objects.hash(amount.stripTrailingZeros(), currency);
    }
}

4.2 Inheritance — Template Method for notification sending

→ See the NotificationSender example in Section 2.2 Inheritance.

4.3 Polymorphism — Strategy pattern for risk evaluation

// Multiple evaluators — each examines a different aspect
public class CompositeRiskEvaluator implements RiskEvaluator {

    private final List<RiskEvaluator> evaluators;

    public CompositeRiskEvaluator(List<RiskEvaluator> evaluators) {
        this.evaluators = List.copyOf(evaluators); // defensive copy
    }

    @Override
    public RiskLevel evaluate(Transaction transaction) {
        // Return the highest risk level found
        return evaluators.stream()
            .map(e -> e.evaluate(transaction))
            .max(Comparator.comparingInt(RiskLevel::severity))
            .orElse(RiskLevel.LOW);
    }

    @Override
    public String evaluatorName() {
        return "COMPOSITE";
    }
}

4.4 Common mistake — ❌ / ✅

// ❌ BAD: Violation of encapsulation — public mutable fields
public class PaymentOrder {
    public List<LineItem> items = new ArrayList<>();  // anyone can modify!
    public BigDecimal totalAmount;                     // can be overwritten directly!
}

// Usage — invariants are easily violated:
PaymentOrder order = new PaymentOrder();
order.items.add(new LineItem("Widget", new BigDecimal("10.00")));
order.totalAmount = new BigDecimal("-999.99");  // ⚠️ Negative amount!

// ✅ GOOD: Modifiable only through business operations; invariants protected
public class PaymentOrder {

    private final List<LineItem> items = new ArrayList<>();
    private BigDecimal totalAmount = BigDecimal.ZERO;

    public void addItem(LineItem item) {
        Objects.requireNonNull(item, "Item must not be null");
        if (item.getPrice().compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Item price must be positive");
        }
        this.items.add(item);
        this.totalAmount = this.totalAmount.add(item.getPrice());
    }

    // Defensive copy — callers cannot modify the internal list
    public List<LineItem> getItems() {
        return Collections.unmodifiableList(items);
    }

    public BigDecimal getTotalAmount() {
        return totalAmount;
    }
}

---

5. Trade-offs

---

6. Common Mistakes

6.1 — Anemic Domain Model

// ❌ The object is just a data holder; logic lives in a "service"
public class Transaction {
    private String id;
    private BigDecimal amount;
    private TransactionStatus status;

    // Getters + Setters everywhere...
    public void setStatus(TransactionStatus status) { this.status = status; }
    public void setAmount(BigDecimal amount) { this.amount = amount; }
}

public class TransactionService {
    public void approve(Transaction tx) {
        if (tx.getStatus() == TransactionStatus.PENDING) {
            tx.setStatus(TransactionStatus.APPROVED);  // poking state from outside
        }
    }
}

// ✅ Rich Domain Model — the object is responsible for its own state
public class Transaction {
    private final String id;
    private BigDecimal amount;
    private TransactionStatus status;

    public void approve() {
        if (this.status != TransactionStatus.PENDING) {
            throw new IllegalStateException("Only a PENDING transaction can be approved");
        }
        this.status = TransactionStatus.APPROVED;
    }

    // No setStatus()! State transitions happen through business operations.
}

6.2 — Inheritance for code reuse (HAS-A instead of IS-A)

// ❌ BAD: PaymentLogger is NOT "a kind of" ArrayList!
public class PaymentLogger extends ArrayList<String> {
    public void logPayment(String message) {
        this.add("[PAYMENT] " + message);
    }
}
// Problem: PaymentLogger inherits ALL public ArrayList methods
// — clear(), remove(), set() — which are irrelevant for a logger!

// ✅ GOOD: Composition — the logger CONTAINS a list, it does not EXTEND one
public class PaymentLogger {
    private final List<String> logs = new ArrayList<>();

    public void logPayment(String message) {
        logs.add("[PAYMENT] " + message);
    }

    // Only expose what is actually needed
    public List<String> getRecentLogs(int count) {
        int start = Math.max(0, logs.size() - count);
        return Collections.unmodifiableList(logs.subList(start, logs.size()));
    }
}

6.3 — Leaky Abstraction (internal implementation leaking out)

// ❌ The internal list reference leaks out
public class RiskAssessmentResult {
    private final List<RiskFactor> factors;

    public RiskAssessmentResult(List<RiskFactor> factors) {
        this.factors = factors;  // ⚠️ No defensive copy!
    }

    public List<RiskFactor> getFactors() {
        return factors;  // ⚠️ Mutable reference — callers can modify it!
    }
}

// Caller accidentally (or intentionally) modifies internal state:
List<RiskFactor> factors = result.getFactors();
factors.clear();  // 💥 The original object's internal state is now corrupted!

// ✅ Defensive copy + unmodifiable view
public class RiskAssessmentResult {
    private final List<RiskFactor> factors;

    public RiskAssessmentResult(List<RiskFactor> factors) {
        this.factors = List.copyOf(factors);  // Defensive copy in constructor
    }

    public List<RiskFactor> getFactors() {
        return factors;  // List.copyOf() already returns an unmodifiable list
    }
}

6.4 — Missing @Override annotation

// ❌ Typo in method name — creates a new method instead of overriding
public class CustomRiskEvaluator extends AbstractRiskEvaluator {

    // Should be computeScore, not komputScore!
    // Without @Override the compiler says nothing
    protected double komputScore(Transaction transaction) {
        return 0.5;
    }
    // Result: AbstractRiskEvaluator's abstract computeScore() runs instead
    // — or if a default implementation exists, the bug is silent
}

// ✅ The @Override annotation causes a compile error if the method doesn't exist in the parent
public class CustomRiskEvaluator extends AbstractRiskEvaluator {

    @Override  // ← The compiler verifies this is actually an override
    protected double computeScore(Transaction transaction) {
        return 0.5;
    }
}

---

7. Deep Dive

Composition over Inheritance

A principle known since the Gang of Four (GoF) book: prefer composition over inheritance. Inheritance is the strongest form of coupling in Java — if the parent changes, every subclass is potentially affected.

// ❌ Inheritance-based approach — rigid, hard to extend
public class FraudCheckingPaymentService extends PaymentService {
    @Override
    public PaymentResult process(PaymentRequest request) {
        fraudChecker.check(request);
        return super.process(request);
    }
}
// What if I also want rate limiting? Another extends?
// FraudCheckingRateLimitedPaymentService extends FraudCheckingPaymentService? 🤮

// ✅ Composition + Decorator pattern — flexible and extensible
public class FraudCheckingPaymentProcessor implements PaymentProcessor {

    private final PaymentProcessor delegate;
    private final FraudChecker fraudChecker;

    public FraudCheckingPaymentProcessor(PaymentProcessor delegate, FraudChecker fraudChecker) {
        this.delegate = delegate;
        this.fraudChecker = fraudChecker;
    }

    @Override
    public PaymentResult process(PaymentRequest request) {
        fraudChecker.check(request);       // precondition
        return delegate.process(request);  // delegation
    }

    @Override
    public boolean supports(PaymentMethod method) {
        return delegate.supports(method);
    }
}
// Rate limiting? Create a RateLimitingPaymentProcessor that also delegates.
// They can be freely combined and nested.

SOLID connection

The OOP pillars alone are not enough — the SOLID principles define how to apply them correctly:

The dangers of over-abstraction

Codebase size:        ~5,000 lines
Abstract layers:      8 (Controller → Service → Facade → Strategy → Handler → Processor → Adapter → Gateway)
One request trace:    15 classes, 3 interfaces
New developer onboarding: 3 weeks 😱

Rule of thumb: Ask yourself — "If I need to change this tomorrow, how many files do I have to open to understand the flow?" If the answer is 6+, you probably have too much abstraction.

Sealed classes (Java 17+)

Modern Java's sealed keyword restricts the inheritance hierarchy — only permitted subclasses can exist:

// Exactly three kinds of notification outcome are possible — no others
public sealed interface NotificationOutcome
    permits Delivered, Failed, Retrying {
}

public record Delivered(Instant timestamp) implements NotificationOutcome {}
public record Failed(String reason, Instant timestamp) implements NotificationOutcome {}
public record Retrying(int attempt, Instant nextRetry) implements NotificationOutcome {}

// Pattern matching — the compiler verifies exhaustiveness
public String describe(NotificationOutcome outcome) {
    return switch (outcome) {
        case Delivered d   -> "Delivered at: " + d.timestamp();
        case Failed f      -> "Failed: " + f.reason();
        case Retrying r    -> "Retrying, attempt #" + r.attempt();
        // No default branch needed — sealed ensures exhaustiveness
    };
}

Interview tip

Question: "When would you use an abstract class vs an interface?"

Good answer: "If there is shared state or a shared implementation that subclasses will reuse — abstract class. If it's a purely behavioral contract that unrelated classes can implement — interface. Since Java 8, interfaces can also have default methods, which blurs the line. But the key distinction is that an interface has no state (no instance fields)."

---

8. Interview Questions

How do you explain encapsulation vs abstraction without mixing them up?

Encapsulation hides internal state behind a controlled API, while abstraction hides unnecessary detail so the caller can work with a simpler mental model.

Why is composition usually safer than inheritance?

Because composition keeps coupling weaker. Inheritance makes subclasses sensitive to parent behavior and evolution, while composition allows behavior to be assembled and replaced more safely.

When is an abstract class better than an interface?

When several closely related classes need shared implementation or shared state. If you only need a contract across unrelated types, an interface is usually better.

What is the best way to talk about the four OOP pillars in an interview?

Define each pillar briefly, connect it to a Java construct, and mention a trade-off. Strong answers combine definition, language feature, and judgment.

---

9. Glossary

---

10. Cheatsheet

1. Encapsulation = data + operations in one unit, access restricted by modifiers
2. Inheritance = IS-A relationship, extends keyword, single inheritance in Java
3. Polymorphism = compile-time (overloading) + runtime (overriding, virtual dispatch)
4. Abstraction = abstract class (state + partial impl.) vs interface (contract)
5. Don't write getters/setters automatically — think in business operations
6. Prefer composition over inheritance
7. Always use the @Override annotation
8. Use interfaces at module boundaries, abstract classes for shared implementation
9. If the inheritance hierarchy is 3+ levels deep, refactor toward composition
10. sealed (Java 17+) is the controlled form of inheritance — enables exhaustive pattern matching