0

Possible Duplicate:
Why use getters and setters?

I'm reading the Java for Dummies 2nd edition, and it says that it's better to define accessor methods for class's variables instead of making them public. Is that true?

Community
  • 1
  • 1
Nick Shvelidze
  • 1,564
  • 1
  • 14
  • 28
  • 2
    possible duplicate of [Why use getters and setters?](http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) and http://stackoverflow.com/questions/2252573... and http://stackoverflow.com/questions/1461598... and http://stackoverflow.com/questions/10407877... and... – Tomasz Nurkiewicz May 27 '12 at 19:01

6 Answers6

3

Yes.

Defining accessor methods allows you greater flexibility. For instance, you can make it publicly readable, but only privately writable.

Here's a Skeet answer to this particular question. He suggests always making your fields private

Community
  • 1
  • 1
gobernador
  • 5,659
  • 3
  • 32
  • 51
  • so java doesn't have `readonly` ? – Nick Shvelidze May 27 '12 at 19:03
  • No, but defining public reader methods essentially replicates the functionality. It also makes for a better API. – gobernador May 27 '12 at 19:05
  • if I am not mistaken `final` can be used as `readonly` – Pshemo May 27 '12 at 19:13
  • 2
    Well, `final` doesn't necessarily mean `readonly`. What it means is that we are setting off a certain block of memory for this field, and that memory block's _boundaries_ may not change. Now, the bits within that memory block may change, but the field may not change to refer to refer to a different object. Note that for primitives, such as `int` and `double`, this means that the value is a constant because each value is treated as a distinct instance of the `Integer` and `Double` class respectively. – gobernador May 27 '12 at 19:17
1

Yes, it's a convention.

It allow you to control how other classes will access the members (that are usually private). For example you can start with a basic get/set that return and set the value. But maybe later in the project you will want to add more control. in this case you will only have to change get/set method instead of refractoring all your project.

alain.janinm
  • 19,951
  • 10
  • 65
  • 112
  • Elaborating on the above, it may be that initially the value comes from a simple field variable, but later on the getter returns some response calculated from other data instead of simply passing on contents of a field. Also, it could be that you refactor the initial field into a separate object, but still would like to provide the accessor also on this (now) higher-level object. If you use the accessor methods already from the start, you only need to refactor the provider side, not the consumer. – Juha Laiho May 27 '12 at 19:14
1

I'd go as far as to say it is better not to even have accessor methods either, if possible. Make the class do work on its own state rather than exposing it for another class to work with.

If you do have to expose state, accessor methods give you the opportunity to return a copy of the state rather than the actual object. This way calling classes wont be able to modify the state from outside, avoiding the issue of invariants being broken.

Robert
  • 8,406
  • 9
  • 38
  • 57
0

This is true!

In Java, it is common practice to declare class variables private, and then write public accessor and mutuator methods to control them outside of the class.

David Gay
  • 1,094
  • 2
  • 16
  • 32
0

It is usually good to make accessor methods, to regulate the data any other class (and anybody) can use.

Particularly in big projects, you want other classes only to use just a few of the many variables in the class, so you only make a few getter methods.

On the second hand, it makes the code cleaner, it is easier to see what is happening. Thirdly, it is harder to create your own bugs in your program by using the wrong variable, because in other classes there are less possible variables to choose from.

Hidde
  • 11,493
  • 8
  • 43
  • 68
0

I recommend reading about object oriented programming philosophy:

wikipedia:

When you define accessors you can write there some extra logic protecting the state of your objects.

Maciej Ziarko
  • 11,494
  • 13
  • 48
  • 69