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
    
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
add comment

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.

2 Answers

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
add comment

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
add comment

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