Coding Workspace

Data Structures and Algorithms for Every Java Developer

Whether you're preparing for a coding interview, building scalable backend systems, or aiming to write high-performance applications, a solid understanding of data structures and algorithms (DSA) is non-negotiable. In this blog, we’ll walk through the must-know DSA topics specifically for Java developers, with real-world relevance and Java-specific tips.

Why Java Developers Must Learn DSA

Interviews: DSA is the backbone of technical interviews at FAANG and top-tier companies.
Performance: The right data structure can drastically reduce latency and resource usage.
Scalability: Efficient algorithms make your systems handle 10x more users without 10x cost.
Problem Solving: Builds logical thinking and improves your debugging abilities.

Core Data Structures in Java

1. Linear Data Structures

Data Structure	Use Case	Java API
Array	Fast access by index	`int[]`, `ArrayList<T>`
Linked List	Dynamic memory allocation	`LinkedList<T>`
Stack	LIFO operations (undo, backtracking)	`Stack<T>`
Queue/Deque	FIFO, Double-ended operations	`Queue<T>`, `Deque<T>`

2. Hash-Based Structures

Data Structure	Use Case	Java API
HashMap	Key-value storage	`HashMap<K, V>`
HashSet	Fast membership test	`HashSet<T>`

3. Tree-Based Structures

Data Structure	Use Case	Java API
Binary Tree/BST	Hierarchical storage	Custom
Red-Black Tree	Balanced search tree	`TreeMap<K, V>`, `TreeSet<T>`
Trie	Prefix searching (e.g., autocomplete)	Custom

4. Heap (Priority Queue)

Used for scheduling, top-k problems, and greedy algorithms
Java: PriorityQueue<T> with custom Comparator

5. Graph

Represent networks (social, pathfinding, dependency graphs)
Java: Adjacency List/Matrix with custom classes or JGraphT

6. Advanced

Structure	Use Case
Segment Tree	Range queries
Fenwick Tree	Prefix sums
Disjoint Set (Union-Find)	Connected components, Kruskal’s MST

Algorithms to Focus On

Searching & Sorting

Binary Search, Merge Sort, Quick Sort
Heap Sort, Counting Sort
Java APIs: Arrays.sort(), Collections.sort(), custom Comparator

Recursion & Backtracking

N-Queens, Maze Path, Subsets, Permutations

Dynamic Programming

Knapsack, Fibonacci, LCS, Matrix DP
Practice via tabulation and memoization

Greedy Algorithms

Activity selection, Huffman Coding, Interval Scheduling

Graph Algorithms

BFS, DFS, Topological Sort
Dijkstra, Kruskal, Prim, Union-Find

Bit Manipulation

XOR Tricks, Set/Unset Bits, Power of 2

Sliding Window & Two Pointers

Max sum subarrays, Longest substring without repeating chars

Math & Number Theory

GCD/LCM, Sieve of Eratosthenes, Modular Exponentiation

Java-Specific Tips for DSA

Master Collections Framework (List, Map, Set, Queue)
Use Comparator & Comparable for custom sorting logic
Understand autoboxing, generics, and performance tradeoffs
Dive into Concurrency APIs: ExecutorService, ConcurrentHashMap

Learning Plan for Java DSA

Start with Collections API – understand how ArrayList, HashMap, TreeMap, etc. work under the hood.
Implement Data Structures Manually – Build your own LinkedList, Stack, etc.
Tackle Real Problems – Use LeetCode, GeeksForGeeks, or HackerRank.
Practice Patterns – Sliding window, recursion with memoization, etc.
Master Algorithms – Solve classic problems and understand trade-offs.

Top Resources

📘 Cracking the Coding Interview – Gayle Laakmann McDowell
📘 Effective Java – Joshua Bloch
💻 LeetCode's Top 100 Liked Problems
📚 GeeksForGeeks Java Data Structures Section

Whether you’re targeting top companies, building scalable software, or just enhancing your core dev skills—mastering DSA is your gateway. For Java developers, pairing algorithmic thinking with powerful tools like the Collections Framework will elevate your code from functional to exceptional.

What is LRU Cache?

Least Recently Used (LRU) is a caching strategy that evicts the least recently accessed item when the cache exceeds its capacity. It ensures that the most frequently or recently used data stays in memory while discarding older, less useful entries.

Real-World Use Case

Android image loading: Cache recently viewed images to avoid reloading from the network.
Database query results: Store recently used queries for faster results.
Web browsers: Maintain a small history of visited pages.
Memory-constrained systems: Manage resource usage by limiting active items in memory.

Best Way to Implement LRU in Java

The simplest and most effective way to implement an LRU Cache in Java is by using LinkedHashMap with access-order enabled.

LRU Cache Using `LinkedHashMap` (Best Practice)

import java.util.LinkedHashMap;
import java.util.Map;

public class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int capacity;

    public LRUCache(int capacity) {
        // initialCapacity, loadFactor, accessOrder
        super(capacity, 0.75f, true);
        this.capacity = capacity;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > capacity;
    }

    public static void main(String[] args) {
        LRUCache<Integer, String> cache = new LRUCache<>(3);

        cache.put(1, "One");
        cache.put(2, "Two");
        cache.put(3, "Three");

        // Access key 2 (makes 2 most recently used)
        cache.get(2);

        // Add key 4 - should evict key 1 (least recently used)
        cache.put(4, "Four");

        System.out.println(cache);
        // Output: {3=Three, 2=Two, 4=Four}
    }
}

