DEV Community: Ashutosh Krishna

The Ultimate Guide to the Java Singleton Pattern

Ashutosh Krishna — Sun, 12 Jul 2026 09:28:23 +0000

Imagine a country. A country can have millions of citizens, thousands of politicians, and hundreds of cities, but it only ever has one President at a time. Whenever a citizen, a foreign diplomat, or a journalist wants to address the head of state, they all route their communication to that exact same person.

In software engineering, there are certain objects in our systems that must operate exactly like this President. We need exactly one instance of them, and we need a global point of access to reach them.

This is the Singleton Design Pattern.

Singleton is one of the “Gang of Four” (GoF) creational design patterns. It is arguably the most famous design pattern in existence and simultaneously one of the most controversial. Whether you are building a configuration manager, a printer spooler, or a centralised logger, Singleton ensures that all parts of your application share the same state and resources.

Interview Tip: Interviewers love asking about Singletons because it is a “gateway pattern”. A simple question about Singleton quickly opens the door to complex discussions about multi-threading, the Java Memory Model, class loaders, and reflection.

What is a Singleton Class?
- Key Characteristics
- Benefits
- Drawbacks
Why Do We Need Singleton?
Core Principles Behind Singleton
Basic Singleton Implementation: Eager Initialization
- The Problem
Lazy Initialization: Saving Memory
- The Problem
Synchronized Method: The Traffic Jam
- The Problem
Double-Checked Locking
Understanding the volatile Keyword
The Bill Pugh Singleton: A JVM Masterclass
The Reflection Problem
The Serialization Problem
The Cloning Problem
The Enum Singleton: The Indestructible Solution
Singleton and Class Loaders: An Enterprise Reality
Comparing All Singleton Implementations
Singleton vs Static Utility Class
Singleton in the Spring Framework
Singleton in Modern Cloud Applications
When NOT to Use Singleton (The Anti-Pattern Debate)
Common Mistakes Developers Make
Best Practices for Modern Development
Common Interview Questions and Answers
Conclusion

What is a Singleton Class?

By formal definition, the Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance.

Key Characteristics

One Instance: The JVM will only ever contain one object of this class per classloader.
Self-Managed: The class itself is responsible for keeping track of its sole instance.
Global Access: The class provides a public static method to allow clients to retrieve the instance.

Benefits

Prevents other objects from instantiating their own copies.
Conserves memory by sharing a single object.
Centralises the state and management of a shared resource.

Drawbacks

Introduces global state into an application.
Tightly couples code, making unit testing difficult.
Can cause hidden bottlenecks in heavily multi-threaded environments.

Why Do We Need Singleton?

Why not just create new objects every time we need them using the new keyword?

Creating objects in Java has a cost: memory allocation, CPU cycles, and Garbage Collection overhead. But more importantly, some objects represent resources that are strictly singular by nature.

Practical use cases include:

Logger: If every class creates its own logger object, writing to a single log file concurrently can result in overwrites and corrupted data. A Singleton logger coordinates all file writes.
Configuration Manager: You want to read an application.properties file once, parse it into memory, and share it across the app. You don't want to hit the disk every time a component needs a configuration value.
Connection Pool Manager: Database connections are expensive. A Singleton pool manager creates a fixed number of connections and hands them out to threads, ensuring the database isn't overwhelmed.
Cache Manager: An in-memory cache must be shared. If every service instantiates its own cache, they won't see each other's cached data!

Core Principles Behind Singleton

To build a Singleton, we must actively prevent developers from using the new keyword. To do this, we rely on three core principles:

Private Constructor: If a constructor is private, no other class can call it. This absolutely prevents external instantiation.
Static Instance Variable: We store the single created instance in a private static field. Making it static ties the variable to the class itself rather than to any specific object instance.
Public Access Method: We expose a public static method (usually named getInstance()). This method acts as the gatekeeper. When called, it checks if the instance exists. If it does, it returns it. If it doesn't, it creates it, stores it, and then returns it.

Basic Singleton Implementation: Eager Initialization

We now understand the theory, but how do we actually implement it? Let's start with the most straightforward approach: asking the Java Virtual Machine (JVM) to create the object the moment our application starts. This is known as Eager Initialization.

public class EagerSingleton {

    // Instance is created when the class is loaded by the JVM.
    // This guarantees that only one instance exists.
    private static final EagerSingleton instance = new EagerSingleton();

    // Private constructor prevents external instantiation.
    private EagerSingleton() {
        System.out.println("Eager Singleton initialized.");
    }

    // Global access point to the single instance.
    public static EagerSingleton getInstance() {
        return instance;
    }
}

When you write an Eager Singleton, the object is brought to life the exact moment the Java ClassLoader loads the class into memory, long before any user interacts with your application. Because the JVM internally guarantees that class loading is thread-safe, we do not have to worry about concurrency issues. The final keyword adds an extra layer of security, ensuring that once the instance is assigned, it can never be accidentally overwritten.

When a developer eventually calls getInstance(), the method simply acts as a courier, instantly returning the pre-created object.

The Problem

While eager initialization is elegantly simple and perfectly thread-safe, it introduces a glaring problem: Memory Leak Potential. Imagine this Singleton is a complex cache manager that pre-loads large data structures, or a connection pool holding open network sockets. With Eager Initialization, the JVM allocates these heavy resources immediately on startup, even if the user never accesses the feature that requires them. We are holding precious memory hostage.

To solve this problem, we need to delay the creation of the object until the precise moment it is requested.

Lazy Initialization: Saving Memory

If Eager Initialization wastes memory, the logical evolution is Lazy Initialization. Here, we defer the object creation until a developer actively calls our access method for the very first time.

public class LazySingleton {

    // Instance is not created until it is first requested.
    private static LazySingleton instance;

    // Private constructor prevents external instantiation.
    private LazySingleton() {
        System.out.println("Lazy Singleton initialized.");
    }

    // Creates the instance only when it is needed for the first time.
    public static LazySingleton getInstance() {

        // If no instance exists, create one.
        if (instance == null) {
            instance = new LazySingleton();
        }

        // Return the existing instance.
        return instance;
    }
}

In this implementation, we drop the final keyword and stop assigning the variable at the top. The intelligence of this pattern lives entirely within the getInstance() method.

When an application component requests the Singleton for the first time, our method evaluates the null check. Since the application just started, the instance variable is indeed null. The code gracefully steps inside the conditional block, invokes the private constructor to allocate the necessary memory, and assigns the newly minted object to our static variable. Finally, it returns the instance to the caller.

The beauty of this approach shines during the second request. When another component calls the method, the null check evaluates to false. The application completely skips the creation logic and instantly hands back the exact same object. We have successfully solved our memory problem. The object only exists if it is actually used.

However, we have unknowingly walked right into a catastrophic architectural bug. While this basic implementation works flawlessly in a simple, single-threaded script, modern Java applications operate in highly concurrent environments.

The Problem

To understand why our Lazy Singleton fails in the real world, we must take a brief detour into concurrency.

A thread is an independent path of execution within your application. Concurrency occurs when multiple threads execute tasks simultaneously, driven by a multi-core CPU. A race condition is a software bug that happens when the outcome of a program depends on the unpredictable timing of how the CPU schedules these threads.

Let's visualize a scenario where Thread A and Thread B try to access our LazySingleton at the exact same millisecond.

Time	Thread A	Thread B
1	calls `getInstance()`	calls `getInstance()`
2	evaluates: `if (instance == null)`
3	(Result: TRUE)	evaluates: `if (instance == null)`
4	-- CPU Context Switch --	(Result: TRUE)
5		enters if block
6	enters if block	`instance = new LazySingleton()`
7	`instance = new LazySingleton()`
8	returns Instance #1	returns Instance #2

Because CPU context switching is unpredictable, Thread A evaluated the condition as true but was paused before it could actually create the object. Thread B then ran, also saw a null instance, and proceeded to create the object. When Thread A woke back up, it blindly continued into the if block and created a second instance.

Our Singleton pattern has been utterly shattered. We now have two separate objects floating in memory, violating the primary rule of the pattern. We need a way to control the traffic.

Synchronized Method: The Traffic Jam

The most intuitive way to prevent threads from colliding in Java is to force them to form an orderly line. We do this by applying the synchronized keyword to our method.

public class SyncMethodSingleton {

    // Instance is created only when it is first requested.
    private static SyncMethodSingleton instance;

    // Private constructor prevents external instantiation.
    private SyncMethodSingleton() {}

    // Synchronized method ensures that only one thread can execute the instance creation logic at a time.
    public static synchronized SyncMethodSingleton getInstance() {

        // Create the instance if it does not already exist.
        if (instance == null) {
            instance = new SyncMethodSingleton();
        }

        // Return the single shared instance.
        return instance;
    }
}

By adding synchronized to the method signature, we turn getInstance() into a locked room. Only one thread can possess the key to this room at any given time. If Thread A is inside evaluating the null check, Thread B is physically blocked from entering the method and must wait patiently outside. By the time Thread B is allowed in, Thread A has finished creating the instance. Thread B will correctly see that the instance is no longer null and will simply return it.

Our Singleton is finally thread-safe. But we have traded a correctness problem for a massive performance bottleneck.

The Problem

Think about the lifecycle of this Singleton. We only truly need synchronization for the very first thread, the one that actually executes the constructor. Once the object exists, every subsequent read operation is perfectly safe to happen concurrently. Yet, because we synchronized the entire method, every single time any part of our app wants to read from this Singleton, threads are forced to wait in line. In a high-traffic enterprise application, this single lock can choke your entire system's throughput.

Double-Checked Locking

We need a scalpel, not a sledgehammer. What if we only synchronize the exact block of code that creates the object, and only apply that lock if the object hasn't been created yet? This brings us to a highly performant idiom known as Double-Checked Locking (DCL).

public class DoubleCheckedSingleton {

    // Volatile ensures that changes made by one thread
    // are immediately visible to other threads.
    private static volatile DoubleCheckedSingleton instance;

    // Private constructor prevents external instantiation.
    private DoubleCheckedSingleton() {}

    public static DoubleCheckedSingleton getInstance() {

        // First check avoids synchronization after the instance has already been created.
        if (instance == null) {

            // Only one thread can enter this block at a time.
            synchronized (DoubleCheckedSingleton.class) {

                // Second check ensures another thread has not already created the instance while waiting.
                if (instance == null) {
                    instance = new DoubleCheckedSingleton();
                }
            }
        }

        // Return the single shared instance.
        return instance;
    }
}

The execution flow here is brilliant. When threads call getInstance(), they immediately hit the first if check. This check is completely lock-free. If the instance already exists, threads grab the object and go, operating at maximum speed without ever encountering a lock.

If the instance is null, threads proceed to the synchronized block. Suppose Thread A wins the lock while Thread B waits. Thread A enters the block and performs a second null check. Why? Because while Thread A was waiting to acquire the lock, another thread might have sneaked in and created the instance! The second check ensures we don't accidentally overwrite an instance that was just established. Thread A creates the object, assigns it, and releases the lock. When Thread B finally gets the lock, it hits the second check, sees the newly created object, and safely skips the creation logic.

Pro Tip: Historically, prior to Java 5, Double-Checked Locking was considered a broken anti-pattern. The Java Memory Model was not strict enough, allowing the JVM to wildly reorder instructions in ways that caused crashes. Today, thanks to the keyword we are about to discuss, DCL is a highly respected, production-ready solution.

Understanding the `volatile` Keyword

You likely noticed the word volatile attached to the instance variable in our Double-Checked Locking example. If you forget this single word during an interview or in production code, your Singleton is fundamentally broken. To understand why, we must explore the physical architecture of modern hardware.

Modern multi-core CPUs are incredibly fast, much faster than the main system RAM. To bridge this speed gap, CPUs utilize ultra-fast local caches (L1, L2, L3) for each core. When a thread modifies a variable, it often writes that change to its local CPU cache to save time, rather than updating the main memory immediately.

This creates a severe Visibility Problem. If Thread A, running on Core 1, initializes the Singleton and saves it to its local cache, Thread B, running on Core 2, might look at the main memory, see that the variable is still null, and proceed to create a duplicate instance!

Furthermore, to optimize performance, the Java Compiler and the CPU are allowed to perform Instruction Reordering. The simple line instance = new DoubleCheckedSingleton(); is actually three separate JVM instructions:

Allocate blank memory for the object.
Initialize the object (run the constructor).
Assign the memory reference to the instance variable.

The JVM is fully allowed to reorder these steps to 1 -> 3 -> 2. If it does, Thread A allocates memory and assigns the reference (Step 3). At this exact microsecond, the instance variable is no longer null, but the object is completely empty because the constructor hasn't run yet. Thread B comes along, hits the lock-free first check, sees a non-null instance, and tries to invoke a method on a half-baked object, triggering a catastrophic application crash.

The volatile keyword acts as an iron-clad disciplinarian. First, it solves the visibility problem by forcing all reads and writes of the variable to bypass the CPU cache and go straight to Main Memory. Second, it establishes a strict happens-before relationship, entirely forbidding the JVM from reordering the initialization instructions. The object must be fully constructed before the reference is published to the rest of the application.

The Bill Pugh Singleton: A JVM Masterclass

Double-Checked Locking is incredibly performant, but as we just saw, it requires a deep, uncomfortable understanding of memory visibility, instruction reordering, and the volatile keyword. It is verbose and notoriously easy to implement incorrectly.

William Pugh, a renowned computer scientist, proposed a much more elegant solution. He realized we could trick the JVM's internal class-loading mechanics into handling the synchronization for us, allowing us to achieve perfect lazy loading without using synchronized blocks or volatile variables.

public class BillPughSingleton {

    private BillPughSingleton() {}

    private static class SingletonHelper {
        private static final BillPughSingleton INSTANCE = new BillPughSingleton();
    }

    public static BillPughSingleton getInstance() {
        return SingletonHelper.INSTANCE;
    }
}

This approach utilizes a static inner helper class, and its brilliance lies in the JVM's lazy class-loading rules. When the application starts and the BillPughSingleton class is loaded into memory, the JVM explicitly ignores the inner SingletonHelper class. It does not load it, and therefore does not instantiate the Singleton object. We have achieved perfect lazy loading; zero memory is wasted.

The magic occurs only when a developer calls getInstance(). This method attempts to access SingletonHelper.INSTANCE. The moment that explicit reference is made, the JVM is forced to load the inner class and initialize its static fields.

Because the Java language specification strictly guarantees that the initialization of a class is thread-safe, the JVM natively locks the process behind the scenes. Multiple threads can call the method simultaneously, but the JVM will perfectly orchestrate the creation of a single object, returning it to all threads with blazing speed. For years, the Bill Pugh approach has been considered the gold standard of Java Singletons.

The Reflection Problem

Our Bill Pugh Singleton is lazy, fast, and thread-safe. But in the hands of a curious or malicious developer, it can easily be destroyed. Java provides a powerful API called Reflection, which allows developers to inspect and manipulate code at runtime, completely ignoring access modifiers.

