1

So what do you think?

My Java lecturer said that properties should always be declared private and there is no reason why it should be done any other way. I immediately started to think inheritance, how it would affect to that.

PPPHP
  • 747
  • 10
  • 20
  • As for Java, there was [a very similar question](http://stackoverflow.com/questions/4920941/why-to-prefer-getter-and-setter-methods-for-variable-instead-of-making-it-public) just today that turned out to be [a duplicate](http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) anyway. The question it duplicates contains a lot of useful information though. – Sergei Tachenov Feb 07 '11 at 15:01

2 Answers2

3

Do you mean declaring the field to be private? If so, I agree with your lecturer, although "no reason" may be slightly overkill. There are very occasional reasons to use non-private fields - such as in private nested classes.

But yes, in a simple superclass/subclass relationship I would use getters/setters instead of making the field protected. It separates the implementation from the API exposed by the class - even to its subclasses.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    What is the reason to use non-private fields in private nested classes? Private fields of a nested class are accessible within the topmost level containing class anyway. – Sergei Tachenov Feb 07 '11 at 14:58
  • @Sergey: That's true in Java, yes - I was getting confused with C#, which does things the other way round. Although even in Java you end up with extra synthetic methods with no benefits... – Jon Skeet Feb 07 '11 at 15:09
  • I don't get it, end up with extra synthetic methods with no benefits when? – Sergei Tachenov Feb 07 '11 at 15:21
  • @Sergey: When you access a private field of a private static nested class in Java, from its containing class. – Jon Skeet Feb 07 '11 at 16:01
  • I still don't get it. Why would any methods be necessary at all? The fields are accessible, so you can just do `innerInstance.somePrivateField = someValue;` or alike, no setters or getters required. And if there are getters/setters, but they do more than just getting and setting, then they are no longer "synthetic", are they? In fact, I see no difference between private, protected and public in a private nested class in Java. They all aren't accessible from outside because the class itself is private. – Sergei Tachenov Feb 07 '11 at 16:14
  • 1
    @Sergey: They're accessible in the *language* but not in the JVM (which has no notion of inner classes). Try it and decompile the generated code with javap -c. – Jon Skeet Feb 07 '11 at 16:16
  • Awesome. I had no idea Java had such discrepancies between the language and JVM. – Sergei Tachenov Feb 07 '11 at 16:25
  • This is the price for bytecode compatibility. The inner classes were added later. – maaartinus Feb 07 '11 at 17:20
0

Private would prevent classes that extend the original class from accessing it directly. Generally speaking I think that protected is a better way to declare a variable if you expect to extend your original class and want the inheriting class to be able to directly modify that particular class member.

dmcnelis
  • 2,913
  • 1
  • 19
  • 28
  • 1
    The field should be private, Getters and setters could be protected or public depending on the use case. See Jon Skeet's answer ... – Guillaume Feb 07 '11 at 15:09
  • @Guillaume, even private getters and setters can be useful if they do more than just get or set. Or if it is likely that they will have to do more in the future. – Sergei Tachenov Feb 07 '11 at 15:13
  • @Sergey : I have to agree with you on that one. Yes, any visibility can have its use on a getter / setter ... – Guillaume Feb 07 '11 at 15:20