10

At my internship one of my colleagues gave me a hint. I want to know if this is good practice.

What I was doing was creating classes that are used only for the values they contain and don't have any functions that actually do something (apart from having getters, setters and a constructor). I declared my variables like this:

public class ObjectIUse{
  Private String name;

  public ObjectIUse(String name){
    this.name = name;
  }

  public String getName(){
    return name;
  }
}

So I'm not using a setter because it should always stay the same. My colleague said that I can also do it this way:

public class ObjectIUse{
  public final String name;

  public ObjectIUse(String name){
    this.name = name;
  }
}

Because now we don't need to have any getters or setters because it is public, however it can also never be changed because it is final.

Which would be better? Or would it maybe be preferable to still make it private but also final? I mean all of the options work, obviously. I just want to know which is better and why.

WereWolfBoy
  • 498
  • 1
  • 4
  • 23
  • 3
    Make it private. Make it final. – MD Sayem Ahmed Mar 28 '13 at 12:47
  • 1
    What Sayem said. Public member variables are "considered harmful." When your object doesn't change (we say it is "immutable"), declare the member variable `final`. This forces you to set it in the constructor and prevents it from changing -- even if someone reflects your class instance. – Charles Forsythe Mar 28 '13 at 12:49
  • That was also what I thought would be the better option. What is your reasoning? – WereWolfBoy Mar 28 '13 at 12:49
  • 6
    As the Gandalf said to Frodo: "Keep it secret, keep it safe" – Tomislav Novoselec Mar 28 '13 at 12:50
  • private final BLABLABLA; – Marko Niciforovic Mar 28 '13 at 12:50
  • android recomends using public variables instead of getters and setters unlike java coding – Athul Harikumar Mar 28 '13 at 12:53
  • @droidhot and why it that? – WereWolfBoy Mar 28 '13 at 12:56
  • @WereWolfBoy accessing a variable directly is (potentially) faster than through a getter. – zapl Mar 28 '13 at 13:00
  • refer this http://developer.android.com/training/articles/perf-tips.html#internal_get_set it has the details @WereWolfBoy – Athul Harikumar Mar 28 '13 at 13:02
  • @zapl sure it is faster... but does it matter that much? It would probably be less than a (fraction of a) millisecond of difference... Itsn't safety a little more important than a (fraction of a) millisecond? – WereWolfBoy Mar 28 '13 at 13:03
  • @WereWolfBoy it depends. Sometimes those miliseconds make a difference, e.g. when you need to draw a new image every 16ms to achieve 60fps or more. And sometimes you just bundle data into an object to put it into e.g. a `List`. Those types of container objects don't need clear encapsulation IMHO as long as you use them only locally. – zapl Mar 28 '13 at 13:08
  • android previously didnt have inlining of getters and setters (added in ginger bread even though not fully fledged) so it gave a huge drawback -- currently you can use it sorry for not updating on that from bens answer (google jit dev) ref http://stackoverflow.com/a/4930538/1254628 – Athul Harikumar Mar 28 '13 at 13:10
  • @droidhot The articles seems to say that you should use them for private field access only: "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." – jprofitt Mar 28 '13 at 13:11
  • the article is out dated inlining have been added -- but still it was not just for in class but for objects too(but for interfaces only) the reason was the jit comp was not that fully fledged to inline those codes and was realy costly for a handheld device perfomance !! now inlining is available you can use getters and setters!! – Athul Harikumar Mar 28 '13 at 13:15

8 Answers8

8

Make the variable private, because by doing so you'll be encapsulating the variable in your class. This has many benefits, information hiding is among one, which you'll learn if you go to the above link.

If you want it to never change after creation, then make it final too.

MD Sayem Ahmed
  • 28,628
  • 27
  • 111
  • 178
  • I have already learned about encapsulation. I thought it was weird that they tried to teach me to make it public at my internship. I will still do it for their product, because they do it themselves. However I would never do it for my own projects. – WereWolfBoy Mar 28 '13 at 12:51
  • @WereWolfBoy: Yes, in production quality code you should always try to use private data members. And yes, it was weird that they tried to teach you while you were doing intern (I mean you are supposed to learn how to write production quality code while doing intern, right?). It's however OK to make it public in your test/play/pet projects, for example, but it's never OK in the production quality code. May be you should ask them about this...... – MD Sayem Ahmed Mar 28 '13 at 12:54
  • 2
    I would say that this person is a hacker, not a developer, and probably doesn't understand all the ramifications of his decission. And, having seen his advice, I would be weary about anything he/she told me in the future. But, keep in mind, as an intern, they will treat you like you don't know what you are talking about, so don't try to argue the point. – CodeChimp Mar 28 '13 at 13:08
4

This works now because a String is immutable. But what happens when you expose the reference to a mutable class and that class is not thread safe ?. You cant even return a defensive copy if you want to.

Not to mention this also breaks encapsulation. Use a private variable and getters.

Deepak Bala
  • 11,095
  • 2
  • 38
  • 49
1

Which would be better? Or would it maybe be preferable to still make it private but also final?

If you want to be successful developer, you should program correctly, efficiently and the most important securely. Security and performance is on the first place.

When you make it public you will break encapsulation that is very important and has many benefits. Every time you want to get property of Object, getters will become your friend.

Generally you shouldn't have direct access to properties of Object(only in extrem cases but also these can be solved in better way). Getters and Setters are designated for these purposes - preserve encapsulation and deal with objects securely.

final variables are usually used for data which are unchangeable during a time.

Simon Dorociak
  • 33,374
  • 10
  • 68
  • 106
1

The idea of not providing a setter method to a variable makes it a read-only field, that said, it means we can only read but not write, so making it a constant by the use of the final keyword summarizes it all.

I think a constant is better. final keyword improves performance. Read more here

tmwanik
  • 1,643
  • 14
  • 20
1

You should definitely have a getter and make your field private. That is what we call encapsulation.

Also by making it final and so not having a setter, your object is immutable, whic is a very good thing for parallel programming.

tibo
  • 5,326
  • 4
  • 37
  • 53
1

A proper use of encapsulation principle is to make all class fields private and access them via setters and getters. Other than that, you might want to add any additional logic when you're calling getName(). While second variant is sometimes used, the first one is better. Hope this helps.

Egor
  • 39,695
  • 10
  • 113
  • 130
1

I guess their reasoning is that having it public keeps the code simpler. Java gets criticised for being too verbose in situations like this. Over a language such as Javascript where this would (normally) always be public.

But that simplicity is a trade-off against having secure, stable and extendable code.

To see why that's important, take a look at a large-scale Javascript project that has been written with everything as public. Each class's code might be simple... but their relationships, and the resulting architecture, end up being a nightmare to maintain.

David Lavender
  • 8,021
  • 3
  • 35
  • 55
  • It is true that a lot of the things they make are website related... containing lots of javascript code. So it's probably because of that that they use it in java/android as well. – WereWolfBoy Mar 28 '13 at 13:09
0

I think it's depends. For example: if you use getter - you can override it. Sometimes it very usefull.

shapkin
  • 358
  • 3
  • 10