Demeter's law vs method chaining: when to use which?

Question

Given this code from the Symfony framework:

use Symfony\Component\HttpFoundation\Request;

public function indexAction(Request $request)
{
    $request->isXmlHttpRequest(); // is it an Ajax request?

    $request->getPreferredLanguage(array('en', 'fr'));

    // retrieve GET and POST variables respectively
    $request->query->get('page');
    $request->request->get('page');

    // retrieve SERVER variables
    $request->server->get('HTTP_HOST');

    // retrieves an instance of UploadedFile identified by foo
    $request->files->get('foo');

    // retrieve a COOKIE value
    $request->cookies->get('PHPSESSID');

    // retrieve an HTTP request header, with normalized, lowercase keys
    $request->headers->get('host');
    $request->headers->get('content_type');
}

I think this way of accessing for example the GET and POST variables is nice. You call the get() method on the query object which is part of the request object. I think the concept of method chaining is short and nice. However, I know the drawbacks of this tight coupling. Here, my controller claims to much knowledge on the method of the query object. That is, when the query object changes its method, I would need to change all these scripts. These drawbacks are manifested in the law of Demeter.

So what is the question? My question is, when there is so much description of "good practice" how come that such popular frameworks as Symfony decide against some of these rules. Or do I misinterpret the law of Demeter? I get the impression that sometimes good practice considerations to a degree depend on personal preference. Am I wrong?

Answer 1

First of all, the Law of Demeter should not be perceived as set-in-stone rule. Is your request's structure prone to changes? Is there any additional behavior that could be invoked when getting your $request's properties? If you get "no" to both answers, I don't think that violating this "law" is such a bad thing.

Or do I misinterpret the law of Demeter?

Probably. To better understand it, I think you could look no further than this.

Answer 2

You are not misinterpreting the Law of Demeter, your example is a good example of what the Law is against.

I do not believe that everything is a question of personal preference. I do believe that architectures / designs can be compared in some fixed context. Unfortunately this is only my opinion at this point :)

To your concrete question about why frameworks don't really give much thought to the LoD, and this from my Java Enterprise perspective:

1. Culture. Our developer culture is just dominated by other paradigms at the moment. It all came from the "Procedural" paradigm ("C", "Pascal", "Basic" and alike). Then people tried Object-Orientation for a while (the "Smalltalk" people), and its syntax was added to languages ("Java", "C++"). However we do not do OO. We do Component-based designs, Layered designs, Structured design, or even Procedural programming still. Therefore the LoD, which is a Law of Object-Orientation often does not apply.

2. Seeing no alternatives. There are just too few projects that really do Object-Orientation / Tell don't ask / LoD. There are just not that many examples for people to learn from.

Here is my own article on Law of Demeter. I basically agree with Yegor's article, it can be summarized as: don't write getters.

Ps.: Just to comment on Martin Fowler's "occasionally useful suggestion of Demeter" tweet. It's occasionally useful if you are only occasionally doing Object-Orientation. If you are using Object-Orientation, then you have to follow LoD.