Encapsulation: Your Code’s Secret Diary with a Lock 🔐

Imagine you have a treasure chest. You don’t leave it wide open for everyone to grab whatever they want. Instead, you keep it locked, and only YOU decide what goes in, what comes out, and who gets to peek inside.

That’s encapsulation! It’s like giving your code a private diary with a lock. Only the diary owner (your class) controls what others can read or write.

🏠 The House Analogy

Think of a class as a house:

• The rooms inside are your private data (variables)
• The doors and windows are how others interact with your house (methods)
• The locks on doors are your access modifiers

You don’t let strangers walk into your bedroom, right? But you might let them ring the doorbell and you’ll answer!

1. Encapsulation Principles

What’s the Big Idea?

Encapsulation means: Hide your stuff, but provide safe ways to use it.

Three Golden Rules:

1. Keep data private - Your variables are YOUR business
2. Control access - Decide WHO can see or change things
3. Protect your state - Don’t let anyone mess up your data

Real Life Example

Think of a piggy bank:

• You can’t see exactly how much money is inside (private data)
• You can only add coins through the slot (controlled input)
• You shake it to guess the amount (controlled output)
• Nobody can steal money without breaking it (protection!)

class PiggyBank {
    private int coins = 0;  // Hidden!

    public void addCoin() {
        coins++;  // Safe way to add
    }

    public int shake() {
        return coins;  // Safe way to check
    }
}

2. Access Modifiers

The Four Locks for Your Doors

Java gives you 4 types of locks for your code:

Visual Guide

🔒 private    → Only inside THIS class
📁 default    → Classes in SAME package
🔓 protected  → Same package + children classes
🌍 public     → EVERYONE, EVERYWHERE

Code Example

class MyHouse {
    private String diary = "Secrets!";
    String familyAlbum = "Photos";  // default
    protected String recipe = "Grandma's cookies";
    public String doorbell = "Ring me!";
}

When to Use What?

• private: Almost always for your variables! 🏆
• public: For methods others need to call
• protected: When children classes need access
• default: Rarely used, be careful!

3. Getters and Setters

The Polite Doorkeepers

Since your data is private (locked away), how do others use it?

Meet getters and setters - your friendly doorkeepers!

• Getter: “You want to SEE something? Let me fetch it for you!”
• Setter: “You want to CHANGE something? Let me check if that’s okay first!”

The Magic Pattern

class Person {
    private int age;  // Hidden!

    // GETTER - lets others READ the age
    public int getAge() {
        return age;
    }

    // SETTER - lets others CHANGE the age
    public void setAge(int newAge) {
        if (newAge > 0) {  // Validation!
            age = newAge;
        }
    }
}

Why Not Just Make Age Public?

Without encapsulation:

person.age = -50;  // Oops! Negative age?
person.age = 9999; // A 9999-year-old?

With encapsulation:

person.setAge(-50);  // Setter says NO!
person.setAge(25);   // Setter says OK!

The Power of Control

Your setter is like a security guard:

• Checks if the value makes sense
• Can transform data before storing
• Can notify when things change
• Can log who changed what

4. Records

The Lazy Programmer’s Dream ✨

Writing getters for every field is boring! Java 16+ says: “I got you!”

Records automatically create:

• Private fields
• Getters for all fields
• A constructor
• equals(), hashCode(), toString()

Before Records (So Much Typing!)

class Student {
    private String name;
    private int grade;

    public Student(String name, int grade) {
        this.name = name;
        this.grade = grade;
    }

    public String getName() { return name; }
    public int getGrade() { return grade; }
    // Plus equals, hashCode, toString...
}

With Records (One Line!)

record Student(String name, int grade) { }

That’s it! You get everything automatically!

Using a Record

Student bob = new Student("Bob", 95);
System.out.println(bob.name());   // Bob
System.out.println(bob.grade());  // 95
System.out.println(bob);          // Student[name=Bob, grade=95]

📝 Note: Records are immutable (can’t change after creation) and use name() instead of getName().

5. Sealed Classes

The VIP Guest List 🎫

What if you want to control WHO can be your child class?

Sealed classes let you say: “Only THESE specific classes can extend me!”

The Nightclub Analogy

Imagine you’re a nightclub owner:

