Methods for calling Java in an instance variable

There are two ways:

String salary = company.getPerson(id).getData().getSalary(); String postcode = company.getPerson(id).getData().getPostCode(); 

or

 Data data = company.getPerson(id).getData(); String salary = data.getSalary(); String postcode = data.getPostCode(); 

How and why? Any benefits besides reading?

+4
source share
8 answers

Id actually prefers the third option in case the person does not exist

 Person person = company.getPerson(id); if(person != null) { Data data = person.getData(); if(data != null) { String salary = data.getSalary(); String postcode = data.getPostCode(); } } 

It depends on whether there can be zero values ​​or not. If you can guarantee that there will be no null values, you can eliminate some / all null checks.

As another user points out in the comment below, there may be a case where none of the method calls can return null, in which case, if performance is not a problem, in my opinion this will be truly a personal preference.

I would probably prefer to separate them into separate calls, like me, even without null checks.

+7
source

If there is a possibility that the intermediate variable may be null, then you should use the second option along with the null check

 Data data = company.getPerson(id).getData(); if (data != null){ String salary = data.getSalary(); String postcode = data.getPostCode(); // other code here } 
+3
source

There is really no true good style; it depends on the context and on your needs.

Using:

  String salary = company.getPerson(id).getData().getSalary(); String postcode = company.getPerson(id).getData().getPostCode(); 

If you need to improve your memory usage .

Simple use:

 Data data = company.getPerson(id).getData(); String salary = data.getSalary(); String postcode = data.getPostCode(); 

If you want to increase productivity .

For readability, this is too subjective for me. There is both readable honestly.

The second example has the benefits of refracting company.getPerson(id) , and the variable also allows you to perform some validation without calling company.getPerson(id) again. I often prefer this style, but, again, depending on needs, the first solution might be better if getPersonne(id) and getData() cannot return null.

+3
source

It depends on the complexity of your production methods. If, for example, the getPerson (id) method is complex, or the getData () method is complex, this can lead to performance problems.

An intelligent compiler can solve this problem by eliminating the repetition of parts of the code. But in general, from my point of view, the second way is better.

+2
source

For refactoring / readability and performance, I personally consider this the best solution:

 Data data = company.getPerson(id).getData(); String salary = data.getSalary(); String postcode = data.getPostCode(); 
+1
source

You must consider performance. While "beautiful code" is great, if there is something expensive, get a link to it and reuse it.

It is likely that company.getPerson(id) includes a database query to retrieve the data, therefore, while the first option looks ahead of schedule, the second option is probably better.

But the answer is "it depends" - if every call is cheap, you can use the first option.

+1
source

One thing to consider is when getPerson (...) or getData () can return null. If any of them ever returns null, you will be rewarded with a NullPointerException exception, so the answer may depend on other hidden factors than ease of reading.

+1
source
  String salary = company.getPerson(id).getData().getSalary(); String postcode = company.getPerson(id).getData().getPostCode(); 

This is less readable, and the amount of data returned by company.getPerson(id).getData() is only executed at run time, so garbage collected will be at this time.

or

 Data data = company.getPerson(id).getData(); String salary = data.getSalary(); String postcode = data.getPostCode(); 

The above is more readable, but you create another reference variable of type Data , so for the garbage collection collector will check the link to the "data" on the heap, and then, if it finds it suitable, it will be collected.

+1
source

All Articles