DEV Community: Rajani K

Chapter 3 - Methods Common to All Objects (Items 10-14)

Rajani K — Wed, 24 Sep 2025 15:49:42 +0000

Introduction

Welcome back to our "Effective Java" blog series! In this chapter, we're moving on to a critical part of object-oriented programming: understanding and correctly implementing the methods inherited from java.lang.Object. While these methods may seem straightforward, a flawed implementation can lead to subtle and hard-to-find bugs. As always, we'll see how Kotlin's modern design patterns can help us avoid these pitfalls from the start.

Chapter 3: Chapter 3 - Methods Common to All Objects

Item 10: Override equals() when you need value-based equality
Item 11: Always override hashCode() when you override equals()
Item 12: Always override toString() for better debugging
Item 13: Avoid clone() and use copy constructors or the copy() method in Kotlin
Item 14: Implement Comparable to define a natural order

Item 10: Override equals() when you need a value-based equality

Summary

The equals() method is used to determine if two objects are logically equal. The default implementation in Object simply checks for reference equality (this == obj). You must override it when you want two distinct objects to be considered equal if their data is the same. However, a correct implementation must adhere to a strict contract.

The equals() Contract

Reflexive: x.equals(x) must be true.
Symmetric: If x.equals(y) is true, then y.equals(x) must be true.
Transitive: If x.equals(y) is true and y.equals(z) is true, then x.equals(z) must be true.
Consistent: Multiple calls to x.equals(y) return the same result, assuming the objects are not modified.
Non-null: x.equals(null) must be false.

Java

A manual implementation in Java is verbose and requires careful attention to detail.

import java.util.Objects;

public final class User {
    private final String name;
    private final String email;
    private final String phoneNumber;

    public User(String name, String email, String phoneNumber) {
        this.name = name;
        this.email = email;
        this.phoneNumber = phoneNumber;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        User user = (User) o;
        return Objects.equals(name, user.name) &&
               Objects.equals(email, user.email) &&
               Objects.equals(phoneNumber, user.phoneNumber);
    }
}

Kotlin (Data Class)

This is where Kotlin's data class shines. A data class automatically generates equals(), hashCode(), and toString() methods based on its primary constructor properties. This is the idiomatic way to handle value-based equality in Kotlin.

data class User(val name: String, val email: String, val phoneNumber: String)

This single line of code provides a robust and correct equals() implementation.

Kotlin (Non-Data Class)

For a regular class, you have to manually override equals(), just like in Java. It's a bit more verbose, but gives you more control.

class User(val name: String, val email: String, val phoneNumber: String) {
    override fun equals(other: Any?): Boolean {
        if (this === other) return true
        if (other !is User) return false
        return name == other.name &&
               email == other.email &&
               phoneNumber == other.phoneNumber
    }
}

Summary: Only override equals() when you need value equality. For simple cases in Kotlin, data class provides the perfect, foolproof solution, but it's important to know how to do it manually for more complex classes.

Item 11: Always Override hashCode() When You Override equals()

Summary

The hashCode() method must always be overridden if equals() is overridden. The Object contract specifies that two objects that are equal according to equals() must have the same hash code. Failure to do so will break hash-based collections like HashMap and HashSet.

Java

A good hashCode() implementation in Java is a combination of a prime number and the hash codes of the object's fields. The formula is: result = 31 * result + c. The Objects.hash utility is a convenient way to implement this in modern Java.

import java.util.Objects;

public final class User {
    // ...
    @Override
    public int hashCode() {
        return Objects.hash(name, email, phoneNumber);
    }
}

Kotlin (Data Class)

Again, the data class simplifies this entirely. The hashCode() method is automatically generated and consistent with equals(), preventing a common source of bugs.

// The hashCode() is automatically generated and correct.
data class User(val name: String, val email: String, val phoneNumber: String)

Kotlin (Non-Data Class)

For a regular class, you'll need to manually implement hashCode() as well. It's crucial that it's consistent with your equals() implementation.