Output

{3=Three, 2=Two, 4=Four}

Explanation:

Initially added 1, 2, 3.
Accessed key 2 → usage order becomes [1, 3, 2]
Adding key 4 → evicts 1 as it is the Least Recently Used.

Custom LRU Without LinkedHashMap (for interviews)

Here’s how you can manually implement an LRU Cache using a Doubly Linked List and HashMap in Java — this is the classic approach commonly asked in interviews because it guarantees O(1) time complexity for both get() and put() operations.

Key Concepts

HashMap gives O(1) lookup for keys.
Doubly Linked List maintains access order (most recent at the front, least at the end).
Each node contains key & value and links to its previous and next node.

import java.util.HashMap;

public class LRUCache<K, V> {
    private final int capacity;
    private final HashMap<K, Node> map;
    private final Node head, tail;

    private class Node {
        K key;
        V value;
        Node prev, next;

        Node(K key, V value) {
            this.key = key;
            this.value = value;
        }
    }

    public LRUCache(int capacity) {
        this.capacity = capacity;
        map = new HashMap<>();

        // Dummy head and tail nodes to avoid null checks
        head = new Node(null, null);
        tail = new Node(null, null);
        head.next = tail;
        tail.prev = head;
    }

    public V get(K key) {
        if (!map.containsKey(key)) return null;
        Node node = map.get(key);
        moveToHead(node); // Mark as most recently used
        return node.value;
    }

    public void put(K key, V value) {
        if (map.containsKey(key)) {
            Node node = map.get(key);
            node.value = value;
            moveToHead(node);
        } else {
            Node newNode = new Node(key, value);
            map.put(key, newNode);
            addToHead(newNode);

            if (map.size() > capacity) {
                Node lru = tail.prev;
                removeNode(lru);
                map.remove(lru.key);
            }
        }
    }

    // Helper methods for doubly linked list operations
    private void addToHead(Node node) {
        node.prev = head;
        node.next = head.next;

        head.next.prev = node;
        head.next = node;
    }

    private void removeNode(Node node) {
        node.prev.next = node.next;
        node.next.prev = node.prev;
    }

    private void moveToHead(Node node) {
        removeNode(node);
        addToHead(node);
    }

    public void printCache() {
        Node current = head.next;
        while (current != tail) {
            System.out.print(current.key + "=" + current.value + " ");
            current = current.next;
        }
        System.out.println();
    }

    public static void main(String[] args) {
        LRUCache<Integer, String> cache = new LRUCache<>(3);
        cache.put(1, "One");
        cache.put(2, "Two");
        cache.put(3, "Three");

        cache.printCache(); // 3=Three 2=Two 1=One

        cache.get(2); // Access 2 to move it to front
        cache.printCache(); // 2=Two 3=Three 1=One

        cache.put(4, "Four"); // Evicts 1 (least recently used)
        cache.printCache(); // 4=Four 2=Two 3=Three
    }
}

Output

3=Three 2=Two 1=One
2=Two 3=Three 1=One
4=Four 2=Two 3=Three

Benefits of This Approach

Feature	Description
Time Complexity	`O(1)` for both `get()` and `put()`
Space Complexity	`O(capacity)`
No built-in Java tricks	Great for coding interviews
Full control	Easy to customize or extend

Key Takeaways

Use LinkedHashMap with accessOrder = true for easy and efficient LRU.
Override removeEldestEntry() to control eviction.
Prefer it for in-memory caches in performance-sensitive apps.
For interviews, know the manual implementation using Doubly Linked List + HashMap.

📢 Feedback: Did you find this article helpful? Let me know your thoughts or suggestions for improvements! 😊 please leave a comment below. I’d love to hear from you! 👇

Happy coding! 💻✨

Longest Common Subsequence (LCS) in Java

Longest Common Subsequence (LCS) problem, including its problem statement, solution, and Java implementation using the best possible approach — Dynamic Programming (Tabulation - Bottom-Up) for optimal performance.

Problem Statement: Longest Common Subsequence (LCS)

Given two strings text1 and text2, return the length of their longest common subsequence.

A subsequence of a string is a new string generated from the original string with some characters (can be none) deleted without changing the relative order of the remaining characters.

Example:

Input: text1 = "abcde", text2 = "ace"
Output: 3
Explanation: The LCS is "ace" with length 3.

Optimal Solution: Dynamic Programming (Bottom-Up Tabulation)

💡 Idea:

We use a 2D DP array dp[i][j] where each cell represents the length of the LCS of the first i characters of text1 and the first j characters of text2.

Transition Formula:

If text1[i-1] == text2[j-1]
→ dp[i][j] = 1 + dp[i-1][j-1]
Else
→ dp[i][j] = max(dp[i-1][j], dp[i][j-1])

Java Code (Bottom-Up Approach)

public class LongestCommonSubsequence {