public class ReflectionBreaker {
    public static void main(String[] args) {
        BillPughSingleton instanceOne = BillPughSingleton.getInstance();
        BillPughSingleton instanceTwo = null;

        try {
            Constructor[] constructors = BillPughSingleton.class.getDeclaredConstructors();
            for (Constructor constructor : constructors) {
                // We bypass the private constructor!
                constructor.setAccessible(true);
                instanceTwo = (BillPughSingleton) constructor.newInstance();
                break;
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

        System.out.println(instanceOne == instanceTwo); // Prints: false
    }
}

By retrieving the private constructor and explicitly calling setAccessible(true), Reflection allows us to forcibly instantiate a second object, entirely breaking the Singleton contract.

To defend against this, we must add aggressive boilerplate logic inside our constructor. We must check if an instance already exists, and if it does, forcefully throw a RuntimeException to crash the rogue process before it can instantiate the duplicate.

The Serialization Problem

In distributed applications, you often need to convert an object into a byte stream (Serialization) to send it over a network or save it to a database, and later reconstruct it (Deserialization).

If your Singleton class implements the Serializable interface, you are in for a nasty surprise. During the deserialization process, the JVM reads the byte stream and automatically creates a brand-new instance of your Singleton, completely bypassing your private constructor.

To patch this vulnerability, you must provide a special, deeply hidden JVM hook method called readResolve().

protected Object readResolve() {
    return getInstance();
}

When the JVM deserializes an object, it searches for the readResolve() method. If it finds it, the JVM immediately discards the freshly created duplicate object and instead returns whatever readResolve() dictates, in our case, the true Singleton instance.

The Cloning Problem

Similarly, if your Singleton accidentally implements the Cloneable interface (perhaps inherited from a parent class), a developer could invoke the .clone() method to create a shallow copy of your precious instance.

To prevent this, you must explicitly override the clone method and throw an exception to block the operation.

@Override
protected Object clone() throws CloneNotSupportedException {
    throw new CloneNotSupportedException("Cloning of a Singleton is strictly prohibited.");
}

The Enum Singleton: The Indestructible Solution

Protecting a Singleton from Reflection, Serialization, and Cloning requires writing a lot of defensive, ugly boilerplate code. Joshua Bloch, the legendary author of Effective Java, looked at this mess and proposed a radically simple alternative: just use a Java Enum.

public enum EnumSingleton {
    INSTANCE;

    public void doSomething() {
        System.out.println("Enum Singleton is working flawlessly.");
    }
}

That is the entire code. You access it anywhere in your application by calling EnumSingleton.INSTANCE.doSomething().

Why is this considered the ultimate Singleton? Because the Java language specification treats enums like royalty. The JVM inherently guarantees that an enum value is instantiated exactly once in a given Java program. It naturally provides flawless thread-safety.

If a hacker tries to use Reflection to duplicate an enum, the internal java.lang.reflect.Constructor class explicitly detects it and throws an IllegalArgumentException. Furthermore, Java's serialization mechanism is custom-built to ensure enum values are never duplicated during deserialization, so no readResolve() hack required. While it does not support lazy loading, the Enum Singleton is the absolute safest, most robust way to implement the pattern in core Java.

Singleton and Class Loaders: An Enterprise Reality

There is a frequently overlooked enterprise concept that catches even senior engineers off guard. The standard rule of the GoF Singleton pattern states: "There is only one instance per JVM." This is technically false in Java.

The accurate statement is: There is only one instance per ClassLoader.

In Enterprise Java architectures (like Apache Tomcat, JBoss, or WebSphere), applications are packaged as WAR or EAR files. These heavy application servers use hierarchical, isolated class loaders. If your Singleton class is packaged into two separate WAR files deployed on the same Tomcat server, they will be loaded by two different class loaders. The JVM will treat them as entirely different classes. You will end up with multiple Singleton instances running in the exact same JVM memory space!

To resolve this in traditional enterprise environments, the Singleton class must be placed in a shared library folder (like Tomcat's lib directory) so it is loaded by a common parent class loader, ensuring true JVM-wide singularity.

Comparing All Singleton Implementations

To synthesize everything we have built, let's look at how the different approaches stack up against each other:

Implementation	Thread-Safe?	Lazy Loaded?	Performance	Reflection Safe?	Serialization Safe?
Eager	Yes	No	High	Needs manual check	Needs `readResolve`
Basic Lazy	No	Yes	High	Needs manual check	Needs `readResolve`
Synchronized	Yes	Yes	Very Low	Needs manual check	Needs `readResolve`
Double-Checked	Yes	Yes	High	Needs manual check	Needs `readResolve`
Bill Pugh	Yes	Yes	High	Needs manual check	Needs `readResolve`
Enum	Yes	No	High	Yes (Native)	Yes (Native)

Singleton vs Static Utility Class

A common debate among developers is why we go through the trouble of creating Singletons when we could just create a class full of static methods and variables, much like the java.lang.Math class.

Feature	Singleton Object	Static Utility Class
Object Orientation	It is a real object on the heap.	It is not an object; just a collection of functions.
Interfaces	Can implement interfaces (e.g., `ILogger`).	Cannot implement interfaces.
Inheritance	Can extend base classes and utilize polymorphism.	Cannot participate in traditional OOP inheritance.
State Management	Excellent for holding and managing complex state.	Extremely poor. Static state is difficult to track and clear.
Testing	Can be mocked dynamically in testing frameworks.	Very difficult to mock; requires advanced static mockers.

The Verdict: If you are simply grouping stateless, utility helper methods together, use a Static Class. If your component needs to manage state, maintain active connections, or adhere to interface-driven design, you must use a Singleton.

Singleton in the Spring Framework

If you are a modern Java developer, you are almost certainly using the Spring Framework. In Spring, the framework manages the lifecycle of your objects for you using a concept called Inversion of Control (IoC).

When you annotate a class with @Service or @Component, Spring essentially registers it as a Singleton Bean.

Interview Tip: It is crucial to understand the subtle difference between a GoF Java Singleton and a Spring Singleton. A classic Java Singleton guarantees one instance per ClassLoader. A Spring Singleton guarantees one instance per ApplicationContext (the Spring IoC container). If you instantiate two ApplicationContexts within the same JVM, Spring will happily create two instances of your globally intended @Service.

Because Spring handles the instantiation via Dependency Injection (DI), you completely abandon private constructors, static variables, and getInstance() boilerplates. You simply write standard, testable Java classes, and let Spring enforce the single-instance rule.

Singleton in Modern Cloud Applications

In the modern era of cloud-native development, applications are rarely deployed on a single massive server. They are broken down into microservices and deployed across dozens of identical Kubernetes pods.

This fundamentally shifts the concept of a Singleton. A Java Singleton only exists within the memory boundary of one specific pod. If you build an in-memory Singleton Cache Manager, Pod A and Pod B will have entirely disconnected, conflicting caches.

If you require a true "Cluster-wide Singleton", a resource that must be perfectly singular across a massive distributed network, a Java-level Singleton will fail you. You must step out of the JVM and rely on distributed systems tools like Redis for centralized caching, ZooKeeper for consensus, or database-level row locks for state management.

When NOT to Use Singleton (The Anti-Pattern Debate)

Despite its fame, many architects view the manual Singleton as an Anti-Pattern when misused.

The primary criticism is Hidden Dependencies. If an OrderProcessor class buries a call to PaymentGateway.getInstance() deep inside a method, the dependency is hidden. With modern Dependency Injection, dependencies are clearly declared in the constructor, making the code self-documenting.

Furthermore, Singletons introduce Global State. If Thread A mutates data inside a Singleton, and Thread B fails because of that mutation, tracking down who changed the state is a debugging nightmare.

Finally, they create a Testing Nightmare. Because Singletons persist for the entire life of the JVM, unit tests can pollute each other. Test 1 might alter the Singleton, causing Test 2 to fail simply because it expected a clean slate.

Common Mistakes Developers Make

Overusing the Pattern: Creating a Singleton just to pass arbitrary user data between two screens in a UI application. This creates severe memory leaks and fundamentally breaks architectural boundaries.
Ignoring Thread Safety: Deploying a basic Lazy Singleton to a production web server, leading to silent, untraceable race conditions.
Storing User Context: A Singleton is global. Never, under any circumstances, store user-specific context (like an Authentication Token or a Shopping Cart) in a Singleton, or User A will start seeing User B's private data!

Best Practices for Modern Development

Prefer Dependency Injection: Lean heavily on frameworks like Spring, Guice, or CDI to manage singleton lifecycles. Let the framework do the heavy lifting of instantiation and sharing.
Design for Interfaces: Even if you write a manual Singleton, have it implement an interface. This allows you to inject mock implementations during unit testing, preserving testability.
Keep it Stateless: The safest Singletons are those that perform operations (like routing or logging) without holding onto mutable, changing data. A stateless Singleton cannot cause state-corruption bugs.

Common Interview Questions and Answers

Interviewers use the Singleton pattern as a gateway to test your deeper understanding of Java mechanics. Here is how to navigate the most common questions:

Q: What exactly is a Singleton Pattern?

A: It is a creational design pattern ensuring a class has only one instance per class loader, and it provides a global point of access to that single instance.

Q: How do you prevent the cloning of a Singleton?

A: You must explicitly override the clone() method inherited from the Object class and throw a CloneNotSupportedException.

Q: Why is Double-Checked Locking broken if you forget the volatile keyword?

A: Because of instruction reordering and CPU caching visibility. Without volatile, the CPU might allocate memory for the object and assign the reference before the constructor actually runs. Another thread could see a non-null reference, try to use it, and crash because the object is only partially constructed.

Q: What is the fundamental difference between a Spring Singleton and a Java GoF Singleton?

A: A traditional GoF Java Singleton strictly guarantees one instance per JVM ClassLoader. A Spring Singleton guarantees one instance per ApplicationContext container. You can have multiple Spring containers in a single JVM.

Q: Why does Joshua Bloch recommend the Enum Singleton?

A: Because the JVM natively handles all the heavy lifting. Enums are thread-safe by default, the JVM prevents instantiation via reflection (Constructor.newInstance blocks enums), and it natively handles serialization without needing the readResolve() hack.

Q: Is the Singleton pattern considered an anti-pattern?

A: It can be. Manual Singletons introduce global state, hide class dependencies, and make isolated unit testing extremely difficult because state carries over between test cases. Modern practices heavily favor Dependency Injection over manual GoF Singletons.

Conclusion

The Singleton class in Java represents a fascinating journey through software architecture. What starts as a simple concept, a private constructor and a static variable, rapidly escalates into a deep dive into the Java Memory Model, multi-threading race conditions, CPU cache visibility, JVM class loading mechanics, and modern enterprise architecture.

While modern frameworks like Spring have largely abstracted away the need to manually write complex Bill Pugh or Double-Checked Singletons, understanding how to write them, why concurrency breaks them, and how the JVM interprets them is an absolute hallmark of a Senior Java Engineer.

Remember: A pattern is only as effective as its application. Use Singletons sparingly, prioritize statelessness, lean on Dependency Injection wherever possible, and always respect the dangers of global state.

Stop Misusing POST for Search: Welcome to the HTTP QUERY Method

Ashutosh Krishna — Sun, 12 Jul 2026 09:26:15 +0000

Every developer building Web APIs eventually runs into the exact same architectural wall. You need to build a search feature, an analytics dashboard, or a complex reporting tool. The user selects a dozen active filters, specifies nested conditions, chooses sorting rules, and hits "Search."

Suddenly, your clean backend design faces an unpleasant choice. If you choose a traditional GET request, your URL balloons into an unreadable string of encoded text that risks crashing into web browser or server character limits. If you choose a POST request, you easily bypass the size limits by placing the filter data inside the request body, but you strip away the fundamental caching, safety, and retry guarantees that make HTTP work so beautifully.

For decades, we treated this tension as just another normal quirk of web development. We built complex workarounds like persisted queries or query hashing, pretending that using an action verb like POST to perform a read-only search was fine.

That compromise is no longer necessary. The Internet Engineering Task Force (IETF) officially introduced a new standard HTTP method designed to break this deadlock: QUERY (RFC 10008).

The QUERY method fills a massive gap in web architecture. It provides the heavy-lifting capability of a request body, while preserving the clean, read-only guarantees of a safe and idempotent fetch.

Why GET Isn't Always Enough

To understand why the QUERY method matters, we need to look at the practical limits of the options we have used for years.

When you learn REST API design, the rule is simple: if you are reading data, you use GET. This approach works flawlessly for simple lookups like /api/v1/users/42 or light filtering like /products?category=shoes&size=10. The parameters are right there in the URL string. They are easy to inspect, easy to bookmark, and perfectly suited for HTTP caching layers.

However, modern applications rarely stay that simple. Imagine you are building an advanced search engine or an enterprise reporting tool. Your user wants to filter products based on a highly complex query: they need items within a specific category, priced within a dynamic range, matching an array of tags, excluding clearance items, and sorted by a complex multi-column rule.

If you try to map that into a standard GET request, the URL starts looking like an encoded mess:

GET /products/search?filter%5Bcategory%5D=laptops&filter%5Bprice%5D%5Bmax%5D=1500&filter%5Btags%5D%5B0%5D=ssd&filter%5Btags%5D%5B1%5D=business&sort=price&order=desc HTTP/1.1
Host: query-demo-self.vercel.app

This approach presents four distinct architectural problems outlined in RFC 10008:

URL Length Limitations: While the HTTP specification doesn't enforce a hard limit on URL length, the real-world infrastructure handling your traffic does. Browsers, load balancers, corporate firewalls, and Content Delivery Networks (CDNs) often truncate or reject URLs that exceed a certain size—frequently capping out around 8,000 octets (bytes). If a user pastes a massive list of IDs into a search filter, a GET request will simply fail.
Privacy and Data Leakage: URLs are designed to be visible. Because query strings live directly inside the request target, they are automatically logged in plain text by web servers, stored in browser history files, and passed along in Referer headers to third-party scripts. If your search query contains sensitive filters—like an account number, a medical symptom, or personal data—that information leaks across your infrastructure.
Encoding Overhead: Expressing complex data structures inside a target URI is highly inefficient because of the overhead of percent-encoding brackets, spaces, and special characters, making network payloads harder to read and debug.
Resource Dilution: Encoding every single query combination directly into the request URI effectively casts every unique combination of query inputs as entirely distinct resources on the web, cluttering resource organization.

Faced with these limits, many developers ask a logical question: Why not just send a request body inside a standard GET request?

The short answer is that the web infrastructure treats GET bodies as having no defined semantic meaning. Because of this ambiguity, the ecosystem handles it completely inconsistently. Some proxy servers silently strip the body before passing the request forward. Other API gateways reject the request entirely, while some frameworks ignore the body. Altering how GET processes bodies today would break millions of legacy network systems.

Why POST Isn't the Ideal Replacement

Because GET with a body is unusable in the wild, the industry settled on an alternative workaround: using POST for complex searches.

When you use POST, all your complex filters travel cleanly inside the request body. You can send a beautifully structured JSON payload of any size, avoiding URL length limits and keeping sensitive terms out of system access logs.

POST /products/search HTTP/1.1
Host: query-demo-self.vercel.app
Content-Type: application/json

{
  "category": "Laptops",
  "price": { "max": 1500 },
  "tags": ["ssd", "business"],
  "sort": { "field": "price", "order": "desc" }
}

This works around the immediate structural limits, but it introduces a major flaw into your API's network behavior: POST is semantically unsafe and non-idempotent.

In the language of HTTP, a method is considered safe if it does not change the state of the resource on the server. A method is idempotent if executing it multiple times produces the identical result and state as executing it exactly once.

Because POST is designed for state-altering actions, like creating a new database record or processing a credit card payment, network intermediaries must assume that every POST request changes something on your server. This structural assumption breaks two core performance optimizations:

Caches Are Bypassed: Because a POST request is assumed to modify state, edge networks, CDNs, and browser caches will not cache the response by default. If a thousand users execute the exact same complex dashboard query within a minute, your origin server must compute that identical database search a thousand times.
Automatic Retries Are Blocked: If a network connection drops mid-request while a browser is sending a POST request, the browser cannot safely retry it automatically. Doing so might cause a double-charge or a duplicate record. The browser is forced to display a warning to the user, even if the backend endpoint was completely read-only.

How QUERY Solves the Problem

The QUERY method defined in RFC 10008 directly resolves this tension. It serves as a semantic hybrid: it provides the robust request body capability of a POST, while strictly maintaining the safe, idempotent, and cacheable contracts of a GET.

When an endpoint uses QUERY, the protocol guarantees to every proxy, browser, and CDN along the route that the operation is entirely read-only. If a connection drops, your client library can seamlessly replay the request without risk. If an edge proxy sees identical query criteria come through a second time, it can serve a cached response immediately without waking up your origin database.

Syntax and Request Examples

To see how this works in practice, let's look at a raw HTTP representation of a QUERY request alongside its response.

The Request

QUERY /products/search HTTP/1.1
Host: query-demo-self.vercel.app
Content-Type: application/json
Accept: application/json
Accept-Query: application/json

{
  "category": "Laptops",
  "brands": ["TechNova"],
  "price": { "min": 500, "max": 1500 }
}

Unlike a classic GET, the QUERY method requires a Content-Type header. The specification explicitly dictates that if a client sends a QUERY request without a Content-Type, or if the header doesn't match the format of the body, the server MUST fail the request.

Notice the Accept-Query header. This allows the server to advertise exactly which query formats it knows how to parse for that endpoint—whether that is JSON, SQL, or a custom format.

The Response

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=3600
Content-Location: /products/search/results/a1b2c3d4
Location: /products/search/stored-queries/42

{
  "count": 2,
  "query": {
    "brands": ["TechNova"],
    "category": "Laptops",
    "price": { "max": 1500, "min": 500 }
  },
  "results": [
    {
      "id": 1,
      "name": "UltraBook Pro 14",
      "category": "Laptops",
      "brand": "TechNova",
      "price": 1299,
      "rating": 4.8,
      "stock": 32,
      "discount": 15,
      "available": true,
      "tags": ["ssd", "lightweight", "business"],
      "specs": { "cpu": "Intel Core Ultra 7", "ram": 32, "storage": 1024, "color": "Silver" }
    },
    {
      "id": 3,
      "name": "OfficeBook Air",
      "category": "Laptops",
      "brand": "TechNova",
      "price": 799,
      "rating": 4.3,
      "stock": 50,
      "discount": 20,
      "available": true,
      "tags": ["office", "budget"],
      "specs": { "cpu": "Intel Core i5", "ram": 16, "storage": 512, "color": "Gray" }
    }
  ]
}

The server processes the request payload, runs the search logic, and returns a standard 200 OK status with the data array.

The inclusion of the Content-Location and Location headers are incredibly powerful features of the specification:

Content-Location: Provides a direct URL pointing to a resource representing these specific results. A client can perform a standard GET request directly on that URL later to fetch the same snapshot.
Location: Points to the equivalent resource representing the query itself. A client can send a GET request to this URI to repeat the same search operation later without resending the large query body.

Practical Code Examples

Let's look at how to implement and use the QUERY method using modern development tools.

1. Sending a QUERY Request using cURL

You can test a QUERY endpoint directly from your terminal using standard cURL. We explicitly set the method to QUERY, provide the mandatory content headers, and pass our payload using the data flag.

curl -X QUERY https://query-demo-self.vercel.app/products/search \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"category": "Laptops", "tags": ["gaming"]}'

Why this approach is useful: Because QUERY is officially registered in the IANA HTTP methods registry, modern command-line utilities and network tools handle it natively without needing custom transport hacks.

2. Fetch API Example (JavaScript)

Modern web browsers allow you to pass arbitrary method names into the standard Fetch API. Here is how you can issue a QUERY request from client-side code:

async function searchProducts() {
  const queryPayload = {
    category: 'Laptops',
    price: { min: 1000 },
    sort: { field: 'price', order: 'desc' }
  };

  try {
    const response = await fetch('https://query-demo-self.vercel.app/products/search', {
      method: 'QUERY',
      headers: {
        'Content-Type': 'application/json',
        'Accept': 'application/json'
      },
      body: JSON.stringify(queryPayload)
    });

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    const data = await response.json();
    console.log(`Found ${data.count} items:`, data.results);
    return data;
  } catch (error) {
    console.error('Failed to execute search:', error);
  }
}

This script looks almost identical to a standard POST implementation. However, behind the scenes, the browser knows that this request is safe and idempotent. If the network drops while waiting for the response, the underlying network engine can automatically handle retrying the operation safely.

QUERY vs GET vs POST

Choosing the right tool for the job becomes much easier when we contrast the three methods side by side:

Architectural Property	GET	POST	QUERY
Request Body Allowed	No (Undefined Semantics)	Yes	Yes
Safe (Read-Only)	Yes	Potentially No	Yes
Idempotent (Safe to Retry)	Yes	Potentially No	Yes
Default Cacheable	Yes	No (Only future GET/HEAD)	Yes (Requires Body-Aware Keying)
Data Payload Location	URL Query String	Request Body	Request Body
Primary Use Case	Simple, short resource reads	Resource creation & mutation	Complex, large, or private reads

Current Support and Considerations

While RFC 10008 represents a massive leap forward for clean API design, deploying it in production requires an honest look at the current state of network infrastructure. Because it is a newer standard, adoption is an evolving process across the web ecosystem.

The Caching Challenge

Traditional caching proxies and CDNs use the request URL as the unique identifier—the "cache key"—to look up a stored response. For QUERY, this model breaks down completely. Two requests to /products/search could contain entirely different JSON filtering bodies, meaning they require completely different responses.

For QUERY caching to work safely, edge proxies must update their caching engines to fold the request body into the cache key calculation. While backend frameworks and language ecosystems have moved quickly to add native QUERY support, many edge networks and CDNs are still updating their systems to handle body-aware caching at scale.

Security and Middleboxes

Older Web Application Firewalls (WAFs) and load balancers operate on strict allowlists of classic HTTP verbs (GET, POST, PUT, DELETE). When an unconfigured security gateway encounters a QUERY request, it might react unpredictably—either blocking the traffic outright as a potential exploit attempt, or failing to inspect the body because it treats it like a standard GET.

Additionally, a QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will automatically require a "preflight" OPTIONS request, as QUERY does not belong to the basic set of CORS-safelisted methods.

Best Practices for Adopting QUERY

If you want to start integrating the QUERY method into your current systems, use these design strategies to ensure a smooth transition:

Don't Replace Simple GETs: If a request fits cleanly within a standard URL without hitting size limits or exposing sensitive data, leave it as a GET. QUERY is designed to solve the limits of complex parameters, not to deprecate standard endpoint paths.
Leverage Discovery Methods: Use the OPTIONS method to return an Allow: GET, QUERY, OPTIONS, HEAD header, cleanly signaling to clients that the resource supports the new verb.
Handle Content Negotiation Failures Gracefully: Follow the RFC guidelines for client errors. If a query syntax is correct but points to a non-existent field or table, return a 422 Unprocessable Content status code. If the media type itself isn't supported, return a 415 Unsupported Media Type along with the Accept-Query header.
Validate the Content-Type Early: Always place a validation guard at the top of your route handlers. If an incoming QUERY request omits the Content-Type header, reject it immediately with a 400 Bad Request or 415 status code to stay aligned with the official specification rules.

Key Takeaways

The introduction of the QUERY method solves a structural compromise that engineers have accepted for decades. By merging the data payload flexibility of a request body with the strict safety and idempotency rules of a read operation, it removes the need to misuse POST for complex searches.

While full integration across every browser, WAF, and CDN proxy will take time, the establishment of RFC 10008 gives developers a standardized foundation to build cleaner, more predictable, and more efficient APIs.

Build AI Apps with Gradio: Turn Your Python Scripts into Web Apps

Ashutosh Krishna — Sun, 24 May 2026 11:15:27 +0000

You build a machine learning model or a chatbot in Python. It works perfectly. The logic is solid, the API calls are fast, and the responses are exactly what you want.

But there is a problem. The entire experience is stuck inside a terminal.

Terminal interfaces are great for learning and debugging. However, nobody wants to impress users, stakeholders, or teammates with a blinking terminal cursor forever. Real users expect web interfaces with buttons, text boxes, and clean layouts.

Building a modern frontend app from scratch takes time. You have to set up React, configure a backend framework like FastAPI, manage CORS issues, and write API endpoints just to show a simple text generation result. This frontend work drastically slows down experimentation. AI engineers need to build fast prototypes, test ideas, and share them immediately.

This is where Gradio comes in.

Gradio basically lets Python developers cosplay as frontend developers for a day. It allows you to turn raw Python functions into interactive, shareable web applications in minutes (without writing a single line of HTML, CSS, or JavaScript).

In this article, we will take a simple terminal-based Gemini chatbot and convert it into a clean, modern web application.

What is Gradio?

Gradio is an open-source Python library designed specifically for building interactive web apps around machine learning models and AI scripts.

You can think of Gradio as a translation layer between your Python code and a web browser. You define the inputs your function expects (like text or images) and the outputs it returns. Gradio automatically generates a user interface that matches those parameters.

It has become massive in the AI community. If you visit Hugging Face Spaces (a popular platform for hosting AI demos), almost everything is built with Gradio. Developers love it because it requires minimal setup, enables fast iteration, and handles all the messy frontend logic under the hood.

Here is a high-level look at how it works:

The user types a message in the browser.
The Gradio UI sends that text to your Python backend.
Your Python function processes the text (calling the Google Gemini API).
The API returns the response to your function.
Gradio automatically updates the web UI with the new data.

Installing and Setting Up Gradio

Before we write code, we need a clean environment. Creating a virtual environment keeps your project dependencies isolated from the rest of your system.

Open your terminal and run these commands:

# Create a virtual environment
python -m venv ai_app_env

# Activate the environment (Mac/Linux)
source ai_app_env/bin/activate

# Activate the environment (Windows)
ai_app_env\Scripts\activate

# Install dependencies
pip install gradio google-genai python-dotenv

We are installing gradio for our UI framework, google-genai to access the free tier of Gemini models, and python-dotenv to securely manage our API keys.

Instead of exposing your API key in the terminal or hardcoding it into your script, we will use a .env file. This is a standard engineering practice to keep secrets safe.

Create a file named .env in your project folder. Go to Google AI Studio, grab your free API key, and add it to the file like this:

GEMINI_API_KEY=your_actual_api_key_here

Important: If you are using Git, make sure to add .env to your .gitignore file so you do not accidentally publish your key to the internet.

Build Your First Gradio App

Let us start with the simplest possible example to see how Gradio wires things together. We will build an app that takes a user's name and returns a greeting.

Open 01_greeting_app.py and add this code:

import gradio as gr


# 1. Define the core Python logic
def greet_user(name):
    return f"Hello, {name}! Welcome to your first AI app."


# 2. Create the Interface
demo = gr.Interface(
    fn=greet_user,
    inputs="text",
    outputs="text",
    title="Greeting Generator",
    description="Enter your name to get a custom greeting."
)

# 3. Launch the web server
if __name__ == "__main__":
    demo.launch()

This script introduces the most important class in the library: gr.Interface.

fn=greet_user: We tell Gradio exactly which Python function to run when a user interacts with the app.
inputs="text": We tell Gradio what kind of data the function expects. Because we said "text", Gradio automatically renders an HTML text box on the screen.
outputs="text": We tell Gradio what kind of data the function returns. Gradio renders another text box to display the result.
demo.launch(): This kicks off a local web server (powered by FastAPI under the hood) and opens the connection to your browser.

Run the script in your terminal:

python 01_greeting_app.py

You will see an output like Running on local URL: http://127.0.0.1:7860. Open that link in your browser.

Congratulations, you just built your first Gradio app. Go ahead and play around with it. Enter your name, your pet's name, or a random string of characters. It is a small step, but it is time to greet your new life as an AI UI developer.

The gr.Interface class does the heavy lifting here. It takes three crucial arguments:

fn: The Python function to run.
inputs: The UI component for the function's arguments.
outputs: The UI component for the function's return value.

Gradio inspects this configuration and generates the HTML, wires up the API endpoints, and handles the button clicks for you.

Convert Terminal Logic into a Web App

If you have ever built a Python chatbot before, you likely used a while True: loop to capture user input from the terminal continuously. That works, but it scales poorly.

We are going to replace the terminal loop with a Gradio chat interface. To do this, we need to handle conversation state. The Gemini API expects to see the full history of the conversation to answer context-aware questions. Gradio's ChatInterface automatically tracks history, so we just need to map Gradio's history format into the format Gemini expects.

Create a new file named 02_basic_chatbot.py for this step:

import gradio as gr
from dotenv import load_dotenv
from google import genai
from google.genai import types

# Load environment variables from the .env file
load_dotenv()

# Initialize the Gemini client (it automatically picks up the GEMINI_API_KEY env variable)
client = genai.Client()


def chat_with_ai(user_message, history):
    # Convert Gradio history format to Gemini's expected types.Content format
    contents = []
    for human_text, ai_text in history:
        contents.append(types.Content(role="user", parts=[
                        types.Part.from_text(text=human_text)]))
        contents.append(types.Content(role="model", parts=[
                        types.Part.from_text(text=ai_text)]))

    # Append the current user message
    contents.append(types.Content(role="user", parts=[
                    types.Part.from_text(text=user_message)]))

    # Configure system instructions
    config = types.GenerateContentConfig(
        system_instruction="You are a helpful engineering assistant."
    )

    # Call the free-tier Gemini model
    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=contents,
        config=config
    )

    return response.text


# Create the Chat Interface
demo = gr.ChatInterface(
    fn=chat_with_ai,
    title="Gemini Engineering Assistant",
    description="Ask me anything about Python or system design."
)

if __name__ == "__main__":
    demo.launch()

This file introduces gr.ChatInterface, which is a specialized shortcut for building chatbots. It expects your function to accept exactly two arguments: the new user_message and the history.

The trickiest part here is translating data formats. Gradio 6 formats chat history using OpenAI's standard structure (a list of dictionaries). However, the Gemini API uses its own specific object structure.

Let us break down the for msg in history: loop:

Role Mapping: Gradio calls the AI an "assistant". Gemini calls it a "model". We use a simple inline if statement to translate this.
Text Extraction: Gradio supports multimodal chat (images and text together). Because of this, it stores message content as a list of blocks. We use a list comprehension ("".join([...])) to sift through the blocks, find the text ones, and combine them into a single string.
Building Gemini Objects: We wrap our extracted text and role inside types.Content and types.Part.from_text. This is strictly required by the google-genai library.

Once the history is formatted, we append the brand-new user message, pass it to gemini-3.5-flash, and return the text response. Gradio handles rendering the chat bubbles automatically.

Run it using python 02_basic_chatbot.py.

Play around with the chat. Ask it to explain a Python concept, write a haiku, or help you debug a script. The bottom line here is that you just built a functional web interface for a powerful LLM in under 50 lines of code.

Understanding Gradio Components

gr.Interface and gr.ChatInterface are great shortcuts, but building custom apps requires knowing the individual puzzle pieces. Gradio provides dozens of UI components.

Here are the most common ones you will use in AI development:

gr.Textbox: Used for standard text entry or displaying plain text outputs. You can configure it to have multiple lines or placeholder text.
gr.Chatbot: A specialized display component that renders conversation histories in a familiar text-message bubble format.
gr.Button: Triggers Python functions when clicked.
gr.Image: Handles image uploads via drag-and-drop or webcam, and can display images generated by computer vision models.
gr.File: Allows users to upload documents (PDFs, CSVs, TXT files) and passes the file path directly to your Python script.
gr.Markdown: Renders formatted text, tables, and links to make your UI look professional.
gr.State: A hidden component that stores variables (like user session data or complex history) across page refreshes without displaying anything on the screen.

These components communicate with your backend automatically. When a user uploads a file, Gradio saves it to a temporary directory and hands your function the file path.

Understanding Blocks

The Interface class is rigid. It always puts inputs on the left and outputs on the right. When you want to build a real application, you need control over the layout.

This is why gr.Blocks exists.

Blocks give you a blank canvas. You can arrange components in rows and columns, add tabs, and assign specific click events to specific buttons.

Let us rebuild our chatbot using Blocks to add a custom layout and a "Clear History" button. Create a new file named 03_custom_layout.py:

import gradio as gr


def respond(message, history):
    # Dummy logic for demonstration
    return f"I received your message: {message}"


with gr.Blocks() as demo:
    gr.Markdown("# Custom Chatbot Layout")

    with gr.Row():
        with gr.Column(scale=4):
            chatbot = gr.Chatbot(height=400)
            msg = gr.Textbox(placeholder="Type a message and press Enter...")

        with gr.Column(scale=1):
            clear_btn = gr.Button("Clear Chat")
            settings = gr.Markdown("### Settings\n(Add dropdowns here later)")

    # Hidden state to store history (Gradio 6 uses list of dicts natively)
    state = gr.State([])

    # Event wiring
    def user_turn(user_message, history):
        # Format the user message exactly how Gradio 6 expects it
        new_msg = {"role": "user", "content": [
            {"type": "text", "text": user_message}]}
        history.append(new_msg)
        return "", history, history  # Returns: clear textbox, update state, update chatbot

    def ai_turn(history):
        # Extract the user's actual text string from the deeply nested history block
        user_message = history[-1]["content"][0]["text"]
        bot_response = respond(user_message, history)

        new_msg = {"role": "assistant", "content": [
            {"type": "text", "text": bot_response}]}
        history.append(new_msg)
        return history, history  # Returns: update state, update chatbot

    # When the user presses Enter in the text box
    msg.submit(user_turn, [msg, state], [msg, state, chatbot], queue=False).then(
        ai_turn, state, [state, chatbot]
    )

    # Clear both the hidden state and the visible UI chatbot
    clear_btn.click(lambda: ([], []), None, [state, chatbot], queue=False)

if __name__ == "__main__":
    demo.launch()

This file introduces several advanced UI concepts.

Layout with with statements: gr.Blocks() uses Python's context managers. Everything indented under with gr.Row(): will be placed side-by-side horizontally. Everything indented under with gr.Column(): will be stacked vertically. The scale argument dictates how wide the columns are relative to each other.
gr.State([]): In standard Python, variables inside functions disappear when the function finishes. gr.State creates a persistent, hidden variable attached to the user's browser session. We use it to store our list of message dictionaries.
Event Chaining (.then): Look at msg.submit(...). When a user hits Enter, we first run the user_turn function. This grabs the text, updates the state, and immediately clears the input box so it feels snappy. We use .then(...) to immediately trigger the ai_turn function right after.
Input and Output Arrays: Notice how user_turn returns three things: "", history, history. These map directly to the output array [msg, state, chatbot]. We are telling Gradio: "Set the textbox to an empty string, set the hidden state to the updated history, and set the visual chatbot to the updated history."

Run the code with python 03_custom_layout.py.

Test this out in your browser. Type a few messages, then hit the "Clear Chat" button to watch the state reset perfectly. Welcome to the Gradio block party.

Add Streaming Responses

Have you noticed how modern chat engines print words on the screen one by one? That is called streaming. It prevents the user from staring at a loading spinner for ten seconds while the model generates a long paragraph.

Streaming improves user experience drastically. Gradio supports this natively using Python generators.

Instead of using return to send the final string all at once, we use yield to send incremental updates. Create 04_streaming_chatbot.py:

import gradio as gr
from dotenv import load_dotenv
from google import genai
from google.genai import types

load_dotenv()
client = genai.Client()


def stream_chat(message, history):
    contents = []
    # History parsing logic remains identical to step 2
    for msg in history:
        role = "model" if msg["role"] == "assistant" else "user"
        text_content = "".join(
            [block["text"] for block in msg["content"] if block["type"] == "text"])
        contents.append(types.Content(role=role, parts=[
                        types.Part.from_text(text=text_content)]))

    contents.append(types.Content(role="user", parts=[
                    types.Part.from_text(text=message)]))

    # Enable streaming in the API call
    response_stream = client.models.generate_content_stream(
        model="gemini-3.5-flash",
        contents=contents
    )

    partial_message = ""
    for chunk in response_stream:
        if chunk.text is not None:
            partial_message += chunk.text
            # Yielding updates the UI immediately
            yield partial_message


demo = gr.ChatInterface(
    fn=stream_chat,
    title="Streaming Gemini Chatbot"
)

if __name__ == "__main__":
    demo.launch()

The structural logic here is almost identical to our basic chatbot, but the execution is totally different.

generate_content_stream: Instead of calling generate_content (which waits for the whole answer to be ready), we call the streaming version. This returns an iterable stream of small text chunks directly from Google's servers.
The for loop: We iterate over every chunk that arrives from the stream. We take the new text, append it to our partial_message variable, and then call yield partial_message.
yield vs return: A return statement ends a function immediately. A yield statement pauses the function, sends the current value to Gradio, updates the frontend UI, and then resumes exactly where it left off. This is the magic that creates the typing effect.

Run the file with python 04_streaming_chatbot.py.

Ask the AI a complex question. Watch the text flow in word by word. Play around with it and enjoy that smooth stream of consciousness directly from Gemini.

Upload Files and Build a Simple AI Document Chat

One of the most common AI app ideas is "chat with my document." We can build a basic version of this quickly by combining gr.File with our LLM logic.

We will read the contents of an uploaded text file and inject it into Gemini's system instructions. Create 05_document_qa.py:

import gradio as gr
from dotenv import load_dotenv
from google import genai
from google.genai import types

load_dotenv()
client = genai.Client()


def analyze_document(file_obj, user_question):
    # Prevent crashing if the user clicks Ask without a file
    if file_obj is None:
        return "Please upload a text file first."

    # Read the file text
    with open(file_obj.name, "r", encoding="utf-8") as f:
        file_content = f.read()

    # Inject the file contents directly into the system prompt
    config = types.GenerateContentConfig(
        system_instruction=f"Use this document context to answer questions:\n\n{file_content}"
    )

    response = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=user_question,
        config=config
    )