class User(val name: String, val email: String, val phoneNumber: String) {
    override fun hashCode(): Int {
        var result = name.hashCode()
        result = 31 * result + email.hashCode()
        result = 31 * result + phoneNumber.hashCode()
        return result
    }
}

Summary: The equals() and hashCode() methods are a pair. If you override one, you must override the other. In Kotlin, use a data class for this, or be diligent in your manual implementations.

Item 12: Always Override toString()

Summary

While not as critical as equals() and hashCode(), a good toString() implementation is vital for debugging and logging. The default implementation from Object is not useful.

Java

A manual toString() implementation should be clear, concise, and provide all relevant information about the object's state.

public final class User {
    // ...
    @Override
    public String toString() {
        return "User{" +
               "name='" + name + '\'' +
               ", email='" + email + '\'' +
               ", phoneNumber='" + phoneNumber + '\'' +
               '}';
    }
}

Kotlin (Data Class)

Kotlin's data class also generates a useful toString() method for you, including all properties in the primary constructor.

// Automatically generates a readable toString() method.
data class User(val name: String, val email: String, val phoneNumber: String)

Kotlin (Non-Data Class)

For a non-data class, you'll need to manually override toString() to get a meaningful representation.

class User(val name: String, val email: String, val phoneNumber: String) {
    override fun toString(): String {
        return "User(name=$name, email=$email, phoneNumber=$phoneNumber)"
    }
}

Summary: A useful toString() method is essential. When you create a class, always consider how its string representation can help you understand its state.

Item 13: Override clone() Judiciously

Summary

The clone() method is part of a complex and flawed framework. The Cloneable interface is a marker interface, and Object.clone() is a protected method that performs a shallow copy. This approach is brittle and can lead to bugs. For instance, if an object contains a mutable field, a shallow copy will lead to two objects sharing the same mutable state, which is almost never what you want.

Java

To correctly implement clone(), you must handle both the Cloneable marker interface and potential CloneNotSupportedExceptions. Even then, it's often more trouble than it's worth.

// A flawed clone() implementation in Java.
public class MyObject implements Cloneable {
    private List<String> list;

    // ...

    @Override
    public MyObject clone() throws CloneNotSupportedException {
        // This is a shallow copy! The cloned object shares the same list.
        return (MyObject) super.clone();
    }
}

A better solution is to use a copy constructor or a copy factory, which is a safer and more readable pattern.

Kotlin (Data Class)

Kotlin's data class provides a copy() method that is a perfect example of this idiomatic approach. The copy() method creates a new instance with the same properties as the original, allowing you to optionally change specific fields. It handles the deep vs. shallow copy behavior exactly as you would expect.

data class MyObject(val name: String, val list: MutableList<String>)

// Creating a deep copy using the copy() method.
val original = MyObject("A", mutableListOf("1", "2"))
val copy = original.copy(list = ArrayList(original.list))

Kotlin (Non-Data Class)

Regular classes in Kotlin do not get an automatic copy() method. You'll need to create one yourself, or a copy constructor, to provide this functionality.

class MyObject(val name: String, val list: MutableList<String>) {
    fun copy(name: String = this.name, list: MutableList<String> = this.list): MyObject {
        return MyObject(name, list)
    }
}

// Creating a copy using our custom function.
val original = MyObject("A", mutableListOf("1", "2"))
val copy = original.copy(list = ArrayList(original.list))

Summary: Avoid the clone() method. Use a copy constructor or, better yet, the copy() method in a Kotlin data class. For non-data classes, create your own copy() function.

Item 14: Consider Implementing Comparable

Summary

The Comparable interface is used for natural ordering. It contains a single method, compareTo(), which compares the this object to another object. Correctly implementing compareTo() allows objects to be sorted and to work with collections like TreeSet and TreeMap.

Java (Java 21)

Modern Java provides a more concise way to implement Comparable using Comparator.comparing and thenComparing, which is much cleaner and less error-prone than manual comparisons.

import java.util.Comparator;

public final class User implements Comparable<User> {
    private final String name;
    private final String email;
    private final String phoneNumber;

    public User(String name, String email, String phoneNumber) {
        this.name = name;
        this.email = email;
        this.phoneNumber = phoneNumber;
    }