• Regular class: Anyone can join your club
• Final class: Nobody new can join, ever
• Sealed class: Only people on the VIP list can join

Code Example

// Only these THREE classes can extend Shape!
sealed class Shape
    permits Circle, Rectangle, Triangle {
}

final class Circle extends Shape { }
final class Rectangle extends Shape { }
final class Triangle extends Shape { }

// This would be ILLEGAL:
// class Pentagon extends Shape { }  // NOT on the list!

Why Use Sealed Classes?

1. Pattern matching: Compiler knows ALL possibilities
2. Security: No unexpected children sneaking in
3. Design control: Your API, your rules!

graph TD
    A[Shape - sealed] --> B[Circle - final]
    A --> C[Rectangle - final]
    A --> D[Triangle - final]
    A -.->|❌ Not allowed| E[Pentagon]

6. Immutability

The Stone Tablet Principle 🪨

An immutable object is like a stone tablet:

• Once carved, it CANNOT be changed
• Want different text? Create a NEW tablet!

Why Immutability Rocks

1. Thread-safe: Multiple threads can read safely
2. Predictable: No surprise changes
3. Cache-friendly: Same object, always same value
4. Easy debugging: Value at creation = value forever

Making an Immutable Class

final class ImmutablePerson {
    private final String name;
    private final int age;

    public ImmutablePerson(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() { return name; }
    public int getAge() { return age; }

    // No setters! Once created, forever the same.

    // Want to change? Create new object!
    public ImmutablePerson withAge(int newAge) {
        return new ImmutablePerson(this.name, newAge);
    }
}

The Recipe for Immutability

1. Make the class final (no children)
2. Make all fields private final
3. No setters, ever!
4. Only getters that return copies (for mutable objects)
5. Set everything in the constructor

String is Immutable!

Did you know? String in Java is immutable!

String greeting = "Hello";
greeting.toUpperCase();  // Returns "HELLO", but...
System.out.println(greeting);  // Still "Hello"!

greeting = greeting.toUpperCase();  // Now it's "HELLO"
// (Actually creates a NEW String object!)

7. Composition vs Inheritance

The Great Debate: “Has-A” vs “Is-A”

Two ways to build relationships between classes:

The LEGO Analogy 🧱

Inheritance = You ARE a specific LEGO set (fixed design) Composition = You HAVE LEGO pieces (mix and match!)

Inheritance Example

class Animal {
    void eat() { System.out.println("Eating..."); }
}

class Dog extends Animal {
    void bark() { System.out.println("Woof!"); }
}
// Dog IS-A Animal

Composition Example

class Engine {
    void start() { System.out.println("Vroom!"); }
}

class Car {
    private Engine engine;  // Car HAS-A Engine

    Car() {
        engine = new Engine();
    }

    void startCar() {
        engine.start();
    }
}

Why Prefer Composition?

graph LR
    A[Composition] --> B[🔄 Easy to change parts]
    A --> C[🧪 Easier testing]
    A --> D[🔓 Loose coupling]
    A --> E[🎯 More flexible]

    F[Inheritance] --> G[🔗 Tight coupling]
    F --> H[📦 Fragile base class problem]
    F --> I[🚫 Can't extend multiple classes]

The Golden Rule

“Favor composition over inheritance” - Gang of Four

Use inheritance when:

• There’s a true “is-a” relationship
• You need polymorphism

Use composition when:

• You want flexibility
• You’re sharing behavior, not identity
• You might need to change parts later

Real World Example

Bad (Inheritance Abuse):

class ArrayList extends LinkedList { }  // ArrayList IS-A LinkedList? NO!

Good (Composition):

class ShoppingCart {
    private List<Item> items;  // Cart HAS items
}

🎯 Quick Summary

🌟 The Encapsulation Mindset

Think of encapsulation as being a responsible adult:

1. Don’t overshare - Keep things private by default
2. Set boundaries - Control what others can do
3. Be predictable - Immutability prevents surprises
4. Build with parts - Composition over inheritance
5. Plan your family - Sealed classes for controlled extension

Remember: Good encapsulation makes your code:

• ✅ Easier to understand
• ✅ Safer to modify
• ✅ Harder to break
• ✅ More professional

You’re not just writing code - you’re building secure, reliable software. And that’s what real developers do! 🚀