Suppose I have a series of methods across different classes that all use the same five core variables defined in my main method. I could chain these five variables as method arguments from one method to the next, or I could simply define these five variables as public class variables and reference their path each time I want to use them.

What is considered more readable, and what is more efficient it terms of processing time? These values will not change throughout their lifespan in the program and take the form of Boolean values, multidimensional int[] arrays, and single dimensional int[] arrays.


2 Answers 2


In this case, I would have to say create an object that holds them - like a "Data" class, which you can then instantiate. This provides a nice single point of access to the data. But, in this case, it does take up some extra space on the heap. (I'm not sure how concerned you should be with this though, java has automatic garbage collection)

Another advantage is that now your objects have to be less in-the-know about eachother. When you use a data object to encapsulate the data, you can send that to the method so your sender doesn't know exactly what the method will use. This is an advantage, as you can easily extend the method later to use some more information from the data object. Imagine the method only uses the boolean values and single-dimensional arrays, you really want your sender to know this? I'd say, just pass the data object, and trust the method to fetch the data it needs and perform the operations)

In this way, it's also easier to extend upon this. Do you suddenly, for one class, need more data? Add it to the data-object. Do you, at some point, wish to verify that all the data is correct? Add setter methods to the data object to protect it from flawwed input.

As I don't know how your program is designed exactly, this is what I would do considering all the information you have provided, and keeping in mind the option to expand upon your implementation in unforseen ways later on.

  • But, in this case, it does take up some extra space on the heap. The JVM does escape analysis and will allocate objects on the stack when it's possible. Even if it didn't, garbage collection time is proportional to the number of live objects, so you don't pay for short-lived heap objects that die by the time the GC runs.
    – Doval
    Commented Nov 20, 2014 at 14:24
  • Even better! Thanks for the comment, I was unaware the JVM did that :) Commented Nov 20, 2014 at 16:06

One multi-lingual/multi-platform programmer's thoughts ...

Are the methods in question in the same class as main? If so, they can manipulate the values regardless of the declared access (public/private....). So I assume your question refers to methods which are defined in some other classes. The performance impact of the various options will be irrelevant 99.99% of the time. Not worth spending brain cycles there.

If my main method needs read/write access to a group of variables and a group of methods in other classes need only read access to those variables, I'm inclined to think of the variables are being part of "the context" of all those computations. Defining a "context object" in main's class -- what Dylan called "Data" -- makes for neater source code, especially if the variables receive their value during context's initialization and these values are never changed. The question then becomes: do I pass the context as an argument when I call the methods or do I make it public/protected/package access?

The best reason for me to pass the context explicitly when I call the methods is that doing so makes it blatantly obvious that the methods use the context variables -- a programmer reading my code doesn't need to examine each and every method to determine whether it depends on the context. In that case I would explicitly declare the context private if I don't want it directly referenced from any subclass of main's class, or protected if I'm willing to permit a subclass to directly reference it -- because, for example, the subclass needs to extend the initialization logic for context.

If I decided not to worry about making that dependence obvious, I might declare the context to have package (I'm feeling a little wild and crazy) or public access (I'm completely high and throwing caution to the winds). Personally I favor getting crazy and high somewhere other than my code ;-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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