    private static final Comparator<User> COMPARATOR =
        Comparator.comparing(User::getName)
                  .thenComparing(User::getEmail)
                  .thenComparing(User::getPhoneNumber);

    public String getName() { return name; }
    public String getEmail() { return email; }
    public String getPhoneNumber() { return phoneNumber; }

    @Override
    public int compareTo(User user) {
        return COMPARATOR.compare(this, user);
    }
}

Kotlin

For a regular class, you implement Comparable and override compareTo() in the same way. The compareBy function provides a more idiomatic and readable alternative to manual comparison logic.

class User(val name: String, val email: String, val phoneNumber: String) : Comparable<User> {
    override fun compareTo(other: User): Int {
        return compareBy<User> { it.name }
            .thenBy { it.email }
            .thenBy { it.phoneNumber }
            .compare(this, other)
    }
}

Summary: Use the Comparable interface to define a natural order for your objects, but be sure to adhere to its strict contract.

Wrap-up

The methods inherited from java.lang.Object are foundational to the Java platform. By correctly implementing equals(), hashCode(), toString(), and compareTo(), you ensure your objects behave predictably and work correctly with the rest of the Java ecosystem. The lessons we've learned here are a perfect example of why Kotlin's data class is such a powerful and effective tool, as it automates the implementation of these critical methods, helping you avoid common pitfalls.

Next Up

In our next post, we will begin exploring Chapter 4: Classes and Interfaces, and dive into how to design them for clarity and power. Stay tuned!

Chapter 2: Creating and Destroying Objects (Items 6-9)

Rajani K — Mon, 15 Sep 2025 15:53:59 +0000

Introduction

Welcome back to our series on "Effective Java, 3rd Edition"! In our last post, we explored the first five items of Chapter 2, covering the basics of object creation. This time, we're diving deeper into some of the more nuanced aspects of managing an object's lifecycle. We'll look at how to prevent memory leaks and handle resource management.

Chapter 2: Creating and Destroying Objects (Items 6-9)

Item 6: Avoid Creating Unnecessary Objects : Avoid creating unnecessary objects to improve performance and code cleanliness.
Item 7: Eliminate Obsolete Object References: Prevent memory leaks by nulling out obsolete references.
Item 8: Avoid Finalizers and Cleaners: Use deterministic resource management instead of unreliable finalizers or cleaners.
Item 9: Prefer try-with-resources to try-finally: Ensure reliable resource cleanup in Java with try-with-resources.

Item 6: Avoid Creating Unnecessary Objects

Creating unnecessary objects can negatively impact performance and lead to code that is less clean. The most common pitfall is creating a new String object when a literal would suffice. Java's object creation is a relatively expensive operation, so it's a practice worth avoiding when possible.

Java

A classic anti-pattern is using the String constructor for a string literal.

// DON'T DO THIS! Creating unnecessary String objects.
String s = new String("Hello"); // This creates two String objects: one literal and one object instance.

// The correct, more efficient way.
String s = "Hello"; // This uses a single String literal from the string pool.

The same principle applies to using factory methods for objects that can be reused. Instead of creating a new object every time, a static factory method can return an existing instance. This is especially true for immutable objects.

// A less obvious example of unnecessary object creation in a loop.
Long sum = 0L; // Autoboxing is creating a new Long object in each iteration!
for (long i = 0; i < Integer.MAX_VALUE; i++) {
    sum += i;
}

// The corrected version using a primitive long.
long sum = 0L; // No unnecessary objects are created here.
for (long i = 0; i < Integer.MAX_VALUE; i++) {
    sum += i;
}

Kotlin

Kotlin's approach with primitives and immutability helps mitigate some of these issues. Kotlin's string literals are handled the same way as Java's, but its type system often guides you towards more efficient choices. For instance, the Long vs long issue from Java doesn't exist in the same way, as Kotlin's Long is compiled to a primitive long where possible.

// Kotlin code that avoids unnecessary object creation.
val s = "Hello" // No unnecessary object creation.

