13

in Java it's convention (as far as I am concerned) to keep your field variables private and access them using getters and/or setters. This is so that you can set rules for changing the values of the variables.

But what if the variables are final? Example:

public class Test {

    public final int MY_INT;

    public Test(int myInt) {
        MY_INT = myInt;
    }

}

Would this be allowed? It is compiled and works fine, but is it considered good code?

Ludwig
  • 178
  • 1
  • 7

5 Answers5

17

This compiles but it's not considered good code.

MY_INT violates the naming convention: names with all caps are used for static final variables, also known as "class constants" (see this and this, Google's Java style guide too). to conform to naming conventions, it would be better to rename to myInt.

It's recommended to provide a getter to hide implementation details of your class. Interfaces contain only methods, not fields. If you let other classes refer to this field by name, then you lose the freedom to change the name or your internal representation later.

But most importantly, sub-classes cannot override fields, they can only override methods. If you provide a getter instead of a field, sub-classes will be able to override that and implement different behavior. So it would be better to provide a getter and forbid direct access to the field itself.

(Thanks to @Sotirios Delimanolis for the coding style guide links, much appreciated!)

Community
  • 1
  • 1
janos
  • 120,954
  • 29
  • 226
  • 236
  • Are you sure? I have always thought that all constants should be uppercase. – Ludwig Dec 26 '14 at 19:11
  • 3
    I think the most appropriate answer to whether or not this should be capitalized is explained on another SE site: http://programmers.stackexchange.com/questions/252243/naming-convention-final-fields-not-static – nmagerko Dec 26 '14 at 19:13
  • 1
    @Ludwig yes, absolutely. The [relevant](http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367) [docs](http://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html) are not exactly easy to read, but the all caps convention is only for `static final` variables ("class constants"), not for `final`. In the post linked by @nmagerko, @MichaelT makes an excellent point about the serialization logic. – janos Dec 26 '14 at 19:20
  • 1
    Also, check out [Google's Java styleguide](https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.2.4-constant-names). – Sotirios Delimanolis Dec 26 '14 at 19:21
  • To see what the accepted convention is, examine Java's `Math` class. This class has two constants: `PI` and `E`. Both are static and final and variables are capitalized. In contrast, the `rand` field is static, but not final AND it is lowercase. To summarize, all three fields are static, but only the CONSTANTS are capitalized. To summarize, the OP's mistake was that constants should also be static. If you think about it, there isn't really a good reason for class constants to be non-static. But the naming convention wasn't violated. – hfontanez May 15 '19 at 15:35
6

The provider answers are incomplete (even the one selected as "the answer"). Consider what would happen if the field in question was a Collection or an array of objects. It is a good practice to make ALL fields private and provide "getters" for these fields. But more specifically, your getter should return a (immutable) reference to the field (i.e. String), OR a defensive copy of mutable fields (i.e. array of objects). This is because, even if you cannot change the base address of the object in question, you can change the internals of the object (array or collection) by simply getting the base address. Keep in mind that by mutable fields I do not mean arrays or collections only. It applies to ANY mutable class.

Going back to the question, are getters REQUIRED? The answer is no. HOWEVER, if you want to have robust code, it is on your best interest to follow these best practices; even if it is just to create good habits. Unless you practice them regularly, you will not follow good practices when you code (and most likely others in your project won't either).

hfontanez
  • 5,774
  • 2
  • 25
  • 37
5

If the client could access the public field in your question before it had a value assigned to it (i.e., without calling the constructor), there would be an obvious issue. Specifically, this field could not have an expected/proper value when a client tried to access it. Nonetheless, as has been pointed out in the comments, you have not declared Test.MY_INT with a static identifier, making it essentially impossible for the value of this constant to be retrieved without first calling the constructor.

Therefore, it would appear sensible (in terms of immutability) to do what you are doing. However, in terms of "good code," you are (as others have said) forcing yourself and your clients to refer to this value explicitly by name. If you were using a getter, though, and needed to change the name of MY_INT while keeping the purpose of the constant the same, neither you nor your client would be forced to change anything beyond the implementation in Test.

To be more explicit, I provide your class with a getter and privatized constant.

public class Test {

    private final int MY_INT;

    public Test(int myInt) {
        MY_INT = myInt;
    }

    public int getAssignedIntValue() {
        return MY_INT;
    }

}

I would get the assigned integer value like so:

Test test = new Test(1);
// with your class
test.MY_INT;
// with the above class    
test.getAssignedIntValue();

Now, say I rename MY_INT to myInt to match naming conventions. In both cases, I have to change all occurrences of MY_INT in the Test class. But, the difference between the two implementations becomes clear when I need to get the value with the new constant name:

// if this is the old code from above
Test test = new Test(1);
// I need to change this to test.myInt, or I get an ERROR!
test.MY_INT;
// since I didn't change the name of the getter, all is well
test.getAssignedIntValue();

Note: while this may have been an acceptable answer, it does not necessarily have the most applicable reasoning. Please see this answer for reasoning given in a more general context.

Community
  • 1
  • 1
nmagerko
  • 6,586
  • 12
  • 46
  • 71
  • 3
    They would fail pretty fast at accessing it without an instance. – Sotirios Delimanolis Dec 26 '14 at 19:15
  • `Test.MY_INT` is still valid, despite what comes after, is it not? Please elaborate, if you have a chance – nmagerko Dec 26 '14 at 19:18
  • 2
    Nope. It wouldn't even come up in an IDE autosuggest. – Sotirios Delimanolis Dec 26 '14 at 19:19
  • Considering that this is not declared with `static`, you are correct. I have updated my answer to reflect this. – nmagerko Dec 26 '14 at 19:24
  • Your edit negates everything you said previously. In their example, `MY_INT` cannot be accessed without an instance, which cannot be created and initialized without invoking the single constructor. The field name character case, for the reasons you've given, is not a strong enough reason to make it `private` and encapsulate its retrieval in a getter. – Sotirios Delimanolis Dec 26 '14 at 19:32
4

Yes you can. As long as you do not initialize that variable at class level or from other setters.

JBaba
  • 590
  • 10
  • 30
4

I personally don't like public fields unless your class is just a data class. Your class is immutable but are you sure you will never want to make it mutable. If one day for some reason you need a mutable copy it is easier to have both mutable and immutable copies with getters and setters.

If you have public fields clients will use your fields in their code and you wont be able to change their names in future.

You are breaking encapsulation this way.

b4da
  • 3,010
  • 4
  • 27
  • 34