    public static int longestCommonSubsequence(String text1, String text2) {
        int m = text1.length();
        int n = text2.length();

        // Create a 2D dp array
        int[][] dp = new int[m + 1][n + 1];

        // Fill the dp array from bottom up
        for (int i = 1; i <= m; i++) {
            for (int j = 1; j <= n; j++) {
                // If characters match, move diagonally and add 1
                if (text1.charAt(i - 1) == text2.charAt(j - 1)) {
                    dp[i][j] = 1 + dp[i - 1][j - 1];
                } else {
                    // Else take max from left or top
                    dp[i][j] = Math.max(dp[i - 1][j], dp[i][j - 1]);
                }
            }
        }

        // The answer is in dp[m][n]
        return dp[m][n];
    }

    public static void main(String[] args) {
        String text1 = "abcde";
        String text2 = "ace";
        int result = longestCommonSubsequence(text1, text2);
        System.out.println("Length of LCS: " + result);  // Output: 3
    }
}

Time and Space Complexity

Complexity	Value
Time	`O(m * n)`
Space	`O(m * n)`

You can optimize space to O(min(m, n)) by using a 1D rolling array instead of a 2D array if needed.

Bonus: To Reconstruct the LCS String

If you want to reconstruct the LCS itself, not just its length, we can backtrack from dp[m][n] to dp[0][0] while tracing the matching characters.

📢 Feedback: Did you find this article helpful? Let me know your thoughts or suggestions for improvements! 😊 please leave a comment below. I’d love to hear from you! 👇

Happy coding! 💻✨

SOLID principle in Java

The SOLID principles are essential object-oriented programming (OOP) design principles that help create maintainable, flexible, scalable, and robust software systems.

Here's a clear explanation of each SOLID principle in Java, along with real-time examples and their significance in software projects:

1. Single Responsibility Principle (SRP)

Definition:
A class should have only one reason to change, meaning it should have only one responsibility.

Example:
Suppose you're designing an e-commerce system:

Bad Example:

class OrderProcessor {
    void processOrder(Order order) {
        // Process payment
        // Notify customer via email
        // Update inventory
    }
}

Good Example (SRP applied):

class PaymentProcessor {
    void processPayment(Order order) { }
}

class NotificationService {
    void notifyCustomer(Order order) { }
}

class InventoryService {
    void updateInventory(Order order) { }
}

class OrderProcessor {
    PaymentProcessor paymentProcessor;
    NotificationService notificationService;
    InventoryService inventoryService;

    void processOrder(Order order) {
        paymentProcessor.processPayment(order);
        notificationService.notifyCustomer(order);
        inventoryService.updateInventory(order);
    }
}

Importance:

Improves readability, easier to debug.
Changes to one responsibility don’t affect others.
Easier testing and less coupling between classes.

2. Open/Closed Principle (OCP)

Definition:
Software components (classes, modules, functions) should be open for extension but closed for modification.

Example:
Suppose you are handling different payment methods.

Bad Example:

class PaymentProcessor {
    void processPayment(String paymentType) {
        if(paymentType.equals("CreditCard")) {
            // process credit card payment
        } else if(paymentType.equals("PayPal")) {
            // process PayPal payment
        }
        // If a new payment type comes, this method must be modified.
    }
}

Good Example (OCP applied):

interface PaymentMethod {
    void processPayment();
}

class CreditCardPayment implements PaymentMethod {
    public void processPayment() { }
}

class PayPalPayment implements PaymentMethod {
    public void processPayment() { }
}

class BitcoinPayment implements PaymentMethod {
    public void processPayment() { }
}

class PaymentProcessor {
    void processPayment(PaymentMethod method) {
        method.processPayment();
    }
}

Importance:

Reduces risk when adding new functionality.
Ensures system stability.
Improves flexibility for adding future requirements.

3. Liskov Substitution Principle (LSP)

Definition:
Objects of a superclass should be replaceable by objects of subclasses without breaking the system’s correctness.

Example:
You have a hierarchy of birds:

Violation Example:

class Bird {
    void fly() { }
}

class Penguin extends Bird {
    void fly() {
        throw new UnsupportedOperationException("Penguin can't fly");
    }
}

Good Example (LSP applied):

class Bird { }

class FlyingBird extends Bird {
    void fly() { }
}

class Sparrow extends FlyingBird {
    void fly() { }
}

class Penguin extends Bird {
    void swim() { }
}

Importance:

Ensures polymorphism is correctly implemented.
Prevents unexpected behaviors and runtime errors.
Improves maintainability and readability.

4. Interface Segregation Principle (ISP)

Definition:
Clients should not be forced to depend upon interfaces they don’t use. Keep interfaces small, specific, and tailored to client needs.

Example:
Printer devices example.

Violation Example:

interface Printer {
    void print();
    void scan();
    void fax();
}

class OldPrinter implements Printer {
    public void print() { }
    public void scan() { throw new UnsupportedOperationException(); }
    public void fax() { throw new UnsupportedOperationException(); }
}

Good Example (ISP applied):

interface Printer {
    void print();
}

interface Scanner {
    void scan();
}

interface Fax {
    void fax();
}

class OldPrinter implements Printer {
    public void print() { }
}

class MultiFunctionPrinter implements Printer, Scanner, Fax {
    public void print() { }
    public void scan() { }
    public void fax() { }
}

Importance:

Avoids forcing irrelevant methods onto clients.
Reduces complexity and enhances clarity.
Promotes more modular and maintainable code.

5. Dependency Inversion Principle (DIP)

Definition:
High-level modules should not depend directly on low-level modules. Both should depend on abstractions (interfaces or abstract classes). Abstractions shouldn’t depend on details; details should depend on abstractions.

