Do fluent interfaces violate the Law of Demeter?

Question

The wikipedia article about Law of Demeter says:

The law can be stated simply as "use only one dot".

However a simple example of a fluent interface may look like this:

static void Main(string[] args)
{
   new ZRLabs.Yael.Pipeline("cat.jpg")
        .Rotate(90)
        .Watermark("Monkey")
        .RoundCorners(100, Color.Bisque)
        .Save("test.png");
}

So does this goes together?

Answer 1

Not necessarily. "Only use one dot" is an inaccurate summary of the Law of Demeter.

The Law of Demeter discourages the use of multiple dots when each dot represents the result of a different object, e.g.:

• First dot is a method called from ObjectA, returning an object of type ObjectB
• Next dot is a method only available in ObjectB, returning an object of type ObjectC
• Next dot is a property available only in ObjectC
• ad infinitum

However, at least in my opinion, the Law of Demeter is not violated if the return object of each dot is still the same type as the original caller:

var List<SomeObj> list = new List<SomeObj>();
//initialize data here
return list.FindAll( i => i == someValue ).Sort( i1, i2 => i2 > i1).ToArray();

In the above example, both FindAll() and Sort() return the same type of object as the original list. The Law of Demeter is not violated: the list only talked to its immediate friends.

That being said not all fluent interfaces violate the Law of Demeter, just as long as they return the same type as their caller.

Answer 2

1) It does not violate it at all.

The code is equivalent to

var a = new ZRLabs.Yael.Pipeline("cat.jpg");
a = a.Rotate(90);
a = a.Watermark("Monkey");
a = a.RoundCorners(100, Color.Bisque);
a = a.Save("test.png");

2) As Good Ol' Phil Haack says : The Law of Demeter Is Not A Dot Counting Exercise

Answer 3

The spirit of Demeter's Law is that, given an object reference or class, you should avoid accessing the properties of a class that's more than one sub-property or method away since that will tightly couple the two classes, which might be unintended and can cause maintainability problems.

Fluent interfaces are an acceptable exception to the law since they're meant to be at least somewhat tightly coupled as all the properties and methods are the terms of a mini-language that are composed together to form functional sentences.

Answer 4

Yes, although you have to apply some pragmatism to the situation. I always take the Law of Demeter as a guideline as opposed to a rule.

Certainly you may well want to avoid the following:

CurrentCustomer.Orders[0].Manufacturer.Address.Email(text);

perhaps replace with:

CurrentCustomer.Orders[0].EmailManufacturer(text);

As more of us use ORM which generally presents the entire domain as an object graph it might be an idea to define acceptable "scope" for a particular object. Perhaps we should take the law of demeter to suggest that you shouldn't map the entire graph as reachable.

Answer 5

Well, the short definition of the law shortens it too much. The real "law" (in reality advice on good API design) basically says: Only access objects you created yourself, or were passed to you as an argument. Do not access objects indirectly through other objects. Methods of fluent interfaces often return the object itself, so they don't violate the law, if you use the object again. Other methods create objects for you, so there's no violation either.

Also note that the "law" is only a best practices advice for "classical" APIs. Fluent interfaces are a completely different approach to API design and can't be evaluated with the Law of Demeter.

Answer 6

There's no problem with your example. After all, you're rotating, watermarking, etc... always the same image. I believe you're talking to a Pipeline object all the while, so as long as your code only depends on the class of the Pipeline, you're not violating LoD.