var sum = 0L // The L denotes a Long, but Kotlin optimizes this to a primitive long.
for (i in 0..Int.MAX_VALUE) {
    sum += i
}

Summary

Strive to reuse objects whenever possible. Avoid creating unnecessary new instances, especially in performance-critical code. This makes your applications faster and more memory-efficient.

Item 7: Eliminate Obsolete Object References

This item is a critical one for any developer working with a garbage-collected language. The core idea is to prevent memory leaks by ensuring that objects you are no longer using are truly eligible for garbage collection. A memory leak occurs when an object is "logically" no longer needed but is still "physically" referenced by your code, preventing the garbage collector from reclaiming its memory.

A classic example is implementing a custom stack or queue. When you pop an element from the stack, the array that backed it still holds a reference to the popped object. While your size variable correctly indicates the new top of the stack, the old reference remains. If the popped object holds a large amount of memory, or if you repeat this process many times, it can lead to a significant memory leak.

Java

In Java, you must explicitly null out the reference once you are done with it.

// A simple Java Stack with a memory leak.
public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e) {
        // ... (resize logic)
        elements[size++] = e;
    }

    public Object pop() {
        if (size == 0)
            throw new EmptyStackException();
        Object result = elements[--size];
        // Memory leak here! elements[size] still holds a reference
        // to the popped object.
        return result;
    }
}

The fix is straightforward: just null the reference.

// The corrected Java Stack.
public Object pop() {
    if (size == 0)
        throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null; // Corrected: explicitly null the obsolete reference
    return result;
}

Kotlin

The same problem can exist in Kotlin, especially when using mutable arrays or collections. The principle for the solution remains identical.

// A simple Kotlin Stack with a potential memory leak.
class Stack<E> {
    private var elements = arrayOfNulls<Any>(16)
    private var size = 0

    fun push(e: E) {
        // ... (resize logic)
        elements[size++] = e
    }

    fun pop(): E {
        if (size == 0)
            throw EmptyStackException()
        @Suppress("UNCHECKED_CAST")
        val result = elements[--size] as E
        // Same issue here!
        return result
    }
}

And the fix is just as simple.

// The corrected Kotlin Stack.
fun pop(): E {
    if (size == 0)
        throw EmptyStackException();
    @Suppress("UNCHECKED_CAST")
    val result = elements[--size] as E
    elements[size] = null // Corrected: null out the obsolete reference
    return result
}

Summary

The key takeaway is to be mindful of your object references. When an object is no longer part of your data structure's logical state, be sure to set its reference to null to allow the garbage collector to do its job.

Item 8: Avoid Finalizers and Cleaners

The finalize() method was a feature in older versions of Java intended for resource cleanup, but it is deeply flawed. Finalizers are unpredictable, non-deterministic, and can introduce performance overhead and even security vulnerabilities. You can't guarantee when or even if a finalizer will run, making them completely unreliable for critical resource cleanup.

Java 9 introduced Cleaner as a more robust (but still not guaranteed) alternative to finalizers. While it's a step up, the principle remains the same: it's not the right tool for the job.

Java

The correct way to handle resource cleanup in Java is to use try-with-resources (see Item 8). This ensures that a resource is closed deterministically and reliably.

// A problematic use of a finalizer in Java.
// This is not a reliable way to close resources.
public class ResourceHandler {
    private final FileInputStream fileInputStream;

    public ResourceHandler(String filePath) throws FileNotFoundException {
        this.fileInputStream = new FileInputStream(filePath);
    }

    @Override
    protected void finalize() throws IOException {
        fileInputStream.close();
    }
}

Kotlin

Kotlin has taken an even stronger stance on this. The finalize() method does not exist in Kotlin, and you cannot override it. This is a deliberate design decision that guides developers away from this problematic pattern and toward a more reliable solution.

The idiomatic Kotlin approach is to use the use function, which we'll discuss in the next two items.

Summary

Don't use finalizers or cleaners. They are unreliable and dangerous. Instead, use a deterministic resource management approach.

Item 9: Prefer try-with-resources to try-finally