    return response.text


with gr.Blocks() as demo:
    gr.Markdown("# Document Q&A App")

    with gr.Row():
        file_input = gr.File(label="Upload a .txt file")
        question_input = gr.Textbox(label="Ask a question about the file")

    submit_btn = gr.Button("Ask")

    gr.Markdown("### AI Answer")
    # Using gr.Markdown allows Gemini's bold text, lists, and code blocks to render beautifully
    output_markdown = gr.Markdown(value="Your answer will appear here...")

    submit_btn.click(
        fn=analyze_document,
        inputs=[file_input, question_input],
        outputs=output_markdown  # Send the result straight to the Markdown component
    )

if __name__ == "__main__":
    demo.launch()

This script bridges file management and prompt engineering, and steps up our UI game.

if file_obj is None:: This is a guard clause. If the user hits the "Ask" button before uploading a file, Gradio passes None to our function. If we try to open None, Python will crash. This clause prevents the crash and returns a helpful warning to the user.
file_obj.name: When a user drops a file into a Gradio interface, Gradio does not pass the raw binary data to your function. Instead, it securely saves the file to a temporary directory on your machine and passes you an object. Calling .name retrieves the absolute file path (e.g., /tmp/gradio/some_file.txt), which we can then open normally using standard Python.
System Prompt Injection: We use an f-string to literally paste the entire text of the file into the system_instruction. We are essentially telling the AI: "Here is everything you need to know. Now, answer the user's question based only on this."
Rendering with gr.Markdown: LLMs naturally respond with Markdown formatting (like bold text or bulleted lists). If we use a standard gr.Textbox, the user sees raw asterisks and hashes. By assigning gr.Markdown to our outputs array, Gradio parses the formatting automatically. Mark my words, formatted text is infinitely easier to read.

Run the script with python 05_document_qa.py.

Upload a .txt file containing an article, a snippet of code, or some meeting notes, and start asking questions. Play around to see how well Gemini pulls facts from your custom context. You can officially file this under "cool things I built today."

Deploying Gradio Apps

Building locally is fun, but you eventually need to share your work.

The fastest way to share a prototype is changing your launch command in any of these scripts:

demo.launch(share=True)

This generates a public gradio.live link valid for 72 hours. It tunnels traffic from the public URL directly to the Python script running on your laptop. It is perfect for showing a quick demo to a coworker over Slack.

For permanent deployment, the standard route is Hugging Face Spaces. Spaces offers free hosting tailored specifically for Gradio apps. You just create a repository, upload your specific Python file (renamed to app.py for Hugging Face) and a requirements.txt file, and Hugging Face handles the server configuration automatically.

Remember, your .env file is only for local development. When deploying to Hugging Face Spaces, you must set your GEMINI_API_KEY inside the repository's settings as a hidden secret so your app continues working securely in the cloud.

Keep in mind that Gradio is optimized for prototyping and internal tools. A basic Gradio app is not designed to handle thousands of concurrent users or complex authentication systems out of the box. Be realistic about your deployment goals.

How Gradio Works Internally

You do not need to know the internals to use Gradio, but understanding them makes debugging much easier.

Under the hood, when you call demo.launch(), Gradio starts a local web server using FastAPI. This server exposes API endpoints based on the functions you defined.

On the frontend, Gradio serves a single-page application (built with Svelte). When a user clicks a button, the Svelte frontend sends an HTTP request to your FastAPI backend. Your Python code runs, processes the data, and returns a JSON response.

If you are using streaming or long-running tasks, Gradio switches from standard HTTP requests to WebSockets. This allows a persistent, two-way connection where your Python script can continuously push text chunks to the browser without waiting for the user to request them.

Common Beginner Mistakes

When developers first start building AI UIs, they usually run into the same handful of issues.

Blocking the UI: Python runs synchronously by default. If your API call takes 20 seconds, the Gradio UI will freeze for 20 seconds. Use asynchronous functions or generators (yield) to keep the interface responsive.
Forgetting State: Python variables inside functions reset on every click. If you need to remember data between clicks (like chat history or user choices), you must pass it through a gr.State component or the specialized history arguments.
Exposing API Keys: Never hardcode your API keys into your Python scripts. Always use the .env approach combined with the python-dotenv package. If you upload a hardcoded key to GitHub, bots will find it in seconds.
Handling Large Files Badly: Reading massive datasets entirely into memory will crash your app. If a user uploads a 50MB text file, reading it straight into an LLM prompt will trigger context window boundaries or network timeouts.

When to Use Gradio vs Full Frameworks

Gradio is a specific tool for a specific job.

Use Gradio when:

You want to test an AI idea in an afternoon.
You need to share a prototype with non-technical stakeholders.
You are building an internal utility tool for your team.
You want to host a portfolio project on Hugging Face.

Use Streamlit when:

Your app is heavily focused on data science, charts, and dashboards rather than pure inputs and outputs. (Streamlit is another great Python UI tool, optimized slightly more for data visualization).

Use FastAPI + React (Full Framework) when:

You are building a production SaaS product.
You need strict user authentication, database management, and complex state routing.
You have thousands of users and need to scale microservices.

Building UIs manually for every AI experiment gets old very quickly. Gradio shines during the discovery phase of software engineering.

Final Thoughts

The distance between an idea and a working web app has never been shorter. Gradio became popular in the AI landscape because it eliminated the frontend bottleneck for machine learning engineers.

Using a free-tier API like Gemini means you can experiment with intelligent text generation models endlessly without running up an infrastructure bill. Separating your code into specific scripts like we did makes it easy to push to GitHub, build a portfolio, and reference past work.

You can find all the separate Python scripts we wrote today neatly organized in this GitHub repository. Feel free to fork it, clone it to your local machine, and use those files as a baseline for your own projects. Take the code examples from this article and experiment. Change the system prompts, tweak the UI blocks, or try uploading different file types.

The fastest way to learn AI engineering is to build things and put them out into the world. Once you turn your Python logic into a working Gradio app, share a screenshot or a screen recording of your project on Twitter/X/LinkedIn. Make sure to tag me at @ashutoshkrris so I can see what you built and help showcase your work.

You have the tools. Now go build some AI apps.

Originally published on Ashutosh Writes.

Spring Boot @Value Property Order Explained

Ashutosh Krishna — Thu, 20 Nov 2025 19:02:53 +0000

If you’ve ever been in a Spring Boot interview, you’ve probably come across this question:

“Where does Spring Boot look for @Value("${my.property:DEFAULT_VALUE}"), and in what order?”

At first, it might sound straightforward, but it actually tests a developer’s understanding of how Spring Boot resolves configuration properties — a concept that directly impacts how applications behave across environments.

Understanding the configuration hierarchy in Spring Boot is essential because it helps you:

Debug issues when the wrong value is picked up.
Control how environment variables and external configurations override defaults.
Manage different environments such as development, staging, and production in CI/CD pipelines.

In this article, we’ll look at how @Value works, the exact order in which Spring Boot looks for property values, and why this knowledge is crucial for building predictable and maintainable applications.

Understanding the @Value Annotation
Where Does Spring Boot Look for Properties (Order of Resolution)
Example Demonstration
- Step 1: Define properties in both files
- Step 2: Use @Value in your code
- Step 3: Run the application with different configurations
  - Case 1: Default profile (no active profile)
  - Case 2: Active profile set to “dev”
  - Case 3: Override from the command line
  - Case 4: No property found anywhere
Common Pitfalls
- 1. Forgetting to Set the Active Profile
- 2. Unintentional Property Overrides
- 3. Confusing @Value and @ConfigurationProperties
Interview Tip / Summary
- Quick Mnemonic to Remember the Order
Frequently Asked Questions (FAQ)
- 1. What happens if a property is missing and no default value is given?
- 2. How does @ConfigurationProperties differ from @Value?
- 3. Can we override properties at runtime?

Understanding the `@Value` Annotation

The @Value annotation in Spring Boot is used to inject values into fields directly from property sources such as application.properties, application.yml, environment variables, or command-line arguments. It allows you to bind configuration values to variables in your code without hardcoding them.

Here’s a simple example:

@Value("${my.property:DEFAULT_VALUE}")
private String myProperty;

In this example:

my.property is the key whose value Spring Boot will try to resolve.
DEFAULT_VALUE is the fallback value that will be used if the property is not found in any configuration source.

This default value mechanism is very useful. It ensures your application does not fail to start even if a configuration is missing. Instead, Spring Boot will inject the specified default, keeping your application stable and predictable.

Using @Value is a simple way to access configuration properties for small or single-value injections. For more complex or grouped configurations, developers often use @ConfigurationProperties, which we’ll discuss later.

Where Does Spring Boot Look for Properties (Order of Resolution)

When you use @Value or any other property injection mechanism, Spring Boot doesn’t just look in one place for configuration values. It searches across multiple sources in a specific priority order.

This order determines which value is finally injected when the same property key appears in different places. The higher the source is in the list, the greater its priority.

Here’s the general order in which Spring Boot resolves properties (based on the SpringApplication configuration sources):

Priority	Source	Example / Notes
1	Command-line arguments	e.g. `--my.property=value` when running the application
2	Java System properties	e.g. `-Dmy.property=value`
3	OS environment variables	e.g. `export MY_PROPERTY=value`
4	Application properties or YAML files	Located in `src/main/resources/application.properties` or `.yml`
5	Profile-specific configuration files	e.g. `application-dev.properties` when `spring.profiles.active=dev`
6	External configuration files	Files located in a `/config` directory outside the packaged JAR
7	JNDI attributes	Used in servlet containers or enterprise environments
8	Random values	e.g. `${random.uuid}`, `${random.int}` generated by Spring Boot
9	Default value in code	The fallback provided in `@Value("${my.property:default}")`

Spring Boot checks these sources in order — from top to bottom — and uses the first value it finds for a given property key.

This hierarchy allows you to easily override configurations at runtime without changing your code. For example, values from command-line arguments or environment variables can override those in your application files, which is especially useful for deploying the same codebase to multiple environments like development, testing, and production.

Example Demonstration

Let’s look at a simple example to understand how Spring Boot decides which property value to use when multiple sources define the same key.

Imagine the following project structure:

src/
 └─ main/resources/
     ├─ application.properties
     ├─ application-dev.properties

Step 1: Define properties in both files

application.properties

my.property=HelloFromApplication

application-dev.properties

my.property=HelloFromDevProfile

Step 2: Use `@Value` in your code

@Value("${my.property:DefaultHello}")
private String message;

Step 3: Run the application with different configurations

Case 1: Default profile (no active profile)

If you run your Spring Boot app normally:

java -jar myapp.jar

Spring Boot will load application.properties and inject the value:

HelloFromApplication

Case 2: Active profile set to “dev”

If you run:

java -jar myapp.jar --spring.profiles.active=dev

Spring Boot will load both application.properties and application-dev.properties, but the profile-specific file has higher priority.

So the value becomes:

HelloFromDevProfile

Case 3: Override from the command line

Now, if you run:

java -jar myapp.jar --my.property=HelloFromCLI

Command-line arguments take the highest priority, so this overrides everything else:

HelloFromCLI

Case 4: No property found anywhere

If you remove the property from all configuration files and don’t pass it as an argument, Spring Boot uses the default value given in the code:

DefaultHello

This example shows how Spring Boot’s property resolution order allows flexible configuration management. You can define defaults in your code, keep environment-specific values in property files, and still override them at runtime when needed.

Common Pitfalls

Even though Spring Boot’s configuration system is powerful, it’s easy to run into small mistakes that cause unexpected behavior. Here are some common pitfalls developers face when working with @Value and property resolution.

1. Forgetting to Set the Active Profile

Spring Boot supports profile-specific configuration files, such as application-dev.properties or application-prod.properties.

However, these files are only used when the corresponding profile is active. If you forget to set the profile, Spring Boot will ignore those files and fall back to the default application.properties.

For example:

java -jar myapp.jar --spring.profiles.active=dev

Without this argument, your application-dev.properties file won’t be loaded at all.

2. Unintentional Property Overrides

Because Spring Boot merges multiple property sources, it’s possible to accidentally override values from one source with another.

A common case is when an environment variable or command-line argument unintentionally replaces a property defined in your configuration file.

For instance, if your system has an environment variable named MY_PROPERTY, it might override the my.property key from your .properties file. Always check the effective configuration when debugging unexpected values.

3. Confusing `@Value` and `@ConfigurationProperties`

Both @Value and @ConfigurationProperties are used to inject configuration values, but they serve different purposes.

Feature	`@Value`	`@ConfigurationProperties`
Best for	Single values	Grouped or structured properties
Type safety	Limited	Strong (binds directly to fields)
Supports validation	No	Yes
Preferred for large configs	❌	✅

Use @Value when you only need a few properties.
Use @ConfigurationProperties when dealing with a group of related configurations (for example, database settings or API credentials).

Choosing the right one helps keep your configuration clean, organized, and easy to maintain.

Interview Tip / Summary

When asked about property resolution in Spring Boot interviews, it’s not just about recalling the list — it’s about showing that you understand how and why it works that way.

Here are the key points to keep in mind:

Spring Boot merges multiple property sources — it doesn’t rely on a single file.
Higher-priority sources override lower-priority ones — values from the command line or environment variables can replace those in your application files.
@Value("${my.property:DEFAULT}") provides a safety net — the default value ensures your application runs even when the property is missing.

Quick Mnemonic to Remember the Order

You can remember the lookup order with this simple phrase:

“CLI → System → Env → App → Default”

Or think of it as:

Command-line arguments
↓
System properties (-D)
↓
Environment variables
↓
Application files (.properties / .yml)
↓
Default value in code

If you end your interview answer with a short, clear explanation like this:

“Spring Boot checks multiple property sources in a specific order — starting from command-line arguments, system properties, environment variables, and application files, before finally using the default value provided in code.”

—you’ll leave a confident and lasting impression.

Frequently Asked Questions (FAQ)

1. What happens if a property is missing and no default value is given?

If a property key cannot be found in any configuration source and you haven’t provided a default value in your @Value expression, Spring Boot will throw an exception during startup.

For example:

@Value("${my.property}")
private String value;

If my.property is not defined anywhere, you’ll see an error like:

Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'my.property' in value "${my.property}"

To prevent this, always provide a fallback value:

@Value("${my.property:DefaultValue}")
private String value;

This ensures your application starts smoothly, even when the property is missing.

2. How does `@ConfigurationProperties` differ from `@Value`?

While both are used to inject configuration values, they are suited to different use cases:

@Value is ideal for single values or small configurations.

Example:
```
@Value("${server.port:8080}")
private int port;
```
@ConfigurationProperties is better for structured or grouped configurations, such as database or API settings. It binds multiple related properties into a single Java object and supports validation.

Example:
```
@ConfigurationProperties(prefix = "app")
public class AppConfig {
    private String name;
    private String version;
}
```

In short, use @Value for simple injections and @ConfigurationProperties for larger, type-safe configurations.

3. Can we override properties at runtime?

Yes, you can override properties at runtime without changing your code.

Spring Boot allows this through various property sources, such as:

Command-line arguments
```
java -jar myapp.jar --server.port=9090
```
Environment variables
```
export SERVER_PORT=9090
```
System properties
```
java -Dserver.port=9090 -jar myapp.jar
```

These dynamic overrides are particularly useful in CI/CD pipelines or cloud environments, where configurations may differ between development, staging, and production.

DTO vs Record in Java: Which Should You Use?

Ashutosh Krishna — Sun, 29 Sep 2024 19:16:58 +0000

In Java applications, we often need to transfer data between different layers of the application, or between services. For this purpose, we use Data Transfer Objects (DTOs). A DTO is a simple object designed to hold data, without any complex behavior or logic. Its job is to bundle data and pass it along where needed.

Now, Java introduced a new feature in Java 14, called Records. These are special types of classes that focus on holding data, just like DTOs. The big difference is that Records do a lot of the repetitive work for us. For example, they automatically create methods to get the data (like getters), and they handle equality checks, toString(), and more. This feature became fully available in Java 16, making Records a modern, clean way to work with data in Java.

So, why are we comparing DTOs and Records? Because they both serve a similar purpose — carrying data. However, understanding when to use one over the other is important as Java continues to evolve. In this article, we’ll explore the differences and help you decide which one fits your needs better, especially if you’re working on modern Java applications.

What is a DTO?
- How are DTOs implemented?
What is a Java Record?
- Key Features of Java Records
- Why Use Records?
Comparing DTO and Record
- Immutability
- Boilerplate Code
- Data Representation
- Customization
- Alignment with Functional Programming
When to Use DTO vs Record
- When to Use DTOs
- When to Use Records
Performance Considerations
- Memory Efficiency
- Immutability and Thread-Safety
- Garbage Collection
- CPU Overhead
- Real-World Performance Impact
Wrapping Up

What is a DTO?

A Data Transfer Object (DTO) is a simple Java object that is used to move data between different parts of an application. Think of it as a container for carrying data between layers of your application. For example, in a web application, a DTO might be used to transfer data from the service layer to the controller, or from the controller to the view layer.

DTOs help keep the different parts of an application separated, making the code more organized and easier to maintain. They typically don’t have any business logic or complex behavior. Instead, they just hold data.

How are DTOs implemented?

DTOs are usually implemented as regular Java classes. A typical DTO includes:

Private fields for the data it holds.
Getters and Setters to access and modify the data.
A Constructor to create the object.
Override methods like toString(), hashCode(), and equals() for comparing and printing the object in a meaningful way.

Here’s an example of a UserDTO class :

import java.util.Objects;

public class UserDTO {
    private String name;
    private int age;
    private String email;

