4 Replies Latest reply on Dec 3, 2012 11:31 AM by TPD-Opitz

    setters vs public


      Considering performance which is better getter/setters or public?

        • 1. Re: setters vs public
          No difference.

          Also, you shouldn't be worried about performance too much when you're learning, you'll learn that with experience.
          • 2. Re: setters vs public
            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...
            • 3. Re: setters vs public
              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.
              • 4. Re: setters vs public
                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.