This item is a direct solution to the problems highlighted in Item 7. Before Java 7, resource management was often handled with try-finally blocks, which were verbose and error-prone. A key issue with try-finally is that an exception in the finally block can "swallow" the original exception from the try block, making debugging a nightmare.

try-with-resources, introduced in Java 7, is a significant improvement. It automatically handles the closing of any resource that implements the java.lang.AutoCloseable interface. It is concise, safe, and correctly handles suppressed exceptions, ensuring you don't lose the original stack trace.

Java

The difference in code complexity is stark.

// Legacy Java with try-finally. Verbose and error-prone.
try {
    InputStream is = new FileInputStream("file.txt");
    try {
        // Do something with the stream...
    } finally {
        is.close();
    }
} catch (IOException e) {
    // ...
}

And with try-with-resources:

// Modern Java with try-with-resources. Clean and reliable.
try (InputStream is = new FileInputStream("file.txt")) {
    // Do something with the stream...
} catch (IOException e) {
    // ...
}

Kotlin

Kotlin's approach to this problem is the use extension function, which achieves the same goals as try-with-resources but with a more functional and idiomatic syntax.

// The Kotlin equivalent of try-with-resources using `use`.
import java.io.File

fun readFile(path: String) {
    File(path).inputStream().use { inputStream ->
        // This block executes, and `inputStream` is automatically closed
        // when the block exits.
    }
}

Summary

try-with-resources in Java and the use function in Kotlin are the definitive ways to handle resources that require closing. They prevent resource leaks and make your code significantly more robust and readable.

Summary

For any resource management task in Kotlin, the use function should be your first and only choice. It's a prime example of how Kotlin's language design helps you write more effective, safe, and concise code.

Next Up

In our next post, we'll dive into Chapter 3: Methods Common to All Objects, exploring the critical importance of correctly overriding methods like equals(), hashCode(), and toString(). Stay tuned!

Chapter 2: Creating and Destroying Objects (Items 1-5)

Rajani K — Thu, 11 Sep 2025 13:02:00 +0000

Introduction to the Series

"Effective Java" by Joshua Bloch helped me in writing robust, efficient, and maintainable Java code. I've recently picked up Kotlin, I'm excited to explore how the principles and best practices outlined in this book can be applied to kotlin. In this series, I'll be summarizing each chapter and item, providing Java and Kotlin implementations where relevant, to help me solidify my understanding of both languages.

Chapter 2: Creating and Destroying Objects

Item 1: Static Factory Methods: Static factory methods provide more flexibility and readability than constructors.
Item 2: Builder Pattern: The builder pattern is useful when dealing with many constructor parameters.
Item 3: Singleton Property: Implementing singletons using private constructors or enum types.
Item 4: Noninstantiability: Enforcing noninstantiability using private constructors.
Item 5: Dependency Injection: Prefer dependency injection to hardwiring resources.

Item 1: Consider Static Factory Methods Instead of Constructors

Summary

Static factory methods provide an alternative to constructors for creating objects. They offer several benefits, including meaningful method names, flexibility, and the ability to return objects of any subclass.

Java Implementation

public class Color {
    private final int value;

    private Color(int value) {
        this.value = value;
    }

    public static Color ofValue(int value) {
        return new Color(value);
    }

    public static Color ofRGB(int r, int g, int b) {
        return new Color((r << 16) | (g << 8) | b);
    }
}

Kotlin Implementation

class Color private constructor(val value: Int) {
    companion object {
        fun ofValue(value: Int) = Color(value)
        fun ofRGB(r: Int, g: Int, b: Int) = Color((r shl 16) or (g shl 8) or b)
    }
}

In Kotlin, the companion object is used to define static members or functions that belong to the class itself, rather than instances of the class. It's similar to Java's static members, but with more flexibility. In this example, the companion object allows us to define factory methods ofValue and ofRGB that can be called without creating an instance of the Color class.
By using a companion object, we can achieve similar functionality to Java's static factory methods, while also taking advantage of Kotlin's concise syntax and features.

Item 2: Consider a Builder When Faced with Many Constructor Parameters

Summary

When a class has many constructor parameters, it can be difficult to write and read client code. The builder pattern provides a more flexible and readable alternative.

