Cosmic Module

J

Qubits of DPK

March 14, 2026

Core Java

Layman Explanation

Packages are like folders on your computer — they organize related classes together. Access modifiers are like door locks — they control who can enter (access) a class or its members.

Packages

java
QUBITS OF DPK
1// Declaring a package (must be first line)
2package com.deepak.banking;
3
4// Importing from another package
5import java.util.ArrayList;
6import java.util.*;          // import all classes in java.util

Package Naming Convention

javascript
QUBITS OF DPK
1com.companyname.projectname.module
2
3Examples:
4com.google.auth
5com.netflix.api.streaming
6com.deepak.banking.service

Package = Folder Structure

javascript
QUBITS OF DPK
1src/
2└── com/
3    └── deepak/
4        └── banking/
5            ├── BankAccount.java
6            ├── Transaction.java
7            └── service/
8                └── PaymentService.java

Why Packages?

javascript
QUBITS OF DPK
11. Organize related classes together
22. Avoid naming conflicts (two classes named List in different packages)
33. Access control (default modifier = package-level access)
44. Distribute as JAR files

Access Modifiers

java
QUBITS OF DPK
1public class BankAccount {        // accessible everywhere
2    private double balance;        // only within BankAccount class
3    protected String holderName;   // class + package + subclasses
4    String accountType;            // default: class + same package only
5
6    private void validateAmount(double amount) { }  // private method
7    public double getBalance() { return balance; }  // public method
8}

Access Modifier Use Cases

java
QUBITS OF DPK
1// private — fields (encapsulation), helper methods
2private double balance;
3private void validate() { }
4
5// default — package-internal utilities
6class DatabaseHelper { }   // no modifier = package only
7
8// protected — parent class methods child should access
9protected void initialize() { }
10
11// public — API methods, service interfaces
12public void deposit(double amount) { }
13public class PaymentService { }

️ Traps

java
QUBITS OF DPK
1// Trap 1 — private not inherited
2class Parent { private void secret() { } }
3class Child extends Parent {
4    void test() { secret(); }  // ❌ not accessible!
5}
6
7// Trap 2 — protected accessible in subclass even different package
8class Parent { protected void show() { } }  // different package
9class Child extends Parent {
10    void test() { show(); }    // ✅ protected accessible in subclass
11}
12
13// Trap 3 — Can't reduce visibility in override
14class Parent { public void show() { } }
15class Child extends Parent {
16    private void show() { }    // ❌ can't reduce public to private!
17    protected void show() { }  // ❌ still reducing
18    public void show() { }     // ✅ same or more permissive
19}

Interview Answer (SDE-2)

"Packages organize related classes and prevent naming conflicts, following reverse domain naming convention. Access modifiers control visibility: private (class only), default (package), protected (package + subclasses), public (everywhere). In encapsulation, fields are private with public getters/setters. Protected is used for template method patterns where parent wants child to access but not external code. You cannot reduce access modifier visibility when overriding — can only maintain or increase."

Interview Questions & MAANG-Level Answers

Q1. What is the difference between protected and default access?
Default (package-private): accessible only within the same package — subclasses in DIFFERENT packages cannot access it. Protected: accessible within same package AND in subclasses anywhere (even different packages). Example: if Vehicle.engineType is protected, a Car in a different package that extends Vehicle can access engineType. If default, it can't. In practice: protected for members designed for inheritance across packages; default for package-internal implementation details.
Q2. Can you reduce access modifier visibility when overriding?
No — you can only maintain or increase visibility. If parent method is protected, override can be protected or public, but NOT private or default. Reason: the Liskov Substitution Principle — child must be usable wherever parent is used. If parent's method is accessible, child's override must be at least as accessible. public can only be overridden as public. Reducing visibility would break callers using parent reference.
Q3. What is a package and why is it used?
A package is a namespace that groups related classes and interfaces. Uses: (1) Organization — com.deepak.banking.service vs com.deepak.banking.model. (2) Naming conflict prevention — two classes named User can coexist in com.google.User and com.amazon.User. (3) Access control — default access restricts to same package. (4) Distribution — packages are deployed as JARs. Convention: reverse domain name (com.companyname.project.module).
Q4. What happens if two classes in different packages have the same name?
No conflict — they are treated as completely different classes because their fully qualified names differ: com.google.User vs com.amazon.User. When both are imported in the same file, Java shows ambiguity error — fix by using fully qualified name: com.google.User googleUser = new com.google.User(). This is exactly why package naming (reverse domain) exists — globally unique namespacing.
Q5. Can a private method be overridden?
No. Private methods are not visible outside the class — they're not inherited, so they cannot be overridden. If a child class defines a method with the same name and signature as a parent's private method, it's a completely new method (method hiding), not an override. @Override annotation would cause a compile error. Calling the method on a parent reference always invokes the parent's private method, regardless of the actual object type — no polymorphism.