General Question: What is so bad about public members?

Question

Hello
In many books the authors mention that using public member variables is generally a bad idea and that getter and setter methods should be used instead.
I don't see the advantage in this. As long as the getter and setter methods don't do anything else than return and set the value of an variable, how can it be better to access them by methods instead of directly accessing the field? Using methods means always more code to write.
Can anyone explain me what's the advantages of getter and setter methods?
Some code to illustrate what I mean:
This is supposed to be bad:
class Person {
  public int age;
}And should be replaced by this:
class Person {
  private int age;
  public int getAge() {
     return age;
   public void setAge(int age) {
     this.age = age;
}

Answer 1

duffymo said
While all of jschell's points are well taken, I think
the previous comments listing situations where data
members should not be made public are still valid.dhall said
Objects with value semantics should generally be
immutable (which brings up a whole other debate).The above two points were how the Value Object Pattern stated it.
Both of those have a certain place and are certainly appropriate for some objects (and some designs.) The DTO pattern no longer requires that. Probably for the same reason that I stopped doing the same thing years ago - it is inconvenient and doesn't pay off in terms of maintenance. Sometimes it actually does help, but most of the time it doesn't. And because of that the extra code gets in the way.
My usual pattern these days is to make the attributes public and also provide convienence methods which might consist of any or all of the following...
- A getter and setter (some people like them and since I generate all the DTOs adding more methods is trivial.)
- Conversion methods (set a date attribute using a fixed format date string)
- toString(), used for log/trace
- Validation method (usually a single method) that does the following...
----- Field validation, like validate a required field has a value, validate a telephone number has the correct format (length, etc)
----- Simple record validation, like if the telephone number field is set then the type of telephone number field is also set.
Notice that the above does not require any interaction with other signficant objects. And the above also exist solely as convenienence methods that could just as easily be placed in another helper class.
An example of what a DTO should not do is when a customer DTO verifies the account number exists when the account number field is set. This could certainly be a required validation test. But such a validation requires a level of complexity that exceeds the intent of a DTO.
I don't think it ever comes down to getters/setters
the only way OR the source of all evil. Each case has
to be judged on its own merits. The important thing
is to understand both sides of the issue and to be
aware of the consequences.
Except for the case I made above - although I didn't explain it well enough.
If most of the classes in the system have getters and setters then one of two things is true.
- They are not being used, so they shouldn't exist.
- They are being used, so something is wrong with the design.