Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I have code that looks like this:

tr.t.findIndexSmoothed(arg0.getX(), arg0.getY());

"tr" and "t" are objects. Is it bad practice to reach all the way down the object hierarchy to call methods? The only reason I can think of is that is breaks encapsulation, and if that's the case, can anybody tell me why that poses a problem? Also, does this code structure inhibit performance in any way?

share|improve this question

marked as duplicate by gnat, Kilian Foth, GlenH7, Yusubov, MichaelT Sep 3 '13 at 13:02

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
If the t member inside the tr object is reachable (public) then you are not breaking encapsulation: the purpose of making a member (field or method) public is to allow direct access to it. –  Giorgio Aug 18 '13 at 18:40
    
Yes it is correct. Though if you abuse it, it can hinder readability and debugging (you get a NullPointerException, which is null, tr, tr.tor arg0?) –  SJuan76 Aug 18 '13 at 19:58

2 Answers 2

up vote 9 down vote accepted

The Law of Demeter suggests that you shouldn't call methods on objects two layers down like that.

The idea is that, in your case, you should have a method findIndexSmoothed on tr which in turn calls findIndexSmoothed on t.

What this does is makes your code adaptable. It means that the nature of tr.findIndexSmoothed can change without necessarily changing the nature of t.findIndexSmoothed, which may be called by other code you don't intend to change.

However, it is commonly noted that it's pretty rare you really need that adaptability, and you'll have put yourself in a position where maintenance of t.findIndexSmoothed now requires maintenance of tr.findIndexSmoothed so, in some cases, you will increase your workload.

So, the answer to your question, as so many style questions in programming, is: Use your common sense. Keep the Law of Demeter in mind, but never make it an inflexible truth.

share|improve this answer
    
Also you dont really have a choice when using apis and frameworks. It is just not worth it. So sometimes you will have chains of getX().getY().getZ() –  Kemoda Aug 19 '13 at 6:32
    
The linked article about LOD seems to ignore a fundamental issue: ownership. If a piece of code owns an object (typically by holding the only reference to it anywhere in the universe) and the object provides a place for its owner to store something, that place would be owned by the owner of the object containing it, and that owner would be entitled to use it just as it would one of its own fields. –  supercat Dec 17 at 22:55
    
@supercat: If I'm understanding what you mean, that's exactly what LoD advises you not to do. Each object should have only one owner, which should pass it to child objects as method parameters or expose methods that allow parent objects to access the "grandchild" indirectly. Again, I'm not arguing for the LoD as a hard-and-fast rule here, I'm explaining why there's no mention of multiple ownership in an article about the Law of Demeter -- because the two things are orthogonal. –  pdr Dec 18 at 18:46
    
@pdr: My my understanding, the main purpose of the Law of Demeter is to ensure that any change to some aspect of an object's state should go through the object in question. If a List<Car> holds one element--a reference to the 592nd object created since startup, which is a Car whose Color is "blue", then the state encapsulated by that List<Car> is the fact that item #0 holds a reference to Object #592. Code which owns the List<Car> might care about the fact that Object #592 has a Color of "blue", but that information is not part of the state of the List<Car>. –  supercat Dec 18 at 19:04
    
@pdr: By my understanding of LoD, it would suggest that rather than asking the list for element 0, and asking the returned item its color, one should ask the list for the color of element 0. The problem with that concept is that the list has no idea what a Car or a Color is. All it knows is that it holds a reference to Object #592. A class which encapsulated the states of many cars, and allowed client code to examine or manipulate them without exposing references, could be more safely shareable than List<Car>, but unless it needs to be shared would not be worth the trouble to code. –  supercat Dec 18 at 19:14

I think there is nothing wrong with it as long as it makes sense from the design point of view. Just ask yourself those questions:

  1. Is it sensible for tr to contain and expose t?
  2. Is findIndexSmoothed() the responsibility of t?

If you answer yes to both of the questions then it is a way to go. Only thing I would do differently is to make t private and access it via getter.

Also I think it actually makes sense with the single responsibility principle. What if t had 5 different methods? would you delegate all of those from tr? how would you name them? findIndexSmoothedInTr()?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.