Example:
Consider database operations:

Violation Example:

class MySQLDatabase {
    void saveData(String data) { }
}

class UserService {
    private MySQLDatabase database = new MySQLDatabase();
    void saveUser(String data) {
        database.saveData(data);
    }
}

Good Example (DIP applied):

interface Database {
    void saveData(String data);
}

class MySQLDatabase implements Database {
    public void saveData(String data) { }
}

class MongoDB implements Database {
    public void saveData(String data) { }
}

class UserService {
    private Database database;

    UserService(Database database) {
        this.database = database;
    }

    void saveUser(String data) {
        database.saveData(data);
    }
}

Importance:

Decouples software modules, leading to highly maintainable code.
Easier to replace or upgrade components (database, network service, etc.).
Simplifies testing through mock implementations.

Why SOLID Principles Are Important in Software Projects

Maintainability: Easier to update, debug, and extend.
Readability: Clean and well-structured code improves readability.
Testability: Each class can be independently tested without excessive dependencies.
Flexibility and Extensibility: New features can be added without significant modifications.
Reduced Cost: Reduces complexity, lowering maintenance and future enhancements costs.
Scalability: Facilitates the development of larger and more complex systems, supporting agile methodologies.

Applying SOLID principles promotes creating software that's not only functional but also robust, efficient, and scalable.

Thanks for reading! 🎉 I'd love to know what you think about the article. Did it resonate with you? 💭 Any suggestions for improvement? I’m always open to hearing your feedback so that I can improve my posts! 👇🚀. Happy coding! 💻✨

Dependency Inversion Principle (DIP) in SOLID with Java Example

The Dependency Inversion Principle (DIP) is one of the SOLID principles of object-oriented design. It promotes loose coupling between high-level and low-level modules by introducing abstractions. Here's a simple explanation with an example in Java.

Definition

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Why Use DIP?

Without DIP:

High-level classes are tightly coupled to low-level classes.
Difficult to change or replace low-level implementations.
Harder to test (e.g., unit testing with mocks).

With DIP:

Use interfaces or abstract classes to depend on abstractions.
Concrete classes implement those interfaces.
High-level modules work with interfaces, not concrete implementations.

Java Example Without DIP (Bad)

class Keyboard {
    public void input() {
        System.out.println("Keyboard input");
    }
}

class Computer {
    private Keyboard keyboard;

    public Computer() {
        this.keyboard = new Keyboard(); // Tight coupling
    }

    public void use() {
        keyboard.input();
    }
}

Here, the Computer is tightly coupled to the Keyboard.

Java Example With DIP (Good)

// Abstraction
interface InputDevice {
    void input();
}

// Low-level module
class Keyboard implements InputDevice {
    public void input() {
        System.out.println("Keyboard input");
    }
}

// High-level module
class Computer {
    private InputDevice inputDevice;

    public Computer(InputDevice inputDevice) {
        this.inputDevice = inputDevice; // Dependency Injection
    }

    public void use() {
        inputDevice.input();
    }
}

Usage

public class Main {
    public static void main(String[] args) {
        InputDevice keyboard = new Keyboard();
        Computer computer = new Computer(keyboard);
        computer.use();
    }
}

Summary

Before DIP	After DIP
Tight coupling	Loose coupling
Hard to test	Easy to test
Direct dependency	Depend on abstraction
Difficult to extend	Easy to extend/replace

Interface Segregation Principle (ISP) in SOLID with Java Example

The Interface Segregation Principle (ISP) is one of the five SOLID principles of object-oriented design and development. In Java, the ISP promotes the idea that:

"No client should be forced to depend on methods it does not use."

This means interfaces should be specific and fine-grained rather than large and general. Clients should not be required to implement methods they don't need.

🔧 Why It Matters

If an interface has too many methods, implementing classes may end up with empty or meaningless method implementations, which leads to rigid, fragile, and hard-to-maintain code.

✅ Good Example – Following ISP

interface Printer {
    void print(String content);
}

interface Scanner {
    void scan(String document);
}

class CanonPrinter implements Printer {
    @Override
    public void print(String content) {
        System.out.println("Printing: " + content);
    }
}

class CanonScanner implements Scanner {
    @Override
    public void scan(String document) {
        System.out.println("Scanning: " + document);
    }
}

Here, a class only implements the interface it actually needs, promoting separation of concerns.

❌ Bad Example – Violating ISP

interface MultiFunctionDevice {
    void print(String content);
    void scan(String document);
    void fax(String document);
}

class OldPrinter implements MultiFunctionDevice {
    @Override
    public void print(String content) {
        System.out.println("Printing: " + content);
    }

    @Override
    public void scan(String document) {
        // Not supported
        throw new UnsupportedOperationException("Scan not supported");
    }

    @Override
    public void fax(String document) {
        // Not supported
        throw new UnsupportedOperationException("Fax not supported");
    }
}

Here, OldPrinter is forced to implement methods it doesn't support. This violates ISP.

✅ Solution with ISP using Interface Composition

interface Printer {
    void print(String content);
}

interface Scanner {
    void scan(String document);
}

interface Fax {
    void fax(String document);
}

class ModernPrinter implements Printer, Scanner, Fax {
    @Override
    public void print(String content) {
        System.out.println("Printing: " + content);
    }

