you might consider asking newbie questions in comp.lang.java.help

- More control and flexibility (the methods can check value ranges, can
ensure consistency with other values, can create a value on the fly, etc.)

- Hiding of the actual data type used to store the variable

- Methods can be overridden in subclasses

etc.

/Thomas

Unthinkingly creating public accessor methods for all private fields
would indeed destroy the point of making the field private.

An accessor method should operate on some externally visible/settable
attribute of the object. If that attribute happens to be directly
represented by a simple private field, the accessor methods will have
very simple implementations.

If a private field is just part of the implementation, it should not
have accessor methods at all.

In some cases, a field represents a public attribute, but other actions
are needed to keep data structures consistent when it changes. Or there
are conditions on when and how the field can change. For example, it
might have a limited range.

Even if, initially, a private field just represents some public
attribute, and its accessor methods are trivial, using accessor methods
keeps options open, for both the class and its subclasses.

Patricia

I believe that a lot of it has to do with style too.  It is a good
practice to not allow access to all your variables, then provide
accessor methods that make them changeable.  This also provides
consistancy in the code.  Also a huge reason to do it, is to verify
data that is being put in.  e.g.  If I have a variable in a class
called age, I know that someone's age should never be negative and
(depending on what I am doing) should probably never be over about 150.
So, if I ask them for their age, I can store it using the accessor
method and if it is outside of the range, I can throw an exception.

Another reason for making variables private, is for values that you
want the program to be able to access, but not change.  Then you can
provide a "getter" method that returns the value.

I would say that if possible, you should avoid providing access to your
class internals. Think about what you want to do with these values?

Many times you want to perform some calculation of a sort and write the
data back in the same class. This might be better off as a method of
this class which takes the external data as arguments.

Sometimes, you need to pass the value to another class. This might be a
place for the visitor pattern.

If you want to poll the data and if it matches certain conditions do
something, you might want to consider using listeners (with or without
event object).

A few good reasons to use accessors:
- you want to provide read-only access to primitive fields.
- you want to return a view of complex object
  (i.e. Collections.unmodifiableXXX(), Collections.checkedXXX())
- you want to provide write-only access for dependency-injection style
  configuration.
- you want to validate the value before you set it and throw
  exception or return status code if it's not legal.
- you want to keep internal consistency (e.g. invalidate cached
  derived value)
- if you use bean introspection (or use a library that does)
- if you want binary compatibility. Making field private after the
  fact and changing the access to accessor methods would break all
  3rd-party code which use your class.

The paragraph that follows is somewhat controversial. I've taken this
approach in my latest desktop app and so far it works fine, but I'd like
to hear if somebody can think of potential issues.

Sometimes what you need is really a data structure and not a class. In
this case - just use one, make a class with all public fields and don't
worry about flexibility. Every modern IDE supports refactorings, which
make it quite easy to replace field access with accessor invocation.
This makes the code less cluttered and I would say more 'semantic'.

cheers,
Dimitar