    // Constructor
    public UserDTO(String name, int age, String email) {
        this.name = name;
        this.age = age;
        this.email = email;
    }

    // Getters and Setters
    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    // Overriding toString method for meaningful output
    @Override
    public String toString() {
        return "UserDTO{" +
                "name='" + name + '\'' +
                ", age=" + age +
                ", email='" + email + '\'' +
                '}';
    }

    // Overriding equals method for object comparison
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        UserDTO userDTO = (UserDTO) o;
        return age == userDTO.age && Objects.equals(name, userDTO.name) && Objects.equals(email, userDTO.email);
    }

    // Overriding hashCode method
    @Override
    public int hashCode() {
        return Objects.hash(name, age, email);
    }
}

This UserDTO class holds information about a user: their name, age, and email. It also provides basic functionality like comparing two UserDTO objects (using equals()), generating a unique hash code (using hashCode()), and a toString() method for readable output.

With tools like Lombok, you can avoid manually writing boilerplate code while still having a fully functional DTO. However, with Records, as we’ll explore later, Java offers an alternative that also eliminates much of the boilerplate but with a different design philosophy (immutability by default).

Here’s how you can use the UserDTO:

public class UserDTOUsageExample {
    public static void main(String[] args) {
        UserDTO user = new UserDTO("Ashutosh", 25, "ashutosh@example.com");

        // Access data
        System.out.println(user.getName());
        System.out.println(user.getAge());
        System.out.println(user.getEmail());

        // Using the toString() method
        System.out.println(user);

        // Comparing records
        UserDTO anotherUser = new UserDTO("Vishakha", 22, "vishakha@example.com");
        System.out.println(user.equals(anotherUser));
    }
}

Output:

Ashutosh
25
ashutosh@example.com
UserDTO{name='Ashutosh', age=25, email='ashutosh@example.com'}
false

What is a Java Record?

Java Records are a special type of class introduced in Java 14 (as a preview feature) and fully released in Java 16. They simplify the creation of immutable data carriers. Records are designed to hold data in a concise and readable way, and they eliminate much of the boilerplate code that traditional classes, like DTOs, require.

In a traditional DTO, you manually write constructors, getters, equals(), hashCode(), and toString() methods (as we did earlier). With Records, Java generates all of these for you automatically. This makes them ideal for simple, immutable objects whose main job is to carry data.

Key Features of Java Records

Immutable by default: Once you create a record, you can't change its data (unlike DTOs, which are typically mutable).
Compact syntax: You declare the fields and Java generates the constructor, getters, equals(), hashCode(), and toString() automatically.
No setters: Since records are immutable, they don’t provide setters.

Let’s create a UserRecord that represents the same user data as our earlier UserDTO, but using a record:

public record UserRecord(String name, int age, String email) {
}

That's it! With just one line, Java generates:

A constructor: new UserRecord(String name, int age, String email)
Getters for each field: name(), age(), and email()
An equals() method for comparing two UserRecord objects.
A hashCode() method to generate a unique hash code.
A toString() method that returns a string representation like this: UserRecord[name=Ashutosh, age=25, email=ashutosh@example.com].

Here’s how you can use the UserRecord:

public class UserRecordUsageExample {
    public static void main(String[] args) {
        UserRecord user = new UserRecord("Ashutosh", 25, "ashutosh@example.com");

        // Access data
        System.out.println(user.name());
        System.out.println(user.age());
        System.out.println(user.email());

        // Using the toString() method
        System.out.println(user);

        // Comparing records
        UserRecord anotherUser = new UserRecord("Vishakha", 22, "vishakha@example.com");
        System.out.println(user.equals(anotherUser));
    }
}

