What is "Access Control in Inheritance" about?

Can a child see its parent's secrets? Master the levels of Access Control and the power of the 'Protected' keyword.

What topics does "Access Control in Inheritance" cover?

This article covers: low level design, LLD, OOP, Object Oriented Design, SOLID principles, design patterns.

Access Control in Inheritance

We've learned that a child class inherits everything from its parent. But does that mean a child can see everything? If a parent has a "private" diary, can the child read it?

Understanding Access Control is the key to building secure and predictable inheritance hierarchies.

The Essentials

The "Security Clearance" guide to this post:

Private is Strict: Even children cannot see private members of their parent.
Protected is the Bridge: The protected keyword is designed specifically for inheritance: it allows children to see data while keeping it hidden from the rest of the world.
The Package Boundary: Folder structure affects what your code can see.
The "Family Circle" Analogy: Understanding access as levels of trust.

The Secret Diary: Why Private is Absolute

Imagine a User class (the Parent) has an attribute called password. You want every Student (the Child) to have a password, but you don't want the Student class logic to be able to touch or change the password directly.

In code, private means private.

Java Example

Java

public class User {
    private String password;
}

public class Student extends User {
    void printPass() {
        System.out.println(this.password); // COMPILE-TIME ERROR!
    }
}

Even though the Student object physically contains the password data in memory, the "Student" part of the code doesn't have the clearance to look at it. This is the ultimate form of Encapsulation.

The Protected Keyword: Trusting the Family

Sometimes, you want the child to be able to see the parent's data. For example, a User might have a username that the Student needs to access for a specialized login method.

This is where the Protected modifier comes in.

The Clearances

Private: Only the parent can see. (The "Personal Diary")
Default (Package-Private): Anyone in the same folder can see. (The "Apartment Hallway")
Protected: Anyone in the family tree (children) can see, even if they are in a different folder. (The "Family Heirloom")
Public: The whole world can see. (The "Town Square")

Access Control in Action: The Hierarchy Mystery

Private (Strict Secret)

Even children cannot see private data. It is locked inside the parent class forever. If a child needs it, it's stuck.

class User {
private psp: number;
}

class Student extends User {
get() { return this.psp; } // ERROR!
}

Like a personal diary. Not even your own children are allowed to read it without your permission (methods).

No Family Access

✓

Protected (Family Trust)

The protected keyword allows children to see the data, but keeps it hidden from the outside world.

class User {
protected username: string;
}

class Student extends User {
get() { return this.username; } // OK!
}

Like a family heirloom. It stays within the family tree, but remains private to the general public.

Inherited Trust

Code Implementation: Modifiers Across Languages

Here is how you implement these varying levels of trust across Java and TypeScript:

class User {
    private personalDiary: string = "Private secrets";
    protected familyHeirloom: string = "Golden Watch";
    public townSquareNews: string = "Open to all";
}

class Student extends User {
    showSecrets() {
        // console.log(this.personalDiary); // ERROR!
        console.log(this.familyHeirloom);  // OK!
        console.log(this.townSquareNews);  // OK!
    }
}

The Mystery of the Folder (Package)

In Java, folders are called Packages. Access control often depends on whether two classes are in the same package.

If they are in the same package: They are "Neighbors." Neighbors can see each other's default and protected data.
If they are in different packages: They are "Strangers." Strangers can only see public data, unless they are in an inheritance relationship (then they can see protected).

Best Practice: Getters and Setters Over Protected

Even though protected exists, many professional LLD engineers (including those at Google and Amazon) recommend keeping attributes private and using protected getters.

Why?

If you make an attribute protected, you lose control. A child class can change the value to something invalid, and you won't know why. But if you use a method, you can add validation logic:

Java

protected void setUsername(String name) {
    if (name != null) this.username = name;
}

Try to access all three attributes from inside Student. Which ones work?

Data is protected, but how is it actually created? Let's uncover the Constructor Chain in the next post.