    @Override
    public void scan(String document) {
        System.out.println("Scanning: " + document);
    }

    @Override
    public void fax(String document) {
        System.out.println("Faxing: " + document);
    }
}

Summary

ISP encourages creating smaller, specific interfaces.
Helps in building decoupled, modular, and easy-to-maintain code.
Supports flexibility and clean architecture.

Liskov Substitution Principle (LSP) in SOLID with Java Example

The Liskov Substitution Principle (LSP) is one of the five SOLID principles of object-oriented programming, formulated by Barbara Liskov. It states:

"Objects of a superclass should be replaceable with objects of its subclass without affecting the correctness of the program."

In simpler terms, if class B is a subclass of class A, then objects of class A should be replaceable with objects of class B without breaking the application.

Why is LSP Important?

LSP ensures that a derived class extends the behavior of a base class without altering its fundamental characteristics. Violating LSP can lead to unexpected behaviors, breaking polymorphism and making code more complex to maintain.

Example of LSP Violation

Incorrect Example (Violating LSP)

class Rectangle {
    protected int width;
    protected int height;

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getArea() {
        return width * height;
    }
}

class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        this.width = width;
        this.height = width; // Enforcing square behavior
    }

    @Override
    public void setHeight(int height) {
        this.width = height;
        this.height = height; // Enforcing square behavior
    }
}

public class LSPViolationExample {
    public static void main(String[] args) {
        Rectangle rect = new Square();  // Substituting subclass
        rect.setWidth(4);
        rect.setHeight(5);

        System.out.println("Expected Area: " + (4 * 5)); // Expecting 20
        System.out.println("Actual Area: " + rect.getArea()); // Output: 25 (Incorrect!)
    }
}

Why is LSP Violated Here?

The Square class breaks the behavior of Rectangle by forcing the width and height to be the same.
The program expects the area to be width * height = 4 * 5 = 20, but since Square modifies both dimensions, the actual area is 5 * 5 = 25, causing unexpected behavior.

Correct Example (Following LSP)

To fix this, we should avoid modifying inherited behaviors in a way that breaks expectations. A better approach is to use separate abstractions for Square and Rectangle.

abstract class Shape {
    public abstract int getArea();
}

class Rectangle extends Shape {
    protected int width;
    protected int height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public int getArea() {
        return width * height;
    }
}

class Square extends Shape {
    private int side;

    public Square(int side) {
        this.side = side;
    }

    @Override
    public int getArea() {
        return side * side;
    }
}

public class LSPExample {
    public static void main(String[] args) {
        Shape rect = new Rectangle(4, 5);
        Shape square = new Square(4);

        System.out.println("Rectangle Area: " + rect.getArea()); // 20
        System.out.println("Square Area: " + square.getArea()); // 16
    }
}

Why is This Correct?

The Shape abstract class defines a common contract (getArea()), but Rectangle and Square implement their own behaviors separately.
Rectangle and Square do not override each other’s behavior, ensuring LSP compliance.
Objects of Rectangle and Square can be used interchangeably without breaking expected behavior.

Key Takeaways

- Follow LSP by ensuring that subclasses do not break the expectations set by their base classes.
- Avoid overriding methods in a way that alters the base class's behavior incorrectly.
- Use separate abstractions when different behaviors are needed, instead of forcing a subclass to fit.
- Design classes such that a subclass can be substituted for its parent without causing unexpected behavior.

Open-Closed Principle (OCP) in SOLID with Java Example

The Open-Closed Principle (OCP) is one of the five SOLID principles of object-oriented design. It states that:

"Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification."

Explanation

Open for extension: You should be able to add new functionality without changing the existing code.
Closed for modification: You should not modify existing code when adding new features.

This principle helps write flexible, maintainable, and scalable code, reducing the risk of introducing bugs when modifying existing functionality.

Example of Violating the Open-Closed Principle

Here’s an example of a class that violates the Open-Closed Principle: We modify the DiscountCalculator class every time a new customer type is added.

Bad Example (Violating OCP)

class DiscountCalculator {
    public double calculateDiscount(String customerType, double amount) {
        if (customerType.equals("Regular")) {
            return amount * 0.1;  // 10% discount for regular customers
        } else if (customerType.equals("Premium")) {
            return amount * 0.2;  // 20% discount for premium customers
        }
        return 0;
    }
}

Problems:

If a new customer type (e.g., "VIP") needs to be added, we must modify this class.
The calculateDiscount method has to be edited every time a new customer type is introduced, violating OCP.
More modifications mean a higher chance of breaking existing functionality.

Applying the Open-Closed Principle

To follow the OCP, we use polymorphism and abstraction. Instead of modifying an existing class, we create new classes that extend the functionality.

Good Example (Following OCP)

// Step 1: Define an interface for discount strategy
interface DiscountStrategy {
    double applyDiscount(double amount);
}

// Step 2: Implement different discount strategies
class RegularCustomerDiscount implements DiscountStrategy {
    @Override
    public double applyDiscount(double amount) {
        return amount * 0.1;  // 10% discount
    }
}

class PremiumCustomerDiscount implements DiscountStrategy {
    @Override
    public double applyDiscount(double amount) {
        return amount * 0.2;  // 20% discount
    }
}

