Law Of Demeter Principle

Photo by Jake Espedido on Unsplash

The Law of Demeter is a software design principle that states that a component should not know about the inner or private details of the objects it directly communicates with or has a dependency on.

or in other words

The Law of Demeter states that you can talk to your friends, but not to your friend’s friends. This means objects should only know about things they directly have a relationship with

This principle is also known as the “Principle of Least Knowledge” or “Tell, Don’t Ask”.

“Law of Demeter” or “principle of least knowledge” which recommends not accessing dependencies of other objects directly. Instead, send a message to the object and they will pass the message to their dependencies if needed. This guideline helps you achieve loose coupling, making your code easier to develop, test, maintain, and extend.

Identifying Violations and Fixes:

In iOS development, violations of the Law of Demeter can occur when objects reach too deeply into the internal structure of other objects to perform tasks or retrieve data. Here are some common violations of the Law of Demeter in real-world and their fixes examples:

1. Accessing Nested Properties: Directly accessing properties of nested objects can lead to violations. For example:

// Violation
let cityName = user.profile.address.city 

Instead, the User object should provide methods or properties to access nested data, or encapsulate the behavior within the User class.

// Refactored
let cityName = user.firstName // Assuming firstName is a property of the User object

2- Chaining Method Calls: Chaining multiple method calls to navigate through object hierarchies can create tight coupling between objects. For example:

// Violation
let result = user.profile.address.getFormattedAddress()  

Instead, the User object should provide a method to encapsulate the internal details and access the method directly.

// Refactored
let result = user.getFormattedAddress()

3- Passing Objects Too Deeply: Passing objects too deeply into method parameters can lead to violations. For example:

// Violation
func updateUserProfile(user: User, profile: Profile) // Violation

Instead, the method should only accept the necessary data or interfaces required to perform its task, rather than the entire User or Profile object.

// Refactored
func updateUserProfile(userName: String, profileData: ProfileData)
 // Passing only necessary data

4- Cascading Dependencies: When one object depends on another, which in turn depends on yet another, it creates a cascading dependency chain. For example:

class A {
    let b: B
    init() {
        self.b = B()
    }
    func doSomething() {
        b.c.doSomethingElse() // Violation
    }
}

Instead, class A should interact with its immediate collaborators directly, without reaching into the internal structure of the class B or C.

// Refactored
class A {
    let b: B
    init(b: B) {
        self.b = b
    }
    func doSomething() {
        b.doSomethingElse()
    }
}

to keep it more simple you can remember Single Dot Rule: if there are more than 1 dots used to access any detail that prolly is a a violation of the principle

Conclusion

the Law of Demeter is a software design principle that encourages modular and maintainable code by restricting the visibility of an object’s internal details to other objects. By following this principle, code can become less tightly coupled and easier to test and maintain.