Benefits

Readability: Client code is more readable, as the purpose of each parameter is clear.
Flexibility: Optional parameters can be omitted or specified in any order.
Immutability: The built object can be immutable, providing thread-safety benefits.

Java Implementation

public class NutritionFacts {
    private final int servingSize;
    private final int servings;
    private final int calories;
    private final int fat;
    private final int sodium;
    private final int carbohydrate;

    public static class Builder {
        private final int servingSize;
        private final int servings;
        private int calories = 0;
        private int fat = 0;
        private int sodium = 0;
        private int carbohydrate = 0;

        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }

        public Builder calories(int val) {
            calories = val;
            return this;
        }

        public Builder fat(int val) {
            fat = val;
            return this;
        }

        public Builder sodium(int val) {
            sodium = val;
            return this;
        }

        public Builder carbohydrate(int val) {
            carbohydrate = val;
            return this;
        }

        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }

    private NutritionFacts(Builder builder) {
        servingSize = builder.servingSize;
        servings = builder.servings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }
}

// client code
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
        .calories(100)
        .sodium(35)
        .carbohydrate(27)
        .build();

Kotlin Implementation

class NutritionFacts(
    val servingSize: Int,
    val servings: Int,
    val calories: Int = 0,
    val fat: Int = 0,
    val sodium: Int = 0,
    val carbohydrate: Int = 0
)

// Client code
val cocaCola = NutritionFacts(
    servingSize = 240,
    servings = 8,
    calories = 100,
    sodium = 35,
    carbohydrate = 27
)

In Kotlin, we can leverage default parameter values to simplify the creation of objects with many parameters. This approach eliminates the need for a separate builder class.

Item 3: Enforce the Singleton Property with a Private Constructor or an Enum Type

Summary

A singleton is a class designed to have only one instance per JVM, providing a single global point of access. Enforcing this correctly avoids issues like duplicate instances with inconsistent state.

Private Constructor Approach

public class DatabaseConnection {
    public static final DatabaseConnection INSTANCE = new DatabaseConnection();

    private DatabaseConnection() {}

    public void connect() {
        System.out.println("Connected to database...");
    }
}

In this approach, the private constructor ensures that the class cannot be instantiated from outside. The INSTANCE field provides global access to the singleton instance.

Enum Approach

public enum DatabaseConnection {
    INSTANCE;

    public void connect() {
        System.out.println("Connected to database...");
    }
}

In this approach, the enum type ensures that only one instance is created. The INSTANCE field is implicitly public and provides global access to the singleton instance.

Benefits

Both approaches provide several benefits, including:

Thread-safety: Both approaches ensure that the singleton instance is thread-safe.
Serialization safety: The enum approach provides serialization safety, ensuring that the singleton property is preserved even after serialization and deserialization.

Client Code

public class Main {
    public static void main(String[] args) {
        DatabaseConnection dbConn = DatabaseConnection.INSTANCE;
        dbConn.connect();
    }
}

In this example, we access the singleton instance using the INSTANCE field and call the connect() method.

Kotlin Implementation

object DatabaseConnection {
    fun connect() {
        println("Connected to database...")
    }
}

// Client code
fun main() {
    DatabaseConnection.connect()
}