// Step 3: Use the strategy without modifying the existing class
class DiscountCalculator {
    public double calculateDiscount(DiscountStrategy strategy, double amount) {
        return strategy.applyDiscount(amount);
    }
}

// Step 4: Usage
public class Main {
    public static void main(String[] args) {
        DiscountCalculator calculator = new DiscountCalculator();

        DiscountStrategy regularDiscount = new RegularCustomerDiscount();
        DiscountStrategy premiumDiscount = new PremiumCustomerDiscount();

        double regularAmount = calculator.calculateDiscount(regularDiscount, 1000);
        double premiumAmount = calculator.calculateDiscount(premiumDiscount, 1000);

        System.out.println("Regular Customer Discount: " + regularAmount);
        System.out.println("Premium Customer Discount: " + premiumAmount);
    }
}

Advantages of Following OCP:

- No modifications to existing classes when adding a new discount type.
- Extensible design - You can add a new customer type (e.g., VIPCustomerDiscount) by creating a new class implementing DiscountStrategy.
- Better maintainability and readability.
- Follows the Single Responsibility Principle (SRP) by separating concerns.

Extending the System

Now, if a new type of discount needs to be added, you just create a new class:

class VIPCustomerDiscount implements DiscountStrategy {
    @Override
    public double applyDiscount(double amount) {
        return amount * 0.3;  // 30% discount for VIP customers
    }
}

No need to modify the DiscountCalculator class! 🎉

This is how the Open-Closed Principle helps write extensible and maintainable code in Java. 🚀

Single Responsibility Principle (SRP) in SOLID with Java Example

Writing clean, maintainable, and scalable code is crucial in software development. One key principle that helps achieve this is the Single Responsibility Principle (SRP), one of the five SOLID principles of object-oriented design.

What is the Single Responsibility Principle?

The Single Responsibility Principle states that:

"A class should have only one reason to change."

This means that each class should have only one responsibility and one focus. If a class handles multiple responsibilities, it becomes more complex, more challenging to test, and more difficult to maintain.

Following SRP, we can keep our code modular, making it easier to understand, test, and extend.

Example: Violating the Single Responsibility Principle

Let’s consider an example where a class violates the Single Responsibility Principle:

class Employee {
    private String name;
    private double salary;

    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public String getName() {
        return name;
    }

    public double getSalary() {
        return salary;
    }

    // Responsibility 1: Calculating employee's salary
    public double calculateBonus() {
        return salary * 0.10; // 10% bonus
    }

    // Responsibility 2: Saving employee details to a file
    public void saveToFile() {
        System.out.println("Saving employee data to a file...");
    }
}

What is wrong with this code?

The Employee class has two responsibilities:

Business logic (Calculating salary and bonus)
Persistence logic (Saving data to a file)

If we need to change how the salary is calculated, we modify the same class that handles file storage. This violates SRP and makes the class harder to maintain.

Applying the Single Responsibility Principle

To follow SRP, we should separate the concerns. We can create two separate classes:

Employee – Only contains employee-related data
SalaryCalculator – Handles salary calculations
EmployeePersistence – Handles saving employee data

Here’s the refactored code:

// Employee class now has only one responsibility: storing employee details
class Employee {
    private String name;
    private double salary;

    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public String getName() {
        return name;
    }

    public double getSalary() {
        return salary;
    }
}

// SalaryCalculator is responsible for salary-related operations
class SalaryCalculator {
    public double calculateBonus(Employee employee) {
        return employee.getSalary() * 0.10; // 10% bonus
    }
}

// EmployeePersistence is responsible for saving employee data
class EmployeePersistence {
    public void saveToFile(Employee employee) {
        System.out.println("Saving employee " + employee.getName() + " data to a file...");
    }
}

Benefits of Applying the Single Responsibility Principle

Improved Maintainability
- Changes to salary calculations do not affect file storage logic.
Better Readability and Modularity
- Code is easier to understand and modify.
Easier Unit Testing
- We can test salary calculations separately from persistence operations.
Scalability
- If we need to store employee data in a database instead of a file, we only modify EmployeePersistence, leaving other classes unchanged.

Summary

The Single Responsibility Principle (SRP) helps keep our Java applications modular, clean, and easy to maintain. By ensuring that each class has only one reason to change, we can write better, more scalable, and testable software.

Applying SRP reduces complexity, improves reusability, and enhances collaboration in software projects. Always keep in mind:

"A class should do one thing and do it well."

Would you like me to add more real-world examples or expand on any section? 🚀

Understanding Functional Interfaces in Java 8 and Their Relationship with Lambda Expressions

Java 8 introduced several new features that revolutionized the way Java developers write code. One of the key concepts introduced in this version is functional interfaces. Along with lambda expressions, functional interfaces form the core of Java’s functional programming capabilities. This article will explore what functional interfaces are, how they work, and how they relate to lambda expressions with a practical example.

What is a Functional Interface?

A functional interface in Java is an interface that contains exactly one abstract method. This single abstract method is the essence of the interface, and it defines the contract for what the interface should do. Functional interfaces may contain multiple default methods and static methods, but they must have only one abstract method.

Functional interfaces are fundamental for functional programming in Java because they serve as the target types for lambda expressions and method references.

Key Features of Functional Interfaces:

One abstract method: A functional interface's core characteristic is that it defines only one abstract method.
Can contain multiple default and static methods: Though the interface can have more than one method, only one should be abstract.
Used with lambda expressions: Functional interfaces are the primary interface types for lambda expressions in Java.