Output:

Ashutosh
25
ashutosh@example.com
UserRecord[name=Ashutosh, age=25, email=ashutosh@example.com]
false

With UserRecord, we avoided writing getters, constructors, equals(), hashCode(), and toString() manually. Java Records offer a clean, concise way to create immutable objects that only carry data.

Why Use Records?

Less Boilerplate: You don’t have to write repetitive code like getters or equals() methods.
Immutable by Design: Ensures the data can't be changed after the object is created, making it safer to use in multi-threaded environments.
Clear Intent: Using a Record clearly communicates that the object is just for carrying data, without additional behavior or logic.

Comparing DTO and Record

Now that we know about DTO and Records, let’s compare them in this section.

Immutability

Records are immutable by design, meaning once you create a record instance, you can’t change its data. This immutability ensures that the data remains consistent and thread-safe without needing any extra code. For example, in a UserRecord, the fields name, age, and email can be set only when the record is created, and they can't be modified afterward.

On the other hand, DTOs are typically mutable, meaning their fields can be changed after the object is created. To make DTOs immutable, you would have to explicitly avoid setters or design them carefully (e.g., using final fields). Here’s how immutability looks with a record versus a traditional DTO:

Record: Immutable by default.
DTO: Requires manual enforcement for immutability, which can lead to more complex code and potential bugs.

public class ImmutabilityExample {
    public static void main(String[] args) {
        UserDTO userDTO = new UserDTO("Ashutosh", 25, "ashutosh@example.com");
        userDTO.setAge(26);  // DTO allows this by default.

        UserRecord userRecord = new UserRecord("Ashutosh", 25, "ashutosh@example.com");
        userRecord.name = "Jane"; // This would result in a compile-time error.
    }
}

Boilerplate Code

One of the biggest advantages of Records is that they significantly reduce boilerplate code. When using a DTO, you often have to manually write getters, setters, constructors, equals(), hashCode(), and toString() methods. With Records, all of this is generated for you automatically.

In contrast, traditional DTOs require more manual coding. Although tools like Lombok can help reduce the amount of boilerplate, they still don’t provide the same level of simplicity as Records. Here’s a comparison:

Record: Automatically generates constructor, getters, equals(), hashCode(), and toString().
DTO: Requires manual implementation or the use of tools like Lombok.

Data Representation

Records provide a compact and concise way of representing data. Since the declaration of a Record contains only the fields, the code is cleaner and easier to read. This makes it easier to maintain, especially in projects with a lot of data models.

For example:

// Record: Clean and simple
public record UserRecord(String name, int age, String email) {}

Compare this to a DTO, which typically has a lot more code:

// DTO: More verbose
public class UserDTO {
    private String name;
    private int age;
    private String email;

    // Constructor, Getters, Setters, toString, equals, hashCode...
}

With Records, the intent is clearer: it’s just a data carrier with no extra behavior, whereas DTOs can easily become cluttered with boilerplate or additional logic.

Customization

One area where DTOs have an advantage is in customization. DTOs allow you to add custom logic, such as data validation, transformation methods, or even business logic if needed (although this is generally discouraged in pure DTOs). For example, you could add a validation method to ensure the email field follows a valid format.

With Records, customization is more limited. Since they are designed to be lightweight and immutable, you can’t easily add custom methods that modify internal state or perform complex logic. If your use case requires custom behavior or logic in your data objects, DTOs offer more flexibility.

Here’s a quick example of adding custom validation to a DTO:

public class UserDTO {
    private String email;

    // Method to validate email format
    public boolean isValidEmail() {
        return email != null && email.contains("@");
    }
}

With a Record, this level of customization would typically be handled outside the Record itself. Records focus strictly on carrying data, while logic like validation is expected to be handled elsewhere.

Alignment with Functional Programming

One of the key principles of functional programming is immutability — the idea that data objects should not be changed after they are created. Records align more closely with functional programming principles because they are immutable by default. This makes them an ideal choice in systems that favor or adopt a functional programming style.

Records:
- Designed to be immutable, which aligns with functional programming's emphasis on creating data structures that cannot change state.
- They promote a more declarative style, where you can pass around immutable data objects without side effects, making them predictable and easier to reason about.

In contrast, DTOs are traditionally mutable by nature. While it’s possible to make DTOs immutable (by avoiding setters and using final fields), it requires manual enforcement. DTOs often follow the object-oriented paradigm, where state changes are more common.

DTOs:
- More flexible in terms of mutability, which makes them better suited to imperative or object-oriented programming styles.
- When used in their mutable form, DTOs can lead to side effects, which is generally discouraged in functional programming.

When to Use DTO vs Record

When deciding between using a DTO or a Record, the choice depends largely on your specific use case, project requirements, and the version of Java you're using. Below is a breakdown of when to use each:

When to Use DTOs

When mutability is required:

If your object’s data needs to be modified after creation, DTOs are the better choice. DTOs are typically mutable, allowing you to change the values of fields as needed. This is useful in scenarios where data is updated throughout the lifecycle of an object.

Example: In a web application, a form submission may initially create a UserDTO with some fields left blank. As the user updates their profile, the UserDTO may need to change accordingly.
When additional behavior or validation logic is needed:

DTOs are more flexible when it comes to adding custom behavior like validation, transformations, or additional methods. If your data object needs logic beyond simply carrying data (e.g., verifying an email format or sanitizing input), then a DTO is more suitable.

Example: Adding a method in UserDTO to validate the format of an email before passing it between layers of your application.
Compatibility with older versions of Java (pre-Java 16):

If your project is running on a version of Java earlier than Java 16, you won’t be able to use Records. In these cases, you’ll need to use traditional DTOs or alternatives like Lombok to simplify the code.

Example: If your application must support Java 11 or Java 8, then Records are not an option, and you’ll stick with DTOs.

When to Use Records

When you need a concise, immutable data carrier:

Records are ideal when you need a lightweight, immutable object to carry data. Since they automatically generate essential methods (constructor, getters, equals(), hashCode(), and toString()), they offer a clean and efficient way to represent data.

Example: If you’re transferring data between services in a microservice architecture and don't need to modify the data, a UserRecord would be a perfect fit.
For read-only data transfer between layers or services:

If your application involves passing data around without the need to modify it, using a Record is a great choice. The immutability of Records ensures that the data remains consistent, making it suitable for cases like sending data from the database to a service layer or from one service to another.

Example: A Record might be used to send user data from a database layer to a REST controller in a web application.
In modern Java applications (Java 16+):

If your project uses Java 16 or later, you can take full advantage of Records. They are designed to simplify data representation in modern Java applications and help reduce the boilerplate that comes with traditional DTOs.

Example: In a Java 17 web service, you might use Records for all your data transfer needs between different layers of your application to keep the codebase concise and maintainable.

Performance Considerations

When comparing DTOs and Records in terms of performance, the differences are typically minimal, but there are a few important factors to consider:

Memory Efficiency

Since Records are compact by design, they may consume slightly less memory than traditional DTOs. The key reason is that Records do not require the additional overhead of manually implementing getters, setters, equals(), hashCode(), and toString() methods. All of this is generated automatically by the Java compiler in a more optimized way, resulting in a smaller memory footprint.

For example:

A DTO would need separate fields and methods for each operation (getName(), setName(), etc.).
A Record internally holds just the fields and automatically generates the necessary methods, potentially using fewer resources.

Immutability and Thread-Safety

The immutable nature of Records provides some inherent performance benefits, particularly in multi-threaded environments. Since Records are immutable, they don’t require synchronization or locking mechanisms when shared between threads. This can lead to better performance in scenarios where thread contention would normally degrade performance.

In contrast, if you use mutable DTOs in multi-threaded environments, you need to ensure thread safety, either by synchronizing access or using other mechanisms, which can introduce overhead and slow down the application.

Garbage Collection

Both DTOs and Records are plain Java objects (POJOs), so they are subject to the same garbage collection process. However, the concise nature of Records could lead to slightly faster garbage collection, as fewer objects are created or held in memory. This can contribute to improved performance in long-running applications or those handling large volumes of data objects.

CPU Overhead

Since Records are auto-generated by the compiler and are optimized for performance, there may be slight CPU performance improvements in operations such as object creation, method invocation, and comparison (equals(), hashCode()). This is particularly true when comparing complex DTOs where developers might introduce inefficiencies in manually implemented methods. The uniformity and optimization of Records ensure that these operations are handled consistently and efficiently.

Real-World Performance Impact

In practice, the performance differences between DTOs and Records will likely be small and often negligible for most applications. The compact nature of Records might lead to slight performance gains in some scenarios, but the actual impact would only be noticeable in applications with heavy data processing, high throughput, or those running in resource-constrained environments (e.g., mobile or IoT devices).

Wrapping Up

In this tutorial, we've explored the key differences between DTOs and Records, their respective use cases, and how they align with different programming paradigms like functional programming. While DTOs offer flexibility, mutability, and custom behavior, Records provide a concise and immutable way to model data, making them ideal for modern Java applications.

The decision to use a DTO or a Record ultimately depends on your specific requirements:

If you need mutability or want to add custom logic, DTOs are a better fit.
If you prefer a compact, immutable structure and are working in Java 16 or later, Records offer a cleaner and more efficient option.

Both approaches have their strengths, and understanding when to use each will help you write more efficient and maintainable Java code.

Simplify Your DEV Posts with Table of Contents Generator

Ashutosh Krishna — Tue, 06 Aug 2024 19:26:02 +0000

Organizing content for clarity and ease of navigation is essential in the digital age. Whether you're writing a comprehensive article, a well-structured table of contents (TOC) can significantly enhance the readability of your content. TOC Generator makes generating TOCs effortless, helping you focus on content creation rather than formatting. This article will explain how this tool can assist you and guide you through the process.

Why Use a Table of Contents?
Key Features of the Application
How to Use the TOC Generator for freeCodeCamp
How to Use the TOC Generator for Markdown
Benefits of Using Our Application
Conclusion

Why Use a Table of Contents?

Enhanced Navigation: TOCs allow readers to quickly jump to sections of interest.
Improved Readability: A clear structure helps understand the document's flow.
Better SEO: Well-organized content is more likely to rank higher in search engines.

Key Features of the Application

Supports freeCodeCamp Draft Posts: Easily generate TOCs for your drafts using the platform's unique URL.
Markdown Support: Quickly convert your Markdown headers into a clickable TOC.
User-Friendly Interface: Simple and intuitive design for a seamless experience.

Here's a demo of the application:

How to Use the TOC Generator for freeCodeCamp

Access the Application

Visit the TOC Generator website.
Select the Level

Choose the "Single Level" or "Multi-Level" as per your choice.
Enter the Article URL

Input your freeCodeCamp draft post link. The placeholder will show an example URL format for guidance: https://www.freecodecamp.org/news/p/f9bddb65-b444-4447-8451-b0857fecb0c2/.
Generate TOC

Click the "Generate TOC" button to create a structured TOC.

Sample TOC with Single Level Headings:

Sample TOC with Multi-Level Headings:

How to Use the TOC Generator for Markdown

Access the Markdown TOC Generator

Visit our Markdown TOC Generator page.
Enter Your Markdown Content

Paste or type your Markdown content into the provided textbox.
Generate TOC

Click "Generate TOC" to automatically generate the TOC based on your headers.
Copy the TOC

Use the "Copy" button to copy the TOC to your clipboard.

Benefits of Using Our Application

Time-Saving: Quickly generate TOCs without manual formatting.
Consistency: Ensure your TOC is always formatted correctly.
Versatility: Suitable for various platforms and content types.

Conclusion

My Table of Contents Generator is designed to streamline the process of organizing your content, making it easier for your readers to navigate and understand. Whether you're a freeCodeCamp contributor or a Markdown enthusiast, this tool can enhance your workflow and improve the presentation of your work. Try it out today and see how it can simplify your content creation process!

Try out the tool here: https://toc-generator.ashutoshkrris.in/

Fun Fact: The Table of Contents of this post was also generated using the same tool.

Comparable vs Comparator Explained in Java

Ashutosh Krishna — Sat, 20 Jul 2024 20:01:59 +0000

Sorting is a fundamental operation in programming, essential for organizing data in a specific order. In Java, built-in sorting methods provide efficient ways to sort primitive data types and arrays, making it easy to manage and manipulate collections of data. For instance, you can quickly sort an array of integers or a list of strings using methods like Arrays.sort() and Collections.sort().

However, when it comes to sorting custom objects, such as instances of user-defined classes, the built-in sorting methods fall short. These methods don't know how to order objects based on custom criteria. This is where Java's Comparable and Comparator interfaces come into play, allowing developers to define and implement custom sorting logic tailored to specific requirements.

In this blog post, we'll explore how to use the Comparable and Comparator interfaces to sort custom objects in Java. I'll provide examples to illustrate the differences and use cases for each approach, helping you master custom sorting in your Java applications.

Sorting Methods for Primitive Types
- Arrays.sort()
- Collections.sort()
- Limitations with Custom Classes
Comparable Interface
- Overview
- How Comparable Allows for a Single Natural Ordering of Objects
- Limitations of Comparable
Comparator Interface
- Overview
- How Comparator Allows for Multiple Ways of Ordering Objects
  - Comparator by Name
  - Comparator by Age
  - Comparator by Weight
Comparable vs Comparator
- Comparison
- Benefits and Drawbacks of Each Approach
  - Comparable
  - Comparator
Wrapping Up

Sorting Methods for Primitive Types

Java provides a variety of built-in sorting methods that make it easy to sort primitive data types. These methods are highly optimized and efficient, allowing you to sort arrays and collections with minimal code. For primitive types, such as integers, floating-point numbers, and characters, the Arrays.sort() method is commonly used.

Arrays.sort()

The Arrays.sort() method sorts the specified array into ascending numerical order. This method uses a Dual-Pivot Quicksort algorithm, which is faster and more efficient for most data sets.

Let's look at an example of sorting an array of integers and characters using Arrays.sort():

package tutorial;

import java.util.Arrays;

public class PrimitiveSorting {
    public static void main(String[] args) {
        int[] numbers = { 5, 3, 8, 2, 1 };
        System.out.println("Original array: " + Arrays.toString(numbers));

        Arrays.sort(numbers);
        System.out.println("Sorted array: " + Arrays.toString(numbers));

        char[] characters = { 'o', 'i', 'e', 'u', 'a' };
        System.out.println("Original array: " + Arrays.toString(characters));

        Arrays.sort(characters);
        System.out.println("Sorted array: " + Arrays.toString(characters));
    }
}

Output:

Original array: [5, 3, 8, 2, 1]
Sorted array: [1, 2, 3, 5, 8]
Original array: [o, i, e, u, a]
Sorted array: [a, e, i, o, u]

Collections.sort()

The Collections.sort() method is used to sort collections such as ArrayList. This method is also based on the natural ordering of the elements or a custom comparator.

package tutorial;

import java.util.ArrayList;
import java.util.Collections;

public class CollectionsSorting {
    public static void main(String[] args) {
        ArrayList<String> wordsList = new ArrayList<>();
        wordsList.add("banana");
        wordsList.add("apple");
        wordsList.add("cherry");
        wordsList.add("date");
        System.out.println("Original list: " + wordsList);

        Collections.sort(wordsList);
        System.out.println("Sorted list: " + wordsList);
    }
}

Output:

Original list: [banana, apple, cherry, date]
Sorted list: [apple, banana, cherry, date]

Limitations with Custom Classes

While Java's built-in sorting methods, such as Arrays.sort() and Collections.sort(), are powerful and efficient for sorting primitive types and objects with natural ordering (like String), they fall short when it comes to sorting custom objects. These methods do not inherently know how to order user-defined objects because there is no natural way for them to compare these objects.

For example, consider a simple Person class that has name, age, and weight attributes:

package tutorial;

public class Person {
    String name;
    int age;
    double weight;

    public Person(String name, int age, double weight) {
        this.name = name;
        this.age = age;
        this.weight = weight;
    }

    @Override
    public String toString() {
        return "Person [name=" + name + ", age=" + age + ", weight=" + weight + " kgs]";
    }
}

If we try to sort a list of Person objects using Arrays.sort() or Collections.sort(), we will encounter a compilation error because these methods do not know how to compare Person objects:

package tutorial;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;

public class CustomClassSorting {
    public static void main(String[] args) {
        List<Person> people = new ArrayList<>(Arrays.asList(
                new Person("Alice", 30, 65.5),
                new Person("Bob", 25, 75.0),
                new Person("Charlie", 35, 80.0)
        ));
        System.out.println("Original people list: " + people);

        Collections.sort(people);
        System.out.println("Sorted people list: " + people);
    }
}

Compilation Error:

java: no suitable method found for sort(java.util.List<tutorial.Person>)
    method java.util.Collections.<T>sort(java.util.List<T>) is not applicable
      (inference variable T has incompatible bounds
        equality constraints: tutorial.Person
        lower bounds: java.lang.Comparable<? super T>)
    method java.util.Collections.<T>sort(java.util.List<T>,java.util.Comparator<? super T>) is not applicable
      (cannot infer type-variable(s) T
        (actual and formal argument lists differ in length))

The error occurs because the Person class does not implement the Comparable interface, and there is no way for the sorting method to know how to compare two Person objects.

To sort custom objects like Person, we need to provide a way to compare these objects. Java offers two main approaches to achieve this:

Implementing the Comparable Interface: This allows a class to define its natural ordering by implementing the compareTo method.
Using the Comparator Interface: This allows us to create separate classes or lambda expressions to define multiple ways of comparing objects.

We will explore both approaches in the upcoming sections, starting with the Comparable interface.

Comparable Interface

Java provides a Comparable interface to define a natural ordering for objects of a user-defined class. By implementing the Comparable interface, a class can provide a single natural ordering that can be used to sort its instances. This is particularly useful when you need a default way to compare and sort objects.

Overview

The Comparable interface contains a single method, compareTo(), which compares the current object with the specified object for order. The method returns:

A negative integer if the current object is less than the specified object.
Zero if the current object is equal to the specified object.
A positive integer if the current object is greater than the specified object.

How Comparable Allows for a Single Natural Ordering of Objects

By implementing the Comparable interface, a class can ensure that its objects have a natural ordering. This allows the objects to be sorted using methods like Arrays.sort() or Collections.sort() without the need for a separate comparator.

Let's implement the Comparable interface in a new PersonV2 class, comparing by age.

package tutorial;

public class PersonV2 implements Comparable<PersonV2> {
    String name;
    int age;
    double weight;

