DEV Community: Jay D

Building Immutable Classes in Java: A Developer’s Guide with a Real-Life Example

Jay D — Thu, 26 Dec 2024 15:04:40 +0000

You’ve probably heard about immutable classes. But have you ever wondered why they’re so important and how to build your own custom immutable class? In this, we’ll explore immutability in Java with a real-life user profile example to help you understand and apply this concept effectively.

What Is an Immutable Class?
An immutable class is a class whose instances cannot be modified after they are created. Once you create an object, its state stays the same forever.

In Java, popular examples of immutable classes include String, Integer, and other wrapper classes.

Why Are Immutable Classes Useful?
1.Thread-Safety: Since immutable objects can’t be changed, they’re naturally thread-safe. No synchronization is required.
2.Ease of Use: Immutable objects are simple to use and share across methods or threads without worrying about unexpected changes.
3.Predictable Behavior: You know the state of an immutable object will never change, which makes debugging easier.

Real-World Example: Immutable User Profile

Imagine a user profile in an application. When a user creates a profile, their username, email, and date of birth are fixed. If they need to update any detail (e.g., change their email), the system creates a new profile instead of modifying the existing one.

Implementing an Immutable User Class


import java.util.Date;

public final class User {
    private final String username;
    private final String email;
    private final Date dateOfBirth;

    // Constructor to initialize all fields
    public User(String username, String email, Date dateOfBirth) {
        this.username = username;
        this.email = email;
        // Defensively copy mutable fields like Date
        this.dateOfBirth = new Date(dateOfBirth.getTime());
    }

    // Getter for username
    public String getUsername() {
        return username;
    }

    // Getter for email
    public String getEmail() {
        return email;
    }

    // Getter for date of birth (return a copy of the date to ensure immutability)
    public Date getDateOfBirth() {
        return new Date(dateOfBirth.getTime());
    }

    @Override
    public String toString() {
        return "User{" +
                "username='" + username + '\'' +
                ", email='" + email + '\'' +
                ", dateOfBirth=" + dateOfBirth +
                '}';
    }
}

Why Is This Class Immutable?
1.final Class: The User class is declared as final, so no subclass can modify its behavior.
2.Private, Final Fields: All fields (username, email, and dateOfBirth) are private and final, ensuring they are initialized only once.
3.No Setters: The class does not have any setter methods to modify its fields.
4.Defensive Copying: The Date field is mutable, so:
• A new Date object is created in the constructor.
• A copy of the Date is returned in the getter to protect the original object.

Using the Immutable User Class
Here’s how you can use the User class:

import java.util.Date;

public class Main {
    public static void main(String[] args) {
        // Create a new User object
        Date dob = new Date();
        User user = new User("sachin_test", "sachin@gmail.com", dob);

        // Print the user details
        System.out.println("Original User: " + user);

        // Attempt to modify the date of birth
        dob.setTime(0); // Changing the original Date object
        System.out.println("After Modifying Original Date: " + user);

        // Try modifying the returned date from getter
        Date retrievedDate = user.getDateOfBirth();
        retrievedDate.setTime(0); // Changing the retrieved Date object
        System.out.println("After Modifying Retrieved Date: " + user);
    }
}

Output

Original User: User{username='sachin_test',email='sachin@gmail.com', dateOfBirth=Tue Dec 24 00:00:00 IST 2024}
After Modifying Original Date: User{username='sachin_test', email='sachin@gmail.com', dateOfBirth=Tue Dec 24 00:00:00 IST 2024}
After Modifying Retrieved Date: User{username='sachin_test', email='sachin@gmail.com', dateOfBirth=Tue Dec 24 00:00:00 IST 2024}

As you can see, the User object remains unchanged, proving its immutability.

Why Defensive Copying Matters
Without defensive copying, the immutability of the class can be compromised. For example:

public User(String username, String email, Date dateOfBirth) {
    this.username = username;
    this.email = email;
    // If we don't copy the date, external changes to the original Date object will affect our class
    this.dateOfBirth = dateOfBirth;
}

This would allow changes to the Date object outside the class to affect the User object’s state. Defensive copying prevents this.

Benefits of Immutable User Class
1.Data Safety: The user profile data cannot be altered unintentionally.
2.Thread Safety: The User object can be safely shared between multiple threads.
3.Simplified Debugging: No need to trace how the state of the object changes over time.

Real-Life Applications of Immutable Classes
1.APIs: Immutable classes are widely used in APIs where data integrity is crucial. For example, HttpRequest and HttpResponse objects in web frameworks often use immutability.
2.Multithreading: Immutable objects eliminate synchronization issues in multithreaded environments.
3.Data Modeling: Immutable classes are ideal for representing fixed data, like user profiles, currency, or coordinates.

Conclusion

Creating immutable classes in Java is a powerful way to design reliable, thread-safe, and maintainable code. By following the principles of immutability, you can ensure the integrity of your objects and prevent unintended side effects.

The User example above demonstrates how to implement an immutable class while addressing potential pitfalls like mutable fields. Now it’s your turn—try creating your own immutable classes and see how they make your code cleaner and safer!

Single Responsibility Principle in Java

Jay D — Tue, 24 Dec 2024 14:51:16 +0000

Hey there! When you're just starting out with coding, it's easy to write code that works but is hard to read or change later. that's where SOLID Principles come in ! They are like rules to help you write clean and maintainable code.
Imagine we're building a ride sharing app(like Uber)