Built-in Functional Interfaces in Java

Java provides several pre-defined functional interfaces in the java.util.function package, such as:

Predicate<T>: Represents a boolean-valued function of one argument.
Function<T, R>: Represents a function that takes one argument and returns a result.
Consumer<T>: Represents an operation that takes a single argument and returns no result.
Supplier<T>: Represents a supplier of results, providing values of a specific type.

These interfaces are designed to handle various functional programming use cases in Java.

How Do Functional Interfaces Relate to Lambda Expressions?

Lambda expressions allow you to pass behavior (code) as parameters or return them as results, enabling more concise and flexible code. Lambda expressions are beneficial when you need to implement the method of a functional interface.

A lambda expression implements the abstract method defined in the functional interface. It is passed as an argument to methods expecting a functional interface or returned as a result.

Syntax of Lambda Expressions

The syntax for lambda expressions is as follows:

(parameters) -> expression

Parameters: The input to the lambda expression.
Expression: The implementation of the method that corresponds to the abstract method of the functional interface.

Example of a Functional Interface and Lambda Expression

Let’s implement a simple functional interface and use a lambda expression.

Step 1: Define the Functional Interface

@FunctionalInterface
interface MathOperation {
    int operate(int a, int b); // Single abstract method
}

MathOperation is a functional interface because it has exactly one abstract method, operate, which accepts two integers and returns an integer.

Step 2: Use Lambda Expression to Implement the Interface

Now, let’s use a lambda expression to provide an implementation for the operate method.

public class FunctionalInterfaceExample {

    public static void main(String[] args) {
        // Lambda expression for addition
        MathOperation add = (a, b) -> a + b;
        System.out.println("Addition: " + add.operate(5, 3));  // Output: 8
        
        // Lambda expression for multiplication
        MathOperation multiply = (a, b) -> a * b;
        System.out.println("Multiplication: " + multiply.operate(5, 3));  // Output: 15
    }
}

Here, we define two lambda expressions:

add: Adds two integers.
multiply: Multiplies two integers.

The lambda expressions provide the body of the operate method of the MathOperation interface. Each lambda expression represents an implementation of the interface’s abstract method.

Advantages of Using Lambda Expressions with Functional Interfaces

Concise and Readable Code: Lambda expressions significantly reduce the verbosity of anonymous inner class implementations, making the code more concise and easier to understand.
Enhanced Flexibility: Lambda expressions can be passed as arguments to methods, allowing for greater flexibility in how code is written and executed.
Functional Programming Paradigm: They enable a functional programming style in Java, promoting immutability and declarative style programming, which can lead to cleaner and more maintainable code.

Custom Functional Interface with Multiple Methods

While a functional interface must have only one abstract method, it can have multiple default methods or static methods. Default methods allow you to add new interface methods without breaking existing implementations.

@FunctionalInterface
interface Calculator {
    int calculate(int a, int b); // Abstract method
    
    // Default method
    default int add(int a, int b) {
        return a + b;
    }

    // Static method
    static int multiply(int a, int b) {
        return a * b;
    }
}

Although Calculator defines both a default method (add) and a static method (multiply), it is still a functional interface because it only has one abstract method: calculate.

Summary

Functional interfaces in Java 8 are a crucial component of the new functional programming paradigm introduced to the language. They allow you to define a contract with a single abstract method, which can then be implemented using lambda expressions. This makes Java more expressive and concise, especially when dealing with behavior such as parameters or return values.

By understanding the relationship between functional interfaces and lambda expressions, developers can harness the power of functional programming in Java, leading to more readable and maintainable code. Whether working with Java's built-in functional interfaces or creating your own, this concept opens up new possibilities for writing efficient, functional-style Java code.

TestNG: A Powerful Testing Framework for Java

TestNG (Test Next Generation) is a popular Java testing framework inspired by JUnit and NUnit. It introduces additional functionalities, such as parallel execution, dependency testing, and data-driven testing. It is widely used for enterprise applications' unit, integration, and automation testing.

This article will explore TestNG's key features, explain how it works, and provide an example to demonstrate its capabilities.

Why Use TestNG?

TestNG offers several advantages over traditional testing frameworks like JUnit:

Annotations: Provides powerful annotations that simplify test case writing.
Test Suite Execution: Allows grouping and running multiple test cases as a suite.
Dependency Testing: Supports defining dependencies between test methods.
Data-Driven Testing: Enables parameterized tests using data providers.
Parallel Execution: Supports running tests concurrently for better performance.
Flexible Configuration: XML-based configuration makes it easy to organize test execution.
Report Generation: Provides detailed reports on test execution.

How TestNG Works

TestNG relies on annotations to define test methods and configurations. It follows a lifecycle where different annotations manage the execution flow of tests. Here are some commonly used annotations in TestNG:

Key Annotations in TestNG

Annotation	Description
`@Test`	Marks a method as a test case.
`@BeforeSuite`	Runs before all test methods in the suite.
`@AfterSuite`	Runs after all test methods in the suite.
`@BeforeClass`	Runs before the first test method in the current class.
`@AfterClass`	Runs after the last test method in the current class.
`@BeforeMethod`	Runs before each test method.
`@AfterMethod`	Runs after each test method.
`@DataProvider`	Supplies data to test methods for data-driven testing.

