You may haven’t heard about this law or if you have, you may have wondered who’s this Demeter guy. Regardless of it, the Law Of Demeter (LoD) is a foundation concept that’s used among several design patterns, to wit: Delegate, Proxy, Façade, Adapter and Decorator. Therefore, you probably are already taking advantage of this Law, knowing it or not.
There’s a particular situation that occurs with iOS, that’s perfect for applying the LoD. Sometimes it’s needed to call method in our UIApplicationDelegate
. The common way of doing that is the following:
1 2 3 4 5 |
|
There are too many temporary objects, and presumably, there’s no reason why this class should know about AppDelegate
casting and so on.
Using the Decorator
pattern, is a way to wrap up this logic and decouple stuff.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Now the class would just call UIApplication.doSomething()
or AppDelegate.doSomething()
.
Another situation that’s a claimer for LoD is when you have chained ‘get’ statements, for example:
1
|
|
In such a case, the Metallica
class should be refactored and provide it with a mean of calling Metallica().gimmeThatWhichIDesire()
, for example:
1 2 3 4 5 6 7 8 9 |
|
Wrapping up method calls, separating concerns and decoupling classes are the spine of LoD. Some can say that objects become more complex, but one thing is for sure, your software components will be more testable, and that is a big win!
Now go ahead and follow the rule!