What Does SOLID Stand for?
S: Single Responsibility Principal
O: Open/Closed Principle
L: Liskov Substitution Principle
I: Interface Segregation Principle
D: Dependency Inversion Principle

1. Single Responsibility Principal (SRP)

Rule: One Class Should do only one job
Problem: The Overloaded Class
Imagine a class in your ride-sharing app that handles booking rides, payments and rating drivers.

class RideService {
       void bookRide(){/* Logic for booking ride */}
       void processPayment(){/* Logic for process payment */}
       void rateDriver(){/* Logic for reviews */}
}

If your payment system changes, you risk breaking the ride-booking code.
That's bad!

Fix: Divide the work:

class RideBooking {
   void bookRide(){/* Only handles booking ride */}
}

class PaymentService{
   void processPayment(){/* Only handles payment process */}
}

class DriverRating{
  void rateDriver(){/* Only handle reviews */}
}

Now, If something goes wrong with payments, it won't mess up ride booking.
Everyone sticks to their job!

2. Open/Closed Principle
Rule: Classes should be open for extension but closed for modification
Problem: Your payment system initially supports only Credit card payments. Adding support for PayPal requires modifying existing code, which could introduce bugs.

class PaymentProcesser{
      double processPayments(String type){
          if(type.equals("CrediCard")){
             return 90.0;          
         }else if (type.equals("PayPal")){
             return 90.0;
        }
       return 0.0;
    }
}

Fix: Use an interface to make the system extensible without modifying existing code.

interface PaymenTMetod{
   double processPayment();
}

class CrediCardPayment implements PaymentMethod{
     public double processPayment() { return 90.0; }
}

class PayPalPayment implements PaymentMethod{
     public double processPayment() { return 95.0; }
}

class PaymentProcessor{
     double process(PaymentMethod payment){
        return payment.processPayment();
     }
}

3. Liskov Substitution Principle
Rule: If something works with a parent class,
it should also work with its child classes
Problem: Unpredictable Vehicles
Your app allows people to book cars, bikes, or trucks.
But one day, someone tries to book a truck for a ride,
and the app crashes.
Why? Because trucks aren’t supposed to take passengers.

class Vehicle {
    void startRide() { System.out.println("Ride started"); }
}

class Truck extends Vehicle {
    @Override
    void startRide() {
        throw new UnsupportedOperationException("Trucks can't be booked");
    }
}

When you use Truck like any other vehicle, it doesn’t work as expected.

Fix:

Let’s ensure that every type of Vehicle behaves as it should.

abstract class Vehicle {
    abstract void startRide();
}

class Car extends Vehicle {
    void startRide() { System.out.println("Car ride started"); }
}

class Bike extends Vehicle {
    void startRide() { System.out.println("Bike ride started"); }
}

Now, only vehicles that can take rides are part of the system. Everyone plays fair!

4. Interface Segregation Principle
Rule: A class should not be forced to implement methods that doesnt use.
Problem: Too Many Responsibilities
Drivers in your app can accept rides and see earnings,
while admins can manage drivers.
If you give both the same interface, it looks like this:

interface AppUser {
    void acceptRide();
    void viewEarnings();
    void manageDrivers();
}

Drivers don’t manage drivers,
so they leave that method empty or throw an error. That’s awkward!

Fix: Keep Interfaces Small

interface RideHandler {
    void acceptRide();
}

interface EarningsViewer {
    void viewEarnings();
}

interface DriverManager {
    void manageDrivers();
}

class Driver implements RideHandler, EarningsViewer {
    public void acceptRide() { System.out.println("Ride accepted"); }
    public void viewEarnings() { System.out.println("Earnings displayed"); }
}

class Admin implements DriverManager {
    public void manageDrivers() { System.out.println("Managing drivers"); }
}

Now, drivers only do what they’re supposed to, and admins handle their tasks separately. Everyone’s happy!

5. Dependency Inversion Principle
Rule: High-level module should not depend on low level modules. Both should depend on abstraction.
Problem: Hard-Coded Notifications
Your app sends SMS notifications, but now you want to add email and push notifications. Your code is tightly tied to SMS:

class SMSNotification {
    void send(String message) { System.out.println("SMS: " + message); }
}

class NotificationManager {
    private SMSNotification smsNotification;

    public NotificationManager() {
        this.smsNotification = new SMSNotification();
    }

    void notifyUser(String message) {
        smsNotification.send(message);
    }
}

To add email, you’d have to rewrite everything. What a pain!

Fix: Use an abstraction to decouple the notification manager from specific notification methods.

interface NotificationService {
    void send(String message);
}

class SMSNotification implements NotificationService {
    public void send(String message) { System.out.println("SMS: " + message); }
}

class EmailNotification implements NotificationService {
    public void send(String message) { System.out.println("Email: " + message); }
}

class NotificationManager {
    private NotificationService notificationService;

    public NotificationManager(NotificationService notificationService) {
        this.notificationService = notificationService;
    }

    void notifyUser(String message) {
        notificationService.send(message);
    }
}

Now, you can easily switch between SMS, email, or any other notification method.

Why You Should Care

Following SOLID principles makes your code:

Easy to understand (no messy “spaghetti” code).

Easy to update (add features without fear).

Fun to work with (seriously, your future self will thank you).

So next time you build an app or write code, remember these five principles. They’ll make you the smartest coder in the room—and who doesn’t want that?

What principle do you think is the coolest? Let me know!