    public PersonV2(String name, int age, double weight) {
        this.name = name;
        this.age = age;
        this.weight = weight;
    }

    @Override
    public String toString() {
        return "PersonV2 [name=" + name + ", age=" + age + ", weight=" + weight + " kgs]";
    }

    @Override
    public int compareTo(PersonV2 other) {
        return this.age - other.age;
    }
}

In this implementation, the compareTo() method compares the age attribute of the current PersonV2 object with the age attribute of the specified PersonV2 object by subtracting one age from the other. By using the expression this.age - other.age, we’re effectively implementing this logic as follows:

If this.age is less than other.age, the result will be negative.
If this.age is equal to other.age, the result will be zero.
If this.age is greater than other.age, the result will be positive.

Note: We can also use Integer.compare(this.age, other.age) instead of performing the arithmetic operation manually.

Now that the PersonV2 class implements the Comparable interface, we can sort a list of PersonV2 objects using Collections.sort():

package tutorial;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;

public class CustomClassSortingV2 {
    public static void main(String[] args) {
        List<PersonV2> people = new ArrayList<>(Arrays.asList(
                new PersonV2("Alice", 30, 65.5),
                new PersonV2("Bob", 25, 75.0),
                new PersonV2("Charlie", 35, 80.0)
        ));
        System.out.println("Original people list: " + people);

        Collections.sort(people);
        System.out.println("Sorted people list: " + people);
    }
}

Output:

Original people list: [PersonV2 [name=Alice, age=30, weight=65.5 kgs], PersonV2 [name=Bob, age=25, weight=75.0 kgs], PersonV2 [name=Charlie, age=35, weight=80.0 kgs]]
Sorted people list: [PersonV2 [name=Bob, age=25, weight=75.0 kgs], PersonV2 [name=Alice, age=30, weight=65.5 kgs], PersonV2 [name=Charlie, age=35, weight=80.0 kgs]]

In this example, the PersonV2 objects are sorted in ascending order of age using the Collections.sort() method, which relies on the natural ordering defined by the compareTo() method in the PersonV2 class.

Limitations of Comparable

While the Comparable interface provides a way to define a natural ordering for objects, it has several limitations that can restrict its use in practical applications. Understanding these limitations can help us determine when to use other mechanisms, such as the Comparator interface, to achieve more flexible sorting.

Single Natural Ordering: The primary limitation of Comparable is that it allows only one natural ordering for the objects of a class. When you implement Comparable, you define a single way to compare objects, which is used whenever the objects are sorted or compared. This can be restrictive if you need to sort objects in multiple ways.
Inflexibility: If you need to sort objects by different attributes or in different orders, you will have to modify the class or create new implementations of Comparable. This inflexibility can lead to a proliferation of comparison methods and can make the code harder to maintain.
Non-Adaptable: Once a class implements Comparable, the natural ordering is fixed and cannot be easily changed. For instance, if your PersonV2 class initially sorts by age but later you need to sort by weight or name, you have to either change the compareTo() method or create a new version of the class.

This is where the Comparator interface comes into play. To define multiple ways of comparing objects, we can use the Comparator interface, which we will explore in the next section.

Comparator Interface

The Comparator interface in Java provides a way to define multiple ways to compare and sort objects. Unlike the Comparable interface, which allows only a single natural ordering, Comparator is designed to offer flexibility by allowing multiple sorting strategies. This makes it particularly useful for scenarios where objects need to be sorted in different ways.

Overview

The Comparator interface defines a single method, compare(), which compares two objects and returns:

A negative integer if the first object is less than the second object.
Zero if the first object is equal to the second object.
A positive integer if the first object is greater than the second object.

This method provides a way to define custom ordering for objects without modifying the class itself.

How Comparator Allows for Multiple Ways of Ordering Objects

The Comparator interface allows you to create multiple Comparator instances, each defining a different ordering for objects. This flexibility means you can sort objects by various attributes or in different orders without altering the object's class.

Let's implement multiple Comparator instances for the Person class. We'll define comparators for sorting by name, by age, and by weight. First, we need to update the Person class to include getters and ensure that attributes are accessible.

package tutorial;

public class Person {
    String name;
    int age;
    double weight;

    public Person(String name, int age, double weight) {
        this.name = name;
        this.age = age;
        this.weight = weight;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

    public double getWeight() {
        return weight;
    }

    @Override
    public String toString() {
        return "Person [name=" + name + ", age=" + age + ", weight=" + weight + " kgs]";
    }
}

Comparator by Name

This comparator sorts Person objects alphabetically by their name.

package tutorial.comparator;

import tutorial.Person;

import java.util.Comparator;

public class PersonNameComparator implements Comparator<Person> {

    @Override
    public int compare(Person p1, Person p2) {
        return p1.getName().compareTo(p2.getName());
    }
}

Comparator by Age

This comparator sorts Person objects by their age, in ascending order.

package tutorial.comparator;

import tutorial.Person;

import java.util.Comparator;

public class PersonAgeComparator implements Comparator<Person> {

    @Override
    public int compare(Person p1, Person p2) {
        return p1.getAge() - p2.getAge();
    }
}

Comparator by Weight

This comparator sorts Person objects by their weight, in ascending order.

package tutorial.comparator;

import tutorial.Person;

import java.util.Comparator;

public class PersonWeightComparator implements Comparator<Person> {

    @Override
    public int compare(Person p1, Person p2) {
        return (int) (p1.getWeight() - p2.getWeight());
    }
}

Now, here’s how you can use these Comparator instances to sort a list of Person objects:

package tutorial;

import tutorial.comparator.PersonAgeComparator;
import tutorial.comparator.PersonNameComparator;
import tutorial.comparator.PersonWeightComparator;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;

public class CustomClassSortingV3 {
    public static void main(String[] args) {
        List<Person> people = new ArrayList<>(Arrays.asList(
                new Person("Alice", 30, 65.5),
                new Person("Bob", 25, 75.0),
                new Person("Charlie", 35, 80.0)
        ));
        System.out.println("Original people list: " + people);

        Collections.sort(people, new PersonNameComparator());
        System.out.println("Sorted people list by name: " + people);

        Collections.sort(people, new PersonAgeComparator());
        System.out.println("Sorted people list by age: " + people);

        Collections.sort(people, new PersonWeightComparator());
        System.out.println("Sorted people list by weight: " + people);
    }
}

Output:

Original people list: [Person [name=Alice, age=30, weight=65.5 kgs], Person [name=Bob, age=25, weight=75.0 kgs], Person [name=Charlie, age=35, weight=80.0 kgs]]
Sorted people list by name: [Person [name=Alice, age=30, weight=65.5 kgs], Person [name=Bob, age=25, weight=75.0 kgs], Person [name=Charlie, age=35, weight=80.0 kgs]]
Sorted people list by age: [Person [name=Bob, age=25, weight=75.0 kgs], Person [name=Alice, age=30, weight=65.5 kgs], Person [name=Charlie, age=35, weight=80.0 kgs]]
Sorted people list by weight: [Person [name=Alice, age=30, weight=65.5 kgs], Person [name=Bob, age=25, weight=75.0 kgs], Person [name=Charlie, age=35, weight=80.0 kgs]]

In this example, the Comparator instances allow sorting the Person objects by different attributes: name, age, and weight. This demonstrates how the Comparator interface enables flexible and versatile sorting strategies for a class.

Comparable vs Comparator

When sorting objects in Java, you have two primary options: the Comparable and Comparator interfaces. Understanding the differences between these two interfaces can help you choose the right approach for your needs. Please note that this is also a very important interview question.

Comparison

Here’s a table comparing and contrasting the Comparable and Comparator interfaces in Java:

Feature	Comparable	Comparator
Definition	Provides a single, natural ordering for objects	Provides multiple ways to compare objects
Method	compareTo(T o)	compare(T o1, T o2)
Implementation	Implemented within the class itself	Implemented outside the class
Sorting Criteria	One default natural ordering	Multiple sorting criteria
Flexibility	Limited to one way of comparing objects	Flexible; multiple comparators can be defined
Class Modification	Requires modifying the class to implement `Comparable`	Does not require modifying the class
Use Case	Use when there is a clear, natural ordering (e.g., sorting employees by ID)	Use when different sorting orders are needed or when you cannot modify the class

Benefits and Drawbacks of Each Approach

Comparable

Benefits:
- Simplicity: Provides a default sorting order that is easy to implement and use.
- Built-in: The natural ordering is part of the class itself, so it is always available and used by default in sorting methods.
Drawbacks:
- Single Ordering: Can only define one way to compare objects. If different sorting orders are needed, the class must be modified or additional Comparator instances must be used.
- Class Modification: Requires altering the class to implement Comparable, which might not be feasible if the class is part of a library or if its natural ordering is not clear.

Comparator

Benefits:
- Flexibility: Allows for multiple sorting orders and criteria, which can be defined externally and used as needed.
- Non-invasive: Does not require modification of the class itself, making it suitable for classes you do not control or when you need different sorting options.
Drawbacks:
- Complexity: Requires creating and managing multiple Comparator instances, which can add complexity to the code.
- Overhead: Might introduce additional overhead if many comparators are used, especially if they are created on the fly.

In summary, Comparable is best used when a class has a natural ordering that makes sense for most use cases. Comparator, on the other hand, provides flexibility for sorting by multiple criteria and is useful when the class does not have a natural ordering or when different sorting orders are needed. Choosing between Comparable and Comparator depends on your specific sorting needs and whether you need a single default order or multiple flexible sorting options.

Wrapping Up

Understanding and utilizing both Comparable and Comparator can significantly enhance your ability to manage and manipulate object collections in Java. By applying these concepts, you can create more flexible and powerful sorting mechanisms.

To solidify your understanding, try implementing both Comparable and Comparator in real-world scenarios. Experiment with different classes and sorting criteria to see how each approach works in practice.

Links to Official Java Documentation:

Python One-Liners - Code Hacks You Should Know

Ashutosh Krishna — Thu, 30 Nov 2023 02:16:37 +0000

Python's beauty lies in its simplicity and readability. And mastering the art of writing concise yet powerful code can significantly enhance your productivity as a developer. I'm talking about really short lines of code that do big things.

In this article, we'll explore 8 essential Python one-liners that every Pythonista should have in their toolkit. From list comprehensions to lambda functions and beyond, these techniques offer elegant solutions to common programming challenges, helping you write cleaner, more efficient code.

List Comprehension

List comprehension is a Pythonic way to create lists with a single line of code. It offers a concise alternative to traditional loops, enabling you to generate lists quickly and efficiently.

Let's say you want to create a list containing squares of numbers from 0 to 9. Using a traditional loop, you'd do it like this:

# Using a traditional loop
squared_numbers = []
for i in range(10):
    squared_numbers.append(i ** 2)
print(squared_numbers)

The traditional loop method requires more lines of code and explicitly defines the iteration process, appending each squared number to the list step by step.

On the other hand, list comprehension can achieve the same result in a single line, making the code more concise and readable. It condenses the loop into a clear, compact structure, generating the squared numbers directly into a list.

# Using list comprehension
squared_numbers = [i ** 2 for i in range(10)]
print(squared_numbers)

You can use list comprehensions when you need to apply a simple operation to every element in a sequence, such as transforming a list of numbers or strings.

You can learn how you can pack and destructure lists in Python here.

Lambda Functions

Lambda functions, also known as anonymous functions, allow you to create small, throwaway functions without explicitly defining them with def. They are particularly useful in scenarios where a function is needed for a short operation.

First, let's look at an example using def:

# Using def
def add_numbers(x, y):
    return x + y

print(add_numbers(2, 3))

In this code, the def keyword is used to define a named function add_numbers explicitly. It takes an argument x and y and returns the sum of them. This traditional approach provides a named function that can be called multiple times.

But when you need a function just for one-time usage, you can just define an anonymous function using the lambda keyword like this:

# Using Lambda
add = lambda x, y: x + y
print(add(2, 3))

It achieves the same result as add_numbers but in a single line without assigning a name explicitly. Lambda functions are useful for short, throwaway functions that are used infrequently or as part of other expressions.

Map and Filter

The map and filter functions are powerful tools for working with iterables, allowing concise manipulation and filtering of data.

Let's say you have a list of strings and you want to convert each item of the list into uppercase.

fruits = ['apple', 'banana', 'cherry']
upper_case_loop = []
for fruit in fruits:
    upper_case_loop.append(fruit.upper())
print(upper_case_loop)

Now, you can achieve the same using the map function:

upper_case = list(map(lambda x: x.upper(), ['apple', 'banana', 'cherry']))

You can utilize map when you need to perform an operation on every element of an iterable. filter is handy for selectively choosing elements based on a condition.

You can learn more about the map, filter and reduce functions here.

Ternary Operator

The ternary operator provides a condensed way to write conditional statements in a single line, enhancing code readability.

Let's say, you have a number and you want to check if it's even or odd. You can do it using the traditional if condition as below:

# Traditional if
result = None
num = 5
if num % 2 == 0:
    result = "Even"
else:
    result = "Odd"

But you can achieve the same results in a single line using the ternary operator:

# Ternary Operator
num = 7
result = "Even" if num % 2 == 0 else "Odd"

When you need to assign values based on conditions, especially in situations requiring simple if-else checks, the ternary operator shines.

Zip Function

The zip function enables you to combine multiple iterables element-wise, forming tuples of corresponding elements.

Let's assume you have two lists: one containing the names of students and the other containing their respective grades for a specific assignment.

students = ['Dilli', 'Vikram', 'Rolex', 'Leo']
grades = [85, 92, 78, 88]

Now, you want to create a report that pairs each student's name with their grade for easy comprehension or further analysis. You can do it by iterating over the list and appending them to a new list as below:

students = ['Dilli', 'Vikram', 'Rolex', 'Leo']
grades = [85, 92, 78, 88]

student_grade_pairs = []
for i in range(len(students)):
    student_grade_pairs.append((students[i], grades[i]))

print(student_grade_pairs)

The above loop method manually pairs elements from two lists by iterating through their indices, accessing elements at the same positions, and appending tuples of those elements into a new list student_grade_pairs.

But, what if I tell you that we can achieve the same pairing effect in one line using the zip function as below:

students = ['Dilli', 'Vikram', 'Rolex', 'Leo']
grades = [85, 92, 78, 88]

student_grade_pairs = list(zip(students, grades))
print(student_grade_pairs)

The zip function elegantly combines elements from both lists, creating pairs of corresponding elements as tuples. The result student_grade_pairs is a list of tuples, where each tuple contains an element from the grades list paired with the corresponding element from the students list.

You can learn more about the zip function here.

Enumerate Function

The enumerate function offers a concise way to iterate over a sequence while keeping track of the index.

Let's say you're developing a feature where users can add items to their shopping list, and you want to display the items along with their position or index in the list for easy reference.

You can do it using a traditional for-loop as below:

# Simulating a grocery list
grocery_list = ['Apples', 'Milk', 'Bread', 'Eggs', 'Cheese']

# Displaying the grocery list with indices
for i in range(len(grocery_list)):
    print(f"{i}. {grocery_list[i]}")

The traditional loop with manual indexing involves using range along with len to generate indices that are then used to access elements in the grocery_list list. This method requires more code and is less readable due to the explicit handling of indices.

The enumerate function simplifies the process by directly providing both indices and elements from the grocery_list list.

# Simulating a grocery list
grocery_list = ['Apples', 'Milk', 'Bread', 'Eggs', 'Cheese']

# Displaying the grocery list with indices
for index, item in enumerate(grocery_list):
    print(f"{index}. {item}")

It's concise, readable, and more Pythonic, eliminating the need for manual index handling and making the code cleaner. This approach is generally preferred for its simplicity and clarity in obtaining indices and elements from an iterable.

String Join

The join method is a clean way to concatenate strings from an iterable into a single string.

Suppose you have a list of words and want to create a sentence by joining these words using traditional concatenation. You'd do it as below:

# Using traditional concatenation
words = ['Python', 'is', 'awesome', 'and', 'powerful']

sentence = ''
for word in words:
    sentence += word + ' '

print(sentence.strip()) # Strip to remove the trailing space

In the traditional concatenation method, a loop iterates through the list of words, and each word is concatenated with a space. However, this approach requires creating a new string for each concatenation operation, which might not be efficient for larger strings due to string immutability.

The join method, on the other hand, is more efficient and concise. It joins the elements of the list using the specified separator (in this case, a space), creating the sentence in a single operation.

.# Using join method
words = ['Python', 'is', 'awesome', 'and', 'powerful']

sentence = ' '.join(words)
print(sentence)

This method is generally the preferred way to join strings in Python due to its efficiency and readability.

Unpacking Lists

Python's unpacking feature allows for efficient assignment of elements from iterables to variables.

Suppose you have a list of numbers, and you want to assign each number to separate variables using traditional indexing.

# Using traditional unpacking
numbers = [1, 2, 3]

a = numbers[0]
b = numbers[1]
c = numbers[2]

print(a, b, c)

In the traditional unpacking method, individual elements from the list are accessed and assigned to separate variables by explicitly indexing each element. This method is more verbose and requires knowing the number of elements in advance.

Now, let's accomplish the same using the * operator for unpacking the list into variables.

# Using * operator for unpacking
numbers = [1, 2, 3]

a, b, c = numbers

print(a, b, c)

You can learn more about the * operator and list unpacking in this tutorial.

Should You Always Use One-Liners?

While Python one-liners offer conciseness and elegance, there are considerations to keep in mind before applying them universally:

Readability : One-liners might sacrifice readability for crispness. Complex one-liners can be hard to understand, especially for newcomers or when revisiting code after some time.
Maintainability : Overusing one-liners, especially complex ones, can make code maintenance challenging. Debugging and modifying concise code might be more difficult.
Performance : In certain scenarios, one-liners might not be the most performant solution. These concise expressions may consume more resources, such as memory or CPU, and their underlying operations might have higher time complexity, affecting efficiency, especially with large datasets or intensive computations.
Debugging : Debugging a one-liner can be more challenging due to its compactness. Identifying issues or errors might take longer compared to well-structured, multiple-line code.
Context : Not all situations warrant one-liners. Sometimes, a straightforward, explicit approach might be more suitable for code clarity, especially when working in teams.

Ultimately, the decision to use one-liners should consider the trade-offs between conciseness and readability. Strive for a balance that enhances code clarity without compromising maintainability and understanding, especially when collaborating or working on larger projects.

Wrapping Up

Mastering Python's concise techniques like list comprehensions, lambda functions, enumerate, join, zip, and unpacking with the * operator can significantly enhance code readability, efficiency, and simplicity. These methods offer elegant solutions to common programming challenges, reducing verbosity and improving code maintainability.

Understanding when and how to use these Pythonic constructs empowers developers to write cleaner, more expressive code and enhance overall productivity in various programming scenarios.

A Beginner's Guide to Strategy Design Pattern

Ashutosh Krishna — Mon, 01 May 2023 08:36:13 +0000

Introduction

The Strategy Design Pattern is a behavioral design pattern that allows you to dynamically change the behavior of an object by encapsulating it into different strategies. This pattern enables an object to choose from multiple algorithms and behaviors at runtime, rather than statically choosing a single one.

It is based on the principle of composition over inheritance. It defines a family of algorithms, encapsulates each one, and makes them interchangeable at runtime. The core idea behind this pattern is to separate the algorithms from the main object, allowing the object to delegate the algorithm's behavior to one of its contained strategies.

In simpler terms, the Strategy Design Pattern provides a way to extract the behavior of an object into separate classes that can be swapped in and out at runtime. This enables the object to be more flexible and reusable, as different strategies can be easily added or modified without changing the object's core code.

Benefits of using the Strategy Design Pattern

Using the Strategy Design Pattern can provide several benefits, including:

Improved code flexibility : By encapsulating the behavior of an object into different strategies, the code becomes more flexible and easier to modify.
Better code reusability : Since the strategies are encapsulated and interchangeable, they can be reused across different objects and projects.
Encourages better coding practices : This pattern promotes good coding practices, such as separating concerns and reducing code complexity.
Simplifies testing : By separating the algorithms and behaviors from the object, testing becomes more straightforward.

Use cases for the Strategy Design Pattern

The Strategy Design Pattern can be useful in various scenarios, such as:

Sorting algorithms : Different sorting algorithms can be encapsulated into separate strategies and passed to an object that needs sorting.
Validation rules : Different validation rules can be encapsulated into separate strategies and passed to an object that needs validation.
Text formatting : Different formatting strategies can be encapsulated into separate strategies and passed to an object that needs formatting.
Database access : Different database access strategies can be encapsulated into separate strategies and passed to an object that needs to access data from different sources.
Payment strategy : Different payment methods can be encapsulated into separate strategies and passed to an object that needs to process payments.

Understanding the Strategy Design Pattern

The Strategy Design Pattern is a powerful pattern in the world of object-oriented programming. It provides a flexible way to encapsulate and swap the behavior of an object at runtime, enabling code to be more adaptable and easier to maintain. In this section, we will dive deeper into the Strategy Design Pattern, discussing its definition, components, and how it works.

Components of the Strategy Design Pattern

The Strategy Design Pattern consists of three primary components:

Context : The object that will delegate its behavior to one of the contained strategies. The context maintains a reference to a strategy object and interacts with it through a common interface.
Strategy Interface : The interface that defines the behavior for all strategies. The strategies implement this interface to provide their unique implementation of the behavior.
Concrete Strategies : The classes that implement the Strategy Interface. Each strategy encapsulates a specific behavior that the context can switch to at runtime.

How the Strategy Design Pattern Works

The Strategy Design Pattern works by separating the behavior of an object from the object itself. The behavior is encapsulated into different strategies, each with its own implementation of the behavior. The context maintains a reference to a strategy object and interacts with it through a common interface. At runtime, the context can swap the current strategy with another one, effectively changing the object's behavior.

Examples of the Strategy Design Pattern in action

One example of the Strategy Design Pattern in action is in a music streaming service where different subscription tiers have different pricing models. Each subscription tier could have a different pricing strategy that encapsulates its unique pricing logic. The service's billing system would delegate the pricing calculation to the current subscription's strategy, allowing for easy modification and extension of the pricing logic.

Another example is the payment strategy. Different payment methods can be encapsulated into separate strategies, each with its own unique processing logic. A shopping cart application may use the Strategy Design Pattern to encapsulate credit card, PayPal, and cryptocurrency payment methods into separate strategies that can be swapped at runtime. The application's payment processing system would delegate the payment processing logic to the current payment method's strategy, allowing for easy modification and extension of the payment processing logic.

Implementing the Strategy Design Pattern

In this section, we will discuss how to implement the Strategy Design Pattern. We will start with a code example that violates the Strategy Design Pattern and explain the problems with it. Then, we will refactor the code to demonstrate how to implement the Strategy Design Pattern.

To implement the Strategy Design Pattern in Java, follow these steps:

Identify the algorithm or behavior that needs to be encapsulated and made interchangeable.
Define an interface that represents the behavior, with a single method signature that takes in any required parameters.
Implement concrete classes that provide specific implementations of the behavior defined in the interface.
Define a context class that holds a reference to the interface and calls its method when needed.
Modify the context class to allow for the dynamic swapping of the concrete implementations at runtime.

Code Example

Let's consider the following code example:

package withoutstrategy;

public class PaymentProcessor {
    private PaymentType paymentType;

