Law of Demeter expects to make the loosest coupling between classes.
This implies that 90% of all getters/setters exposing in class must be “deleted” and replaced by “behavior-contained” method. Indeed, it corresponds to “tell, don’t ask” philosophy because client is not expected to treat behavior itself through help of poor getter/setter methods.
This reduces duplicated code also if the same action is used elsewhere.
This implies huge classes with many many behavioral methods and overuse of delegation if we want to respect Single-Responsibility principle.
On the other hand, visitor pattern definition is :
Visitor lets you define a new operation without changing the classes of the elements on which it operates.
So, at first sight, it seems to be the contrary of Law of Demeter expectations :
-
One (Visitor) implies class structure to provide getter/setter so that Visitor can modify object’s states without touching to class itself.
-
Other (Demeter) encourages to enclose all behavioral codes directly related to object in the same class.
So my question is :
When can we consider that a class is closed for modification and thus stop adding behavioral methods on it and so prefer to add them in a newly created Visitor with the great risk that client use getters/setters instead of behavioral methods already exposed before in initial class?
The short answer is no.
First, I don’t think “tell, don’t ask” says that you should remove all your getters and setters, but that you should remove them if they don’t add any value or expose the internal state. So, as an example, getters should try as much as possible to return immutable data. An example with setters is adjusment or policy objects, these are objects that are not needed for an instance to work properly, but if provided, they change the behaviour.
Second, I’ve never seen a description of the visitor pattern that implies that the visited object should have getters and setters, so the visitor can modify them. As with any other object, the idea is to use the visited object public API to do any extension. Implying otherwise definitely goes against encapsulation too.
On another subject, I’m a bit confused about your last paragraph, as I don’t know if you’re talking about the open/closed principle, or about how to build a feature using the visitor pattern.
One note, I think the key is to understand that SOLID, the Law of Demeter and all other practices are good practices rather than best practices (‘best practices’ is a marketing term). If you take any of these practices to the extreme, they will probably end up hurting the readability or maintainability of the code.
(by the way, nice question :D)
The benefit of the open/closed principle applies mostly to code that is going to be used by other people in ways that we can’t really anticipate (frameworks are an example of this). So if you’re writing a framework, you’ll need to add extension points and use a language feature to prevent the class be inherited (such as final in java or sealed in C#) or by just letting the developer override certain methods. The idea is to prevent a naive user from overriding an important bit of an object and making the framework break in unexpected ways. Some languages/frameworks laugh at this (e.g Ruby/Rails) and they encourage the user to open the classes to add or modify features (with quite some success).
If you’re writing an application (and you own the code), I would suggest you not pay too much attention to the open/closed principle, and focus on applying the Law of Demeter (to a sane extent :D).