ryfar

The Law of Demeter is a definitive starting point for API design. But it’s also a great guideline for designing every layer of code, including your private classes and functions. This link points to Karl Lieberherr’s landing page for the Law of Demeter, but Wikipedia may have a more accessible description.

The fundamental concept of the Law of Demeter is that a class should only talk to its friends. That is, don’t do this:

[memberObject.somethingThisObjectKnowsAbout changeSomething:newValue];

Instead, do this:

[memberObject changeSomethingThisObjectKnowsAbout:newValue];

Why? What does this get you? What it gets you is reduced fragility of your class. That is, since the details of memberObject’s implementation are not of concern to your class, memberObject can change its implementation freely without affecting your class. In fact, memberObject can get rid of its somethingThisObjectKnowsAbout member entirely, and as long as its interface stays the same, your class won’t know the difference. It will blissfully continue to work properly with no changes.

The alternative is for you to have to change your class’s implementation when the implementation of memberObject changes. When memberObject decides to replace somethingThisObjectKnowsAbout with two different objects doing the job somethingThisObjectKnowsAbout used to do, you’ll need to change your class to talk to the right one. And changing code that shouldn’t need to change makes baby Jesus sad.