    public void processPayment(double amount) {
        if (paymentType == PaymentType.CREDIT_CARD) {
            System.out.println("Processing credit card payment of amount " + amount);
        } else if (paymentType == PaymentType.DEBIT_CARD) {
            System.out.println("Processing debit card payment of amount " + amount);
        } else if (paymentType == PaymentType.PAYPAL) {
            System.out.println("Processing PayPal payment of amount " + amount);
        } else {
            throw new IllegalArgumentException("Invalid payment type");
        }
    }

    public void setPaymentType(PaymentType paymentType) {
        this.paymentType = paymentType;
    }
}

enum PaymentType {
    CREDIT_CARD,
    DEBIT_CARD,
    PAYPAL
}

In this code, the PaymentProcessor class has a processPayment method that takes a payment amount and processes the payment. The payment type is set using the setPaymentType method, which sets the paymentType field. The processPayment method then checks the value of paymentType and processes the payment accordingly.

The problem with this code is that it violates the Open-Closed Principle, which states that classes should be open for extension but closed for modification. In this code, if you want to add a new payment type, you would have to modify the processPayment method, which violates the Open-Closed Principle.

The PaymentProcessor class violates the Strategy pattern by using conditional statements to determine the type of payment and then processing it accordingly. This approach can quickly become unmanageable and inflexible as the number of payment types increases.

To fix this problem, you can use the Strategy Design Pattern. First, you define a common interface for all payment strategies, which in this case is the PaymentStrategy interface:

package withstrategy;

public interface PaymentStrategy {
    void processPayment(double amount);
}

You then define concrete implementations of the PaymentStrategy interface for each payment type. For example, here are the CreditCardPaymentStrategy, DebitCardPaymentStrategy, and PaypalPaymentStrategy classes:

package withstrategy;

public class CreditCardPaymentStrategy implements PaymentStrategy {
    public void processPayment(double amount) {
        System.out.println("Processing credit card payment of amount " + amount);
    }
}

package withstrategy;

public class DebitCardPaymentStrategy implements PaymentStrategy {
    public void processPayment(double amount) {
        System.out.println("Processing debit card payment of amount " + amount);
    }
}

package withstrategy;

public class PaypalPaymentStrategy implements PaymentStrategy {
    public void processPayment(double amount) {
        System.out.println("Processing PayPal payment of amount " + amount);
    }
}

Finally, you update the PaymentProcessor class to take a PaymentStrategy object in its constructor, which it uses to process the payment:

package withstrategy;

public class PaymentProcessor {
    private PaymentStrategy paymentStrategy;

    public PaymentProcessor(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }

    public void processPayment(double amount) {
        paymentStrategy.processPayment(amount);
    }
}

This implementation follows the Open-Closed Principle as well as Strategy Pattern because you can add new payment types by creating new implementations of the PaymentStrategy interface without modifying the existing code.

Best practices for implementing the Strategy Design Pattern

Here are a few best practices to keep in mind when implementing the Strategy Design Pattern:

Keep the interface simple and focused on a single responsibility.
Encapsulate any stateful behavior in the concrete strategy classes, rather than in the context class.
Use dependency injection to pass the concrete strategy to the context class, rather than creating it directly in the context class.
Use an enum or a factory class to provide a centralized place for creating and managing concrete strategy objects.

Real-world Applications of the Strategy Design Pattern

The Strategy Design Pattern has been used extensively in various real-world applications. One such example is the Java Collections Framework. The Collections Framework provides a set of interfaces and classes to represent collections of objects, such as lists, sets, and maps. The framework allows different strategies to be applied to collections based on their behavior.

For instance, the Collections Framework includes a sort() method that allows the sorting of collections. The sort() method takes a Comparator object as an argument, which is responsible for comparing objects within the collection. The Comparator interface defines a strategy for comparing two objects, and the sort() method uses this strategy to sort the collection.

In addition, the Collections Framework also includes the Iterator interface, which defines a strategy for accessing elements of a collection. The Iterator allows the user to traverse the collection without exposing its internal structure, which can change over time. By using the Iterator interface, the user can switch between different strategies for accessing elements of the collection.

Wrapping Up

In this tutorial, we have explored the Strategy Design Pattern and its implementation in Java. We have seen how the Strategy pattern can be used to separate the behavior of an object from its implementation, providing greater flexibility and maintainability in code.

We discussed the components of the Strategy Design Pattern, including the Context, Strategy Interface, and Concrete Strategies. We also provided an example of how the pattern can be used to implement a payment system, allowing for multiple payment options to be implemented using a single interface.

By separating the behavior of an object from its implementation, the Strategy pattern provides greater flexibility and adaptability to changing requirements.

Additional Resources

Design Patterns: A Comprehensive Tutorial

Ashutosh Krishna — Mon, 01 May 2023 07:17:30 +0000

Introduction

Design patterns are proven solutions to commonly occurring software design problems. In other words, they are reusable templates that help to solve recurring design problems in software development. Design patterns were first introduced in the book Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of Four (Gamma, Helm, Johnson, and Vlissides) in 1994.

Design patterns are essential in software development because they provide a common language and framework for communicating design ideas and solutions. They help developers to design robust, flexible, and maintainable software systems. Using design patterns ensures that the software is more reusable, testable, and scalable. Design patterns also promote code reuse and reduce the likelihood of errors and bugs in the software.

In this tutorial, we will explore different types of design patterns, their importance, and the benefits of using them in software development. We will also discuss how to choose the right design pattern for a particular situation and provide examples of design patterns used in real-world applications.

Types of Design Patterns

Design patterns are categorized into three main categories: Creational , Structural , and Behavioral patterns.

Creational Design Patterns

Creational patterns are concerned with object creation mechanisms, trying to create objects in a manner suitable to the situation. There are five types of creational patterns:

Abstract Factory Pattern : Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
Builder Pattern : Separates the construction of a complex object from its representation, allowing the same construction process to create various representations.
Factory Method Pattern : Defines an interface for creating an object, but lets subclasses decide which class to instantiate.
Object Pool Pattern : Reuses and shares objects that are expensive to create.
Prototype Pattern : Creates new objects by copying an existing object, which serves as a prototype.
Singleton Pattern : Ensures that a class has only one instance, and provides a global point of access to it.

Structural Design Patterns

Structural patterns deal with object composition to form larger structures and provide ways to realize relationships between objects. There are seven types of structural patterns:

Adapter Pattern : Allows objects with incompatible interfaces to work together by creating an intermediary object that translates one interface to another.
Bridge Pattern : Decouples an abstraction from its implementation so that the two can vary independently.
Composite Pattern : Composes objects into tree structures to represent whole-part hierarchies.
Decorator Pattern : Dynamically adds responsibilities to an object by wrapping it in an object of a decorator class.
Facade Pattern : Provides a unified interface to a set of interfaces in a subsystem, simplifying the interaction between the client and the subsystem.
Flyweight Pattern : Uses sharing to support large numbers of fine-grained objects efficiently.
Private Class Data Pattern : Restricts access to an object's data by encapsulating it within a separate object.
Proxy Pattern : Provides a surrogate or placeholder for another object to control access to it.

Behavioral Design Patterns

Behavioral patterns deal with communication between objects, focusing on how objects collaborate and fulfill responsibilities. There are eleven types of behavioral patterns:

Chain of Responsibility Pattern : Avoids coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.
Command Pattern : Encapsulates a request as an object, allowing you to parameterize clients with different requests, queue or log requests, and support undoable operations.
Interpreter Pattern : Defines a grammatical representation of a language and provides an interpreter to parse sentences in the language.
Iterator Pattern : Provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
Mediator Pattern : Defines an object that encapsulates how a set of objects interact, promoting loose coupling by keeping objects from referring to each other explicitly.
Memento Pattern : Captures and externalizes an object's internal state so that it can be restored later, without violating encapsulation.
Null Object Pattern : Provides a default value for an object, which can be used to avoid null checks in client code
Observer Pattern : Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
State Pattern : Allows an object to alter its behavior when its internal state changes so that it appears to change its class.
Strategy Pattern : Defines a family of algorithms, encapsulates each one and makes them interchangeable.
Template Method Pattern : Defines the skeleton of an algorithm in a method, deferring some steps to subclasses.
Visitor Pattern : Separates an algorithm from an object structure by moving the hierarchy of methods into one object.

Choosing the Right Design Pattern

Choosing the right design pattern for a particular situation requires a good understanding of the problem at hand and the available design patterns. It's important to choose a pattern that fits the problem, rather than trying to fit the problem into a preconceived pattern. When choosing a design pattern, there are several factors to consider, including:

Complexity : Consider the complexity of the problem and the proposed solution. Some patterns are simple and can be implemented quickly, while others are more complex and may require more time and resources.
Flexibility : Consider the flexibility of the pattern and how well it will adapt to changes in the problem or requirements. Some patterns are more flexible than others and may be better suited to situations where requirements are likely to change.
Reusability : Consider the reusability of the pattern and how it can be applied to other problems. Some patterns are more reusable than others and may be better suited to situations where similar problems are likely to occur.
Familiarity : Consider the familiarity of the pattern and whether it is well-known and widely used. Choosing a well-known pattern can make it easier for other developers to understand and maintain the code.

Examples of when to use certain design patterns include:

Use the Singleton pattern when you need to ensure that only one instance of a class exists and it needs to be globally accessible.
Use the Factory Method pattern when you need to create objects without specifying the exact class of object that will be created.
Use the Observer pattern when you need to notify a set of objects about changes to another object.
Use the Strategy pattern when you need to dynamically change the behavior of an object at runtime.
Use the Adapter pattern when you need to adapt the interface of an existing class to meet the needs of a new interface.

In summary, choosing the right design pattern requires careful consideration of the problem and the available patterns, taking into account factors such as complexity, flexibility, reusability, and familiarity. Choosing the right pattern can help simplify the code and make it easier to maintain over time.

Wrapping Up

In this tutorial, we have covered the basics of design patterns, including the different types of patterns, how to choose the right pattern for a particular situation, and examples of when to use certain patterns.

Key points to remember include the importance of understanding the problem at hand before choosing a design pattern, the need to consider factors such as complexity, flexibility, reusability, and familiarity when choosing a pattern, and the importance of using patterns to simplify code and make it easier to maintain.

Overall, design patterns are an essential tool in any developer's toolkit. By using patterns effectively, developers can build more robust, maintainable, and scalable software systems that meet the needs of users and businesses alike. We recommend that developers continue to learn and explore design patterns to improve their skills and knowledge of software development.

How To Download YouTube Playlist Using Python

Ashutosh Krishna — Sun, 30 Apr 2023 17:54:24 +0000

YouTube is the world's largest video-sharing platform with millions of videos uploaded every day. Many times you come across a playlist of videos on YouTube that you want to watch offline or save for future reference. However, downloading a single video from YouTube is easy, but when it comes to downloading an entire playlist, it can be a daunting task. In such cases, automating the process using Python can save a lot of time and effort.

In this tutorial, you will be using the Pytube library in Python to download entire YouTube playlists in various resolutions, including the high-quality 2160p resolution. Pytube is a lightweight library that allows easy access to YouTube videos and metadata. With Pytube, we can easily extract video URLs, download videos, and even extract audio from videos. So, let's dive into the tutorial and learn how to download a YouTube playlist using Python.

If you're in a hurry, jump to the GitHub gist to get the code immediately.

Prerequisites

To follow this tutorial, you should have a basic understanding of Python programming language, including installing Python packages using pip.

You will also need to install the Pytube library, which can be installed using pip. Open a command prompt or terminal window and type the following command:

pip install pytube

Apart from Python and Pytube, you will also need to have FFmpeg installed on your system. FFmpeg is a command-line tool used for handling multimedia files. It is required for Pytube to be able to download videos in various resolutions. You can download FFmpeg from the official website and follow the installation instructions for your operating system.

Let's Code It!

Roll up your sleeves, fire up your favorite code editor, and let's get started!

Import the Libraries

Let's import the necessary libraries for the program to run correctly.

import os
import re
from pytube import Playlist, YouTube

The code imports the os module to handle operating system functionalities, re module to handle regular expressions, and pytube module to download the YouTube playlist.

Create the Function

Let's define a function called download_playlist. The function takes two parameters; the playlist URL and the desired video resolution.

def download_playlist(playlist_url, resolution):
    playlist = Playlist(playlist_url)
    playlist_name = re.sub(r'\W+', '-', playlist.title)

    if not os.path.exists(playlist_name):
        os.mkdir(playlist_name)

It first creates a new Playlist object using the Pytube library and extracts the name of the playlist. It then checks if a folder with the same name exists in the current working directory. If not, it creates a new folder with the playlist name.

Note that the re.sub() function replaces any non-alphanumeric characters in the playlist title with a hyphen ("-") character. We do so because folder and file names in most file systems have restrictions on the characters they can contain.

Downloading the Videos

The Playlist object provides a videos property which is an iterable of YouTube objects. You first iterate through the list of videos in the playlist using a for loop and enumerate function.:

for index, v in enumerate(playlist.videos, start=1):
    ...

The start parameter set to 1 to start counting from 1 instead of 0 because you're going to use the index in the filenames. Thus it makes sense to start from 1.

Next, create a YouTube object for each video using its watch URL, and specify to use OAuth for authentication:

for index, v in enumerate(playlist.videos, start=1):
    video = YouTube(v.watch_url, use_oauth=True)

Recently, there were several issues where PyTube was throwing a KeyError. The fix was to use the use_oauth=True parameter. When you run the code for the first time, it will ask you to login into your YouTube account.

Filter the available video streams to select the one with the desired resolution, and get its filename:

for index, v in enumerate(playlist.videos, start=1):
    video = YouTube(v.watch_url, use_oauth=True)
    video_resolution = video.streams.filter(res=resolution).first()
    video_filename = f"{index}. {video_resolution.default_filename}"

Determine the full path and filename for the video file, and check if it already exists. If it does, skip downloading this video and move on to the next one:

for index, v in enumerate(playlist.videos, start=1):
    video = YouTube(v.watch_url, use_oauth=True)
    video_resolution = video.streams.filter(res=resolution).first()
    video_filename = f"{index}. {video_resolution.default_filename}"
    video_path = os.path.join(playlist_name, video_filename)
    if os.path.exists(video_path):
        print(f"{video_filename} already exists")
        continue

If the desired resolution is not available, download the video with the highest resolution instead:

for index, v in enumerate(playlist.videos, start=1):
    ...
    video_streams = video.streams.filter(res=resolution)