In Kotlin, we can use the object keyword to define a singleton. The object declaration ensures that only one instance is created, and provides global access to the singleton instance.
By using a private constructor or an enum type (or Kotlin's object declaration), you can enforce the singleton property and ensure that your class is instantiated exactly once.

Item 4: Enforce Noninstantiability with a Private Constructor

Summary

Some classes, such as utility classes, are designed to be used statically and should not be instantiated. To enforce noninstantiability, you can use a private constructor.

Example

public class UtilityClass {
    // Suppress default constructor for noninstantiability
    private UtilityClass() {
        throw new AssertionError();
    }

    public static void utilityMethod() {
        System.out.println("Utility method...");
    }
}

In this example, the private constructor ensures that the class cannot be instantiated from outside. The AssertionError thrown in the constructor makes it clear that instantiation is not intended.

Benefits

Using a private constructor to enforce noninstantiability provides several benefits, including:

Clear intent: The private constructor clearly communicates that the class is not intended to be instantiated.
Prevents instantiation: The private constructor prevents accidental instantiation of the class.

Best Practices

When enforcing noninstantiability, consider the following best practices:

Make the constructor private: Ensure that the constructor is private to prevent instantiation.
Throw an AssertionError: Throwing an AssertionError in the constructor makes it clear that instantiation is not intended.

Kotlin Implementation

class UtilityClass private constructor() {
    companion object {
        fun utilityMethod() {
            println("Utility method...")
        }
    }
}

// or

object UtilityClass {
    fun utilityMethod() {
        println("Utility method...")
    }
}

In Kotlin, you can enforce noninstantiability of a class either by declaring a private constructor or by using an object declaration. A private constructor restricts external code from creating instances of the class, which is useful for utility classes or any class that should not be instantiated. This approach explicitly indicates the intent that instantiation is disallowed. On the other hand, an object declaration defines a singleton class at the language level, guaranteeing a single instance without allowing any constructor calls. This is the preferred idiomatic way in Kotlin to enforce a single instance while preventing any instantiation.
Both approaches convey clear intent and ensure controlled access to the class instances, with the object declaration offering built-in thread safety and simpler syntax.

Item 5: Prefer Dependency Injection to Hardwiring Resources

Summary

Dependency injection is a design pattern that allows components to be loosely coupled, making it easier to test, maintain, and extend the system. Instead of hardwiring resources, prefer dependency injection to provide dependencies to a class.

Hardwiring Resources

public class MerriamWebster implements Dictionary {
    @Override
    public void define(String word) {
        System.out.println("Defining " + word + "...");
    }
}

public class Lexicon {
    private final Dictionary dictionary 

    public Lexicon() {
      this.dictionary = = new MerriamWebster();
    }

    public void lookup(String word) {
        dictionary.define(word);
    }
}

In this example, the Lexicon class is tightly coupled to the MerriamWebster dictionary. This makes it difficult to test or use the Lexicon class with a different dictionary.

Dependency Injection

public interface Dictionary {
    void define(String word);
}

public class MerriamWebster implements Dictionary {
    @Override
    public void define(String word) {
        System.out.println("Defining " + word + "...");
    }
}

public class Lexicon {
    private final Dictionary dictionary;

    public Lexicon(Dictionary dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }

    public void lookup(String word) {
        dictionary.define(word);
    }
}

// Client code
public class Main {
    public static void main(String[] args) {
        Dictionary dictionary = new MerriamWebster();
        Lexicon lexicon = new Lexicon(dictionary);
        lexicon.lookup("Hello");
    }
}

In this example, the Lexicon class is decoupled from the specific dictionary implementation. Instead, it depends on the Dictionary interface, which can be implemented by different dictionaries.

Benefits

Dependency injection provides several benefits, including:

Loose coupling: Components are decoupled, making it easier to test, maintain, and extend the system.
Testability: Components can be tested in isolation using mock dependencies.
Flexibility: Components can be used with different dependencies, making it easier to adapt to changing requirements.

Best Practices

When using dependency injection, consider the following best practices:

Use interfaces: Define interfaces for dependencies to decouple components from specific implementations.
Use constructor injection: Inject dependencies through constructors to ensure that components are properly initialized.

Kotlin Implementation

interface Dictionary {
    fun define(word: String)
}

class MerriamWebster : Dictionary {
    override fun define(word: String) {
      println("Defining $word...")
    }
}

class Lexicon(private val dictionary: Dictionary) {
    fun lookup(word: String) {
      dictionary.define(word)
    }
}

// Client code
fun main() {
    val dictionary: Dictionary = MerriamWebster()
    val lexicon = Lexicon(dictionary)
    lexicon.lookup("Hello")
}

In Kotlin, you can use dependency injection in a similar way to Java.
By preferring dependency injection to hardwiring resources, you can write more flexible, testable, and maintainable code.

Next Up

In our next post, we will cover Items 6-9 of Chapter-2. Stay tuned!