Setting Up TestNG in a Java Project

To use TestNG in a Java project, follow these steps:

Step 1: Add TestNG Dependency

If you are using Maven, add the following dependency to your pom.xml file:

<dependencies>
    <dependency>
        <groupId>org.testng</groupId>
        <artifactId>testng</artifactId>
        <version>7.8.0</version>
        <scope>test</scope>
    </dependency>
</dependencies>

If you are using a standalone JAR file, download TestNG from TestNG’s official website and add it to your project’s classpath.

Step 2: Write a Sample TestNG Test

Here is a basic example demonstrating TestNG in action:

import org.testng.Assert;
import org.testng.annotations.*;

public class TestNGExample {

    @BeforeClass
    public void setup() {
        System.out.println("Setup before class execution");
    }

    @Test(priority = 1)
    public void testAddition() {
        int result = 5 + 3;
        Assert.assertEquals(result, 8, "Addition test failed!");
    }

    @Test(priority = 2, dependsOnMethods = {"testAddition"})
    public void testSubtraction() {
        int result = 10 - 3;
        Assert.assertEquals(result, 7, "Subtraction test failed!");
    }

    @Test(dataProvider = "numbersData")
    public void testMultiplication(int a, int b, int expected) {
        int result = a * b;
        Assert.assertEquals(result, expected, "Multiplication test failed!");
    }

    @DataProvider(name = "numbersData")
    public Object[][] getNumbers() {
        return new Object[][] {
            {2, 3, 6},
            {4, 5, 20},
            {6, 7, 42}
        };
    }

    @AfterClass
    public void teardown() {
        System.out.println("Teardown after class execution");
    }
}

Step 3: Running the Test

You can run TestNG tests in multiple ways:

Using IDE (Eclipse/IntelliJ IDEA): Right-click on the test class and select Run As > TestNG Test.
Using testng.xml: Create an XML configuration file to define test execution.
Using Maven: Run mvn test if TestNG is configured in pom.xml.

Sample `testng.xml`

<suite name="Example Test Suite">
    <test name="Basic Test">
        <classes>
            <class name="TestNGExample"/>
        </classes>
    </test>
</suite>

Run it using the command:

mvn test -Dsurefire.suiteXmlFiles=testng.xml

TestNG Reports

After execution, TestNG generates detailed reports in the test-output directory. These reports include pass/fail statuses, execution time, and failure reasons, which help in debugging.

Summary

TestNG is a versatile and powerful testing framework that simplifies Java application testing with its rich features like annotations, parallel execution, dependency management, and detailed reporting. Whether for unit testing or automation, TestNG offers the flexibility needed for efficient test execution.

By integrating TestNG into your workflow, you can ensure better test coverage, maintainability, and faster feedback loops in your software development lifecycle.

Subscribe To

Why Java Developers Must Learn DSA

Core Data Structures in Java

1. Linear Data Structures

2. Hash-Based Structures

3. Tree-Based Structures

4. Heap (Priority Queue)

5. Graph

6. Advanced

Algorithms to Focus On

Searching & Sorting

Recursion & Backtracking

Dynamic Programming

Greedy Algorithms

Graph Algorithms

Bit Manipulation

Sliding Window & Two Pointers

Math & Number Theory

Java-Specific Tips for DSA

Learning Plan for Java DSA

Top Resources

What is LRU Cache?

Real-World Use Case

Best Way to Implement LRU in Java

LRU Cache Using LinkedHashMap (Best Practice)

Output

Custom LRU Without LinkedHashMap (for interviews)

Key Concepts

Output

Benefits of This Approach

Key Takeaways

Problem Statement: Longest Common Subsequence (LCS)

Optimal Solution: Dynamic Programming (Bottom-Up Tabulation)

💡 Idea:

Transition Formula:

Java Code (Bottom-Up Approach)

Time and Space Complexity

Bonus: To Reconstruct the LCS String

1. Single Responsibility Principle (SRP)

2. Open/Closed Principle (OCP)

3. Liskov Substitution Principle (LSP)

4. Interface Segregation Principle (ISP)

5. Dependency Inversion Principle (DIP)

Why SOLID Principles Are Important in Software Projects

Definition

Why Use DIP?

With DIP:

Java Example Without DIP (Bad)

Java Example With DIP (Good)

Usage

Summary

🔧 Why It Matters

✅ Good Example – Following ISP

❌ Bad Example – Violating ISP

✅ Solution with ISP using Interface Composition

Summary

Why is LSP Important?

Example of LSP Violation

Incorrect Example (Violating LSP)

Why is LSP Violated Here?

Correct Example (Following LSP)

Why is This Correct?

Key Takeaways

Explanation

Example of Violating the Open-Closed Principle

Bad Example (Violating OCP)

Problems:

Applying the Open-Closed Principle

Good Example (Following OCP)

Advantages of Following OCP:

Extending the System

What is the Single Responsibility Principle?

Example: Violating the Single Responsibility Principle

What is wrong with this code?

Applying the Single Responsibility Principle

Benefits of Applying the Single Responsibility Principle

Summary

What is a Functional Interface?

Key Features of Functional Interfaces:

Built-in Functional Interfaces in Java

LRU Cache Using `LinkedHashMap` (Best Practice)

Sample `testng.xml`