    if not video_streams:
        highest_resolution_stream = video.streams.get_highest_resolution()
        video_name = highest_resolution_stream.default_filename
        print(f"Downloading {video_name} in {highest_resolution_stream.resolution}")
        highest_resolution_stream.download(filename=video_path)

If the desired resolution is available, you don't have to download it directly. If you do so, the downloaded video won't have sound. Instead, download both the video and audio streams separately, and merge them using the FFmpeg library to create the final video file. Finally, rename the merged file and delete the temporary video and audio files:

for index, v in enumerate(playlist.videos, start=1):
    ...
    video_streams = video.streams.filter(res=resolution)

    if not video_streams:
        ...
    else:
        video_stream = video_streams.first()
        video_name = video_stream.default_filename
        print(f"Downloading video for {video_name} in {resolution}")
        video_stream.download(filename="video.mp4")

        audio_stream = video.streams.get_audio_only()
        print(f"Downloading audio for {video_name}")
        audio_stream.download(filename="audio.mp4")

        os.system("ffmpeg -y -i video.mp4 -i audio.mp4 -c:v copy -c:a aac final.mp4 -loglevel quiet -stats")
        os.rename("final.mp4", video_path)
        os.remove("video.mp4")
        os.remove("audio.mp4")

The video stream is initially downloaded as video.mp4 and the audio stream is downloaded as audio.mp4. Next, the ffmpeg command takes two input files (video.mp4 and audio.mp4), copies the video codec from the input file and uses the AAC codec for audio, and saves the output as final.mp4. The output file is created by merging the video and audio streams from the two input files.

After ffmpeg finishes processing, the final.mp4 is renamed video_path and the video and audio stream files are deleted.

The `download_playlist` Function

At this point, you have completed the download_playlist function. It should look like this:

def download_playlist(playlist_url, resolution):
    playlist = Playlist(playlist_url)
    playlist_name = re.sub(r'\W+', '-', playlist.title)

    if not os.path.exists(playlist_name):
        os.mkdir(playlist_name)

    for index, v in enumerate(playlist.videos, start=1):
        video = YouTube(v.watch_url, use_oauth=True)
        video_resolution = video.streams.filter(res=resolution).first()
        video_filename = f"{index}. {video_resolution.default_filename}"
        video_path = os.path.join(playlist_name, video_filename)
        if os.path.exists(video_path):
            print(f"{video_filename} already exists")
            continue

        video_streams = video.streams.filter(res=resolution)

        if not video_streams:
            highest_resolution_stream = video.streams.get_highest_resolution()
            video_name = highest_resolution_stream.default_filename
            print(f"Downloading {video_name} in {highest_resolution_stream.resolution}")
            highest_resolution_stream.download(filename=video_path)

        else:
            video_stream = video_streams.first()
            video_name = video_stream.default_filename
            print(f"Downloading video for {video_name} in {resolution}")
            video_stream.download(filename="video.mp4")

            audio_stream = video.streams.get_audio_only()
            print(f"Downloading audio for {video_name}")
            audio_stream.download(filename="audio.mp4")

            os.system("ffmpeg -y -i video.mp4 -i audio.mp4 -c:v copy -c:a aac final.mp4 -loglevel quiet -stats")
            os.rename("final.mp4", video_path)
            os.remove("video.mp4")
            os.remove("audio.mp4")

        print("----------------------------------")

A line of dashes is also printed after every iteration to separate each video as they are downloaded.

Main Function

Let's create the main function that takes input from the user for the playlist URL and desired video resolution. It then calls the download_playlist function with the user's inputs.

if __name__ == " __main__":
    playlist_url = input("Enter the playlist url: ")
    resolutions = ["240p", "360p", "480p", "720p", "1080p", "1440p", "2160p"]
    resolution = input(f"Please select a resolution {resolutions}: ")
    download_playlist(playlist_url, resolution)

Completed Code

Conclusion

In this tutorial, you learned how you can use PyTube and FFmpeg libraries to download videos from a YouTube playlist in high resolutions such as 1080p, 1440p, and even 2160p.

I hope you found the tutorial helpful. If so, don't forget to star the GitHub gist and share this tutorial with others.

The code has been tested with Pytube 12.1.3. It may not work properly at a later point in time.

SOLID Principles for Better Software Design

Ashutosh Krishna — Sat, 29 Apr 2023 19:27:04 +0000

SOLID principles are a set of guidelines for writing high-quality, maintainable, and scalable software. They were introduced by Robert C. Martin, a renowned software engineer, and consultant, in his 2000 paper Design Principles and Design Patterns to help developers write software that is easy to understand, modify, and extend. These concepts were later built upon by Michael Feathers, who introduced us to the SOLID acronym.

The SOLID acronym stands for:

Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

These principles provide a way for developers to organize their code and create software that is flexible, easy to change, and testable. Applying SOLID principles can lead to code that is more modular, maintainable, and extensible, and it can make it easier for developers to work collaboratively on a codebase.

In this tutorial, we will explore each of the SOLID principles in detail, explain why they are important, and provide examples of how they can be applied in practice. By the end of this tutorial, you should have a good understanding of the SOLID principles and how to apply them to your software development projects.

Single Responsibility Principle

The Single Responsibility Principle (SRP) states that a class should have only one reason to change , or in other words, it should have only one responsibility. This means that a class should have only one job to do, and it should do it well.

If a class has too many responsibilities, it can become hard to understand, maintain, and modify. Changes to one responsibility can inadvertently affect another responsibility, leading to unintended consequences and bugs. By following SRP, we can create code that is more modular, easier to understand, and less prone to errors.

Let's take an example that violates the SRP:

class Marker {
    String name;
    String color;
    int price;

    public Marker(String name, String color, int price) {
        this.name = name;
        this.color = color;
        this.price = price;
    }
}

The above code defines a simple Marker class having three instance variables - name, color and price.

class Invoice {
    private Marker marker;
    private int quantity;

    public Invoice(Marker marker, int quantity) {
        this.marker = marker;
        this.quantity = quantity;
    }

    public int calculateTotal() {
        return marker.price * this.quantity;
    }

    public void printInvoice() {
        // printing implementation
    }

    public void saveToDb() {
        // save to database implementation
    }
}

The above Invoice class violates SRP because it has multiple responsibilities - it is responsible for calculating the total amount, printing the invoice, and saving the invoice to the database. As a result, if the calculation logic changes, such as the addition of taxes, the calculateTotal() method would require modification. Similarly, if the printing or database-saving implementation changes at any point, the class would need to be changed. Therefore, there are several reasons for the class to be modified, which could lead to increased maintenance costs and complexity.

Here's how you can modify the code to follow SRP:

class Invoice {
    private Marker marker;
    private int quantity;

    public Invoice(Marker marker, int quantity) {
        this.marker = marker;
        this.quantity = quantity;
    }

    public int calculateTotal() {
        return marker.price * this.quantity;
    }
}


class InvoiceDao {
    private Invoice invoice;

    public InvoiceDao(Invoice invoice) {
        this.invoice = invoice;
    }

    public void saveToDb() {
        // save to database implementation
    }
}


class InvoicePrinter {
    private Invoice invoice;

    public InvoicePrinter(Invoice invoice) {
        this.invoice = invoice;
    }

    public void printInvoice() {
        // printing implementation
    }
}

In this refactored example, we have split the responsibilities of the Invoice class into three separate classes - Invoice, InvoiceDao, and InvoicePrinter. The Invoice class is responsible only for calculating the total amount, and the printing and saving responsibilities have been delegated to separate classes. This makes the code more modular, easier to understand, and less prone to errors.

Open-Closed Principle

The Open-Closed Principle (OCP) states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means that the behavior of a software entity can be extended without modifying its source code.

The OCP is essential because it promotes software extensibility and maintainability. By allowing software entities to be extended without modification, developers can add new functionality without the risk of breaking existing code. This results in code that is easier to maintain, extend, and reuse.

Let's take the previous example again.

class InvoiceDao {
    private Invoice invoice;

    public InvoiceDao(Invoice invoice) {
        this.invoice = invoice;
    }

    public void saveToDb() {
        // save to database implementation
    }
}

The InvoiceDao class has a single responsibility of saving the invoice to the database. But, suppose there's a new requirement to save the invoice to a file as well. One way to implement this requirement would be to modify the existing InvoiceDao class by adding a saveToFile() method. However, this violates the Open-Closed Principle because it modifies the existing code that has already been tested and is live in production.

To follow the OCP, a better solution would be to create an InvoiceDao interface and implement it separately for database and file saving as shown below:

interface InvoiceDao {
    public void save(Invoice invoice);
}

class DatabaseInvoiceDao implements InvoiceDao {
    @Override
    public void save(Invoice invoice) {
        // save to database implementation
    }
}

class FileInvoiceDao implements InvoiceDao {
    @Override
    public void save(Invoice invoice) {
        // save to file implementation
    }
}

This way, if there's a new requirement to save the invoice to another data store, you can implement a new InvoiceDao implementation without modifying the existing code. Thus, the InvoiceDao interface is open for extension and closed for modification, which follows the OCP.

Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that any instance of a derived class should be substitutable for an instance of its base class without affecting the correctness of the program. In other words, a derived class should behave like its base class in all contexts. In more simple terms, if class A is a subtype of class B, you should be able to replace B with A without breaking the behavior of your program.

The importance of LSP lies in its ability to ensure that the behavior of a program remains consistent and predictable when substituting objects of different classes. Violating LSP can lead to unexpected behavior, bugs, and maintainability issues.

Let's take an example.

interface Bike {
    void turnOnEngine();

    void accelerate();
}

In the given example, the interface Bike has two methods, turnOnEngine() and accelerate(). Two classes implement this interface, Motorbike and Bicycle.

class Motorbike implements Bike {

    boolean isEngineOn;
    int speed;

    @Override
    public void turnOnEngine() {
        isEngineOn = true;
    }

    @Override
    public void accelerate() {
        speed += 5;
    }
}

Motorbike correctly implements the turnOnEngine() method, as it sets the isEngineOn boolean to true. It also correctly implements the accelerate() method by increasing the speed by 5.

class Bicycle implements Bike {

    boolean isEngineOn;
    int speed;

    @Override
    public void turnOnEngine() {
        throw new AssertionError("There is no engine!");
    }

    @Override
    public void accelerate() {
        speed += 5;
    }
}

However, the Bicycle class throws an AssertionError in the turnOnEngine() method because it has no engine. This means that an instance of Bicycle cannot be substituted for an instance of Bike without breaking the behavior of the program.

In other words, if the Bicycle class is considered a subtype of the Bike interface, then according to LSP, any instance of Bike should be replaceable with an instance of Bicycle without altering the correctness of the program. But in this case, it's not true because Bicycle throws an AssertionError while trying to turn on the engine. Therefore, the code violates the LSP.

Interface Segregation Principle

The Interface Segregation Principle (ISP) focuses on designing interfaces that are specific to their client's needs. It states that no client should be forced to depend on methods it does not use.

The principle suggests that instead of creating a large interface that covers all the possible methods, it's better to create smaller, more focused interfaces for specific use cases. This approach results in interfaces that are more cohesive and less coupled.

Consider a Vehicle interface as below:

interface Vehicle {
    void startEngine();
    void stopEngine();
    void drive();
    void fly();
}

And then you have a class called Car that implements the Vehicle interface:

class Car implements Vehicle {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }

    @Override
    public void fly() {
        throw new UnsupportedOperationException("This vehicle cannot fly.");
    }
}

In this example, the Vehicle interface has too many methods. The Car class is forced to implement all of them, even though they cannot fly. This violates the ISP because the Vehicle interface is not properly segregated into smaller interfaces based on related functionality.

Let's understand how you can follow ISP here. Suppose you refactor the Vehicle interface into smaller, more focused interfaces:

interface Drivable {
    void startEngine();
    void stopEngine();
    void drive();
}

interface Flyable {
    void fly();
}

Now, you can have a class called Car that only implements the Drivable interface:

class Car implements Drivable {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }
}

And, thanks to interface segregation, you can have another class called Airplane that implements both the Drivable and Flyable interfaces:

class Airplane implements Drivable, Flyable {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }

    @Override
    public void fly() {
        // implementation
    }
}

In this example, you have properly segregated the Vehicle interface into smaller interfaces based on related functionality. This adheres to the ISP and makes your code more flexible and maintainable.

Dependency Inversion Principle

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules, but both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. This principle aims to reduce coupling between modules, increase modularity, and make the code easier to maintain, test, and extend.

For example, consider a scenario where you have a class that needs to use an instance of another class. In the traditional approach, the first class would directly create an instance of the second class, leading to a tight coupling between them. This makes it difficult to change the implementation of the second class or to test the first class independently. However, if you apply the DIP, the first class would depend on an abstraction of the second class instead of the implementation, making it possible to easily change the implementation and test the first class independently.

Here is an example that violates the DIP:

class WeatherTracker {
    private String currentConditions;
    private Emailer emailer;

    public WeatherTracker() {
        this.emailer = new Emailer();
    }

    public void setCurrentConditions(String weatherDescription) {
        this.currentConditions = weatherDescription;
        if (weatherDescription == "rainy") {
            emailer.sendEmail("It is rainy");
        }
    }
}

class Emailer {
    public void sendEmail(String message) {
        System.out.println("Email sent: " + message);
    }
}

In this example, the WeatherTracker class directly creates an instance of the Emailer class, making it tightly coupled to the implementation. This makes it difficult to change the implementation of the Emailer class or to test the WeatherTracker class independently.

Here is an example of how to apply the DIP to the above code:

interface Notifier {
    public void alertWeatherConditions(String weatherDescription);
}

class WeatherTracker {
    private String currentConditions;
    private Notifier notifier;

    public WeatherTracker(Notifier notifier) {
        this.notifier = notifier;
    }

    public void setCurrentConditions(String weatherDescription) {
        this.currentConditions = weatherDescription;
        if (weatherDescription == "rainy") {
            notifier.alertWeatherConditions("It is rainy");
        }
    }
}

class Emailer implements Notifier {
    public void alertWeatherConditions(String weatherDescription) {
        System.out.println("Email sent: " + weatherDescription);
    }
}

class SMS implements Notifier {
    public void alertWeatherConditions(String weatherDescription) {
        System.out.println("SMS sent: " + weatherDescription);
    }
}

In this example, you created a Notifier interface that defines the alertWeatherConditions method. The WeatherTracker class now depends on this interface instead of the Emailer class, making it possible to easily change the implementation and test the WeatherTracker class independently. You also created two implementations of the Notifier interface, Emailer, and SMS, to demonstrate how you can change the implementation of the WeatherTracker class without affecting its behavior.

Conclusion

In this article, you learned about SOLID principles which is a very important part of Design Principles. By applying these principles in your software development projects, you can create code that is easier to maintain, extend, and modify, leading to more robust, flexible, and reusable software. This will also lead to better collaboration among team members, as the code becomes more modular and easier to work with.

DEV Community: Ashutosh Krishna

The Ultimate Guide to the Java Singleton Pattern

Table of Contents

What is a Singleton Class?

Key Characteristics

Benefits

Drawbacks

Why Do We Need Singleton?

Core Principles Behind Singleton

Basic Singleton Implementation: Eager Initialization

The Problem

Lazy Initialization: Saving Memory

The Problem

Synchronized Method: The Traffic Jam

The Problem

Double-Checked Locking

Understanding the volatile Keyword

The Bill Pugh Singleton: A JVM Masterclass

The Reflection Problem

The Serialization Problem

The Cloning Problem

The Enum Singleton: The Indestructible Solution

Singleton and Class Loaders: An Enterprise Reality

Comparing All Singleton Implementations

Singleton vs Static Utility Class

Singleton in the Spring Framework

Singleton in Modern Cloud Applications

When NOT to Use Singleton (The Anti-Pattern Debate)

Common Mistakes Developers Make

Best Practices for Modern Development

Common Interview Questions and Answers

Conclusion

Stop Misusing POST for Search: Welcome to the HTTP QUERY Method

Why GET Isn't Always Enough

Why POST Isn't the Ideal Replacement

How QUERY Solves the Problem

Syntax and Request Examples

The Request

The Response

Practical Code Examples

1. Sending a QUERY Request using cURL

2. Fetch API Example (JavaScript)

QUERY vs GET vs POST

Current Support and Considerations

The Caching Challenge

Security and Middleboxes

Best Practices for Adopting QUERY

Key Takeaways

Build AI Apps with Gradio: Turn Your Python Scripts into Web Apps

What is Gradio?

Installing and Setting Up Gradio

Build Your First Gradio App

Convert Terminal Logic into a Web App

Understanding Gradio Components

Understanding Blocks

Add Streaming Responses

Upload Files and Build a Simple AI Document Chat

Deploying Gradio Apps

How Gradio Works Internally

Common Beginner Mistakes

When to Use Gradio vs Full Frameworks

Final Thoughts

Spring Boot @Value Property Order Explained

Understanding the @Value Annotation

Where Does Spring Boot Look for Properties (Order of Resolution)

Example Demonstration

Step 1: Define properties in both files

Step 2: Use @Value in your code

Step 3: Run the application with different configurations

Case 1: Default profile (no active profile)

Case 2: Active profile set to “dev”

Case 3: Override from the command line

Case 4: No property found anywhere

Common Pitfalls

1. Forgetting to Set the Active Profile

2. Unintentional Property Overrides

3. Confusing @Value and @ConfigurationProperties

Interview Tip / Summary

Quick Mnemonic to Remember the Order

Frequently Asked Questions (FAQ)

Understanding the `volatile` Keyword

Understanding the `@Value` Annotation

Step 2: Use `@Value` in your code

3. Confusing `@Value` and `@ConfigurationProperties`

2. How does `@ConfigurationProperties` differ from `@Value`?