Law of Demeter: Limiting Object Interactions for Cleaner Code

Introduction

Welcome to the third lesson of the Applying Clean Code Principles in Scala course. In our journey so far, we've discussed the importance of the DRY (Don't Repeat Yourself) principle for eliminating redundancy in code. We followed that with the KISS (Keep It Simple, Stupid) principle, which highlights the value of simplicity in software development. Today, our spotlight is on the Law of Demeter — a key guideline in object-oriented programming. By limiting the knowledge that an object has about other objects, this lesson will guide you in crafting more maintainable and modular code. 🤓

Understanding the Law of Demeter

The Law of Demeter was introduced by Karl J. Lieberherr and suggests that an object should only communicate with its immediate collaborators, avoiding the entire system. By reducing dependency between parts, you'll find your code easier to maintain and scale. In simple terms, a method X of the class C should only call methods of: Class C itself An object created by X An object passed as an argument to X An object held in an instance variable of C A constant defined in the class With these principles, you control how parts of your application interact, leading to a more organized structure. Let's explore how this works with examples. 🚀

First Rule Example

For the first point, a method should only access its own class's methods: Scala class Car: def start(): Unit = checkFuel() ignite() private def checkFuel(): Unit = println("Checking fuel level...") private def ignite(): Unit = println("Igniting the engine...") In this example, the start method interacts solely with methods within the Car class itself. This shows how you maintain clear boundaries by adhering to the Law of Demeter .

Second Rule Example

Next, a method can interact with the objects it creates: Scala class Library: def borrowBook(title: String): Book = val book = Book(title) book.issue() book class Book(val title: String): def issue(): Unit = println(s"Book issued: $title") Here, the Library class creates a Book and calls the issue method on it. This usage pattern complies with the Law of Demeter, where Library interacts with the newly created Book . 📚

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Continuing, let's look at interacting with objects passed as arguments:

Scala

class Printer:
  def print(document: Document): Unit =
    document.sendToPrinter()

class Document:
  def sendToPrinter(): Unit =
    println("Document is being printed...")

class Printer:
  def print(document: Document): Unit =
    document.sendToPrinter()

class Document:
  def sendToPrinter(): Unit =
    println("Document is being printed...")

The Printer class method print communicates with the Document object passed as an argument, aligning with the Law of Demeter by limiting communication to direct method parameters. 📄

Objects held in instance variables of a class can also be accessed:

Scala

class House:
  private val door = Door()

  def lockHouse(): Unit =
    door.close()

class Door:
  def close(): Unit =
    println("Door is closed.")

class House:
  private val door = Door()

  def lockHouse(): Unit =
    door.close()

class Door:
  def close(): Unit =
    println("Door is closed.")

In this example, the House class interacts with its door through the lockHouse method, showcasing compliance by interacting with an object it holds in an instance variable. 🏠

Finally, let's see a method interacting with class-level constants. While such constants are convenient, they should be used with understanding, as they can lead to shared state issues in larger applications:

Scala

object TemperatureConverter:
  private val ConversionFactor = 9.0 / 5.0

  def celsiusToFahrenheit(celsius: Int): Int =
    (celsius * ConversionFactor + 32).toInt

object TemperatureConverter:
  private val ConversionFactor = 9.0 / 5.0

  def celsiusToFahrenheit(celsius: Int): Int =
    (celsius * ConversionFactor + 32).toInt

Here, ConversionFactor is defined with val to indicate that it's a constant. This is compliant with the Law of Demeter when accessed within its domain. 🌡️

Here's an example that violates the Law of Demeter:

Scala

class Person(address: Address):
  def getAddressDetails(): String =
    s"Address: ${address.firstName} ${address.lastName}, ${address.street}, " +
    s"${address.city}, ${address.country}, ZipCode: ${address.zipCode}"

class Address(
    val firstName: String,
    val lastName: String,
    val street: String,
    val city: String,
    val country: String,
    val zipCode: String
)

In this case, Person is directly accessing multiple fields through Address, leading to tight coupling. Person relies on the internal structure of Address, which might result in fragile code.

Let's refactor the previous code to adhere to the Law of Demeter:

Scala

class Person(address: Address):
  def getAddressDetails(): String =
    address.fullAddress

class Address(
    val firstName: String,
    val lastName: String,
    val street: String,
    val city: String,
    val country: String,
    val zipCode: String
):
  def fullAddress: String =
    s"$firstName $lastName, $street, $city, $country, ZipCode: $zipCode"

By encapsulating all the address details within the fullAddress method in the Address class, the dependency is minimized, and Person no longer accesses the internals of Address directly.

The Law of Demeter plays a vital role in writing clean, modular code by ensuring objects only interact with their closest dependencies. By understanding and implementing these guidelines, you enhance the modularity and maintainability of your code. As you move on to the practice exercises, challenge yourself to apply these principles and evaluate your code's interactions. Keep these lessons in mind as essential steps toward mastering clean code! 🌟

Introduction

Understanding the Law of Demeter

First Rule Example

Second Rule Example

Join the 1M+ learners on CodeSignal

Third Rule Example

Fourth Rule Example

Fifth Rule Example

Violation Example

Refactored Example

Summary and Next Steps