This content has been marked as final. Show 4 replies
Also, you shouldn't be worried about performance too much when you're learning, you'll learn that with experience.
Funny how people today still worry about performance as if they're targeting a 386 computer. Back then it made sense to unroll some stuff. But we've moved on about 20 years, computers have become a tiny bit faster...
Considering performance which is better getter/setters or public?The performance you should be considering in this case is the performance of the development/testing/debugging team.
It has been well established for several decades that global variables == undebuggable code. Last time I used one was in about 1987.
As the others wrote this is not a question of performance.
Java objects rougthly split up in 2 categories depending on their usage: DataTransferObjects (DTO) and others.
DTOs don't have any logic. They just carry values (primitives or any object type) from one object to another typically between application layers.
You meigt consider public read access to members with this ones but in that case you should declare the members <tt>final</tt> and set them in the constructor. On the other hand, since getters (and setters) are easily created bye modern IDEs with a fiew clicks there is no point in avoiding them, not eaven performance.
Any other object type should never be in need to allow read access to the member variables it carries. This is almost ever a violation of the information hiding praradigma OOP is all about (the only exception here is a derivated class in which case you should use a proteced getter). The only way to achief this is declaring the members private and use setters (or the constructor again) to assign values to them from the outside.