In Java, is it ever a bad idea to make an object&#

Question

I have a data class in my application. My application will never be used as a public API and I will be the only person developing code within my project.

I am trying to save every ounce of processor and memory power I can.

Is it a bad idea to make my data members in my data class to have public/protected/default protection so that I don't have to use a getter? Using a getter would require slightly more memory and creation of a stack and such...which I believe isn't necessary. The only reason I can see in using a getter is for protection/privacy, but if I'm the only coder and nobody else is going to be using my API, then is it a bad idea not to use the getters?

Please let me know if this is stupid.

Answer 1

The argument that this code is only going to be for your own use is a dead easy trap to fall into - this is the case with most code, the publicly exposed bits are usually very small. So assuming most code is for private use, why bother ever using private, protected, final, const (C/C++) - retorical question I know, but I hope the point is clear.

The other thing that is being missed here is locking. If you access the member directly you will only ever be able to lock this code at the whole object or the member level. And that locking will be in the control of the using code, not the Object itself. Maybe OK, maybe not, as in all things it's horses for courses.

Answer 2

In general: If you want to optimize something manually, you should consider architectural improvements rather than such microoptimisations. Microoptimistions can be in many cases done automatically by a tool.

For Java: There is ProGuard tool, that can do many optimizations. However, if you use a modern JVM (say HotSpot or OpenJDK), the JVM can do these optimizations Just-In-Time. If you have a long-running application, ProGuard will probably have a minor effect on the performance.

Answer 3

It's not stupid, but I'm thinking it's probably not a good idea either.

I understand the temptation...if no one else is ever using the code, then you don't need to worry about it. But time and time again, it turns out this just doesn't match with what actually happens...you find out that you'll be using it in more places than you thought, or the project becomes bigger than expected, or someone just gets ahold of it and thinks it's useful...things that were never meant to be permenant or public have a way of becoming that way.

Is there really that tight a limit on processor power and memory? I don't know about your situation (embedded app, perhaps?), but as an (overgeneralized) rule, you're better off looking elsewhere for resources...in your data structures, algorithms, or archetecture to see better improvements in memory or CPU.

Answer 4

Potential drawbacks for using

public final type var;

instead of

private final type var;

public type getvar() {return var ;}

(which I've personally experienced) include:

• The prospect -- however unlikely it seems now -- that the representation will need to change, in the base class or in some future subclass.

• The potential awkwardness of mixing exposed immutably- and mutable-typed fields.

• The bother of remembering which classes use public final and which use getvar .

• The bother of explaining this inconsistency to someone else who may later see the source code.

I've just never been able to convince myself that it's worth it, even though I've tried.

Answer 5

Python folks don't use getters and they're not burning in hell.

Getter/setter is a way to expose part of the class to Java's simple introspection. The Java Bean specification relies on having public getters and setters as a way to determine which attributes are important.

While essential for things that require/produce/use beans, it is not essential feature of OO programming or Java programming. It's just part of the Bean spec, and is required for any class that wants to participate in bean-like things.

Public attributes are fine. They're simple, direct and obvious.

Answer 6

At our team we use the following rule: if the state represented by a class field is mutable then always make it private and provide mutators; however, if it is immutable (i.e. would not be reassigned after class instantiation) then it can be declared as public final [type] [field-name] -- safe for accessing.

Pls note that here "immutable state" specifically means that field is declared as final. Should not be confused with public [immutable-type] [field-name] where one could perform reassignment albeit immutable-type instance is itself immutable.

Pls also note that there are many good reasons to have accessor even for an immutable field. For example, in cases where it is required to perform some action (e.g. security check) at the time when the field is read.