2

When writing an application(in java) that you intend to open source, is it generally a good idea to have a lot of getters & setters and make variables private? More specifically, if that were to be an android application, would the answer to the question above still hold?

Edit: If you guys could give me a concrete reason as to why its better, that would be awesome.

Labeeb Panampullan
  • 34,521
  • 28
  • 94
  • 112
Manish Burman
  • 3,069
  • 2
  • 30
  • 35
  • 4
    Always holds. Actually make your properties protected whenever you can. – Pentium10 Feb 23 '11 at 06:33
  • Why does it always hold? – Manish Burman Feb 23 '11 at 06:38
  • 1
    Bjarne Stroustrup has argued that private for DATA is the better choice, not protected. – JAL Feb 23 '11 at 06:49
  • 1
    possible duplicate of [Why use getters and setters?](http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) – Adeel Ansari Feb 23 '11 at 06:58
  • 6
    I usually find *less mutable* objects cleaner to work with -- e.g. don't just add a getter/setter to everything, but rather think about what *needs* to be exposed and how that can done cleanly. (As such, "a lot of getters & setters" sets off my code-smell flags.) –  Feb 23 '11 at 07:01
  • Also check: http://blog.leocad.io/post/why-you-shouldnt-use-getters-and-setters-on-android – Martin Marconcini Aug 20 '13 at 23:22

3 Answers3

8

If you are discussing getters & setters in ANDROID, check what android documentation tell:-
Avoid Internal Getters/Setters
On Android, this is a bad idea. Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.

Labeeb Panampullan
  • 34,521
  • 28
  • 94
  • 112
3

if all the private variables are expected to be accessed from out side then yes.

Suppose you have certain flags those aren't going to be used from outside then no need of getters/setters for those.

Also See

Community
  • 1
  • 1
jmj
  • 237,923
  • 42
  • 401
  • 438
  • I get the second part of your statement. My question is whether its better to have getters/setters instead of accessing variables directly especially if value checking doesn't matter. – Manish Burman Feb 23 '11 at 06:37
  • Yes.. always go for getters/setters it has its own advantages , today there is no need suppose tomorrow there need arise.. – jmj Feb 23 '11 at 06:38
  • You could still directly access the variables without having getters & setters. – Manish Burman Feb 23 '11 at 06:42
  • suppose tomorrow you need to add some checks over its value. then it will ***** up the code – jmj Feb 23 '11 at 06:44
  • its bettor because at some day, you might need some validation logic on these setters and getters. For example, you want to store date of birth, you can check this condition in setter that it should not be in future. – Adeel Feb 23 '11 at 06:45
3

Lets put it this way, you don't feel any need of having getters/setters and you plan to make your properties non-private. It doesn't appear to be any problem with this approach. But you must ask few questions to yourself.

  • Are you having any property whose value should undergo some checking before assignment? (Need for a setter)
  • Do you have any mutable property which you don't want to expose as it is? (Need for a getter)

Now, if you think your few properties need getters/setters, but not all. Then I would say create getter/setter for all of them for the sake of consistency. :)

Further see, Effective Java 2nd Edition,

  • Item 13: Minimize the accessibility of classes and members
  • Item 14: In public classes, use accessor methods, not public fields
  • Item 15: Minimize mutability
  • Item 38: Check parameters for validity
  • Item 56: Adhere to generally accepted naming conventions
Adeel Ansari
  • 39,541
  • 12
  • 93
  • 133