private String or public static String?

68,185

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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

Solution 5

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.

Share:
68,185
WereWolfBoy
Author by

WereWolfBoy

SOreadytohelp Graduated from the Hogeschool van Amsterdam (the netherlands) on August 2014. Currently employed. I have only been programming since I started studying in 2010. The programming languages I have some experience with are the following. (List not in any particular order) Java Android (which is still java.. pretty much) C C++ C# (Windows Phone and Windows Store) Actionscript php javascript html css python lua Yes I do know that not all of them are proper programming languages. Still counting them. ;)

Updated on March 29, 2020

Comments

  • WereWolfBoy
    WereWolfBoy about 4 years

    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
    WereWolfBoy about 11 years
    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.
  • MD Sayem Ahmed
    MD Sayem Ahmed about 11 years
    @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......
  • CodeChimp
    CodeChimp about 11 years
    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.
  • WereWolfBoy
    WereWolfBoy about 11 years
    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.