16

Does Java natively support properties, like C#? Or when coding in Java, when trying to encapsulate variables, you are constrained to do it by getVariable() and setVariable() kinda methods?

Thanks

Yves M.
  • 29,855
  • 23
  • 108
  • 144
devoured elysium
  • 101,373
  • 131
  • 340
  • 557

5 Answers5

18

No

You don't have the concept of Properties in the Java language. You need to use getters and setters..

stiank81
  • 25,418
  • 43
  • 131
  • 202
  • 2
    Almost: you have no language-level support, but properties are a well-defined concept in the Java beans specification and are defined via their getters/setters. – Joachim Sauer Feb 22 '10 at 17:21
  • 2
    Thanks for adding this, but I assumed were talking about the language Jave in this question. – stiank81 Feb 22 '10 at 17:22
  • 1
    And I agree with that assumption. But still, I'd like to avoid giving the impression that there's nothing like properties in all of Java (the platform). While Java (the language) doesn't support it, it's not an unknown thing in the platform. – Joachim Sauer Feb 22 '10 at 17:23
4

Java does not support C# like properties. You need getters and setters, but be careful that you don't accidentally give your user access to the encapsulated data by returning a reference to the object instead of a reference to a copy of it.

chama
  • 5,973
  • 14
  • 61
  • 77
  • your advocating this: object x = something.getX(); if(x.equals(something.getX())) { // Can't happen } – brian Feb 22 '10 at 17:24
  • Hmm, I see. So should I always make deep copies of variables when returning from a getter? – devoured elysium Feb 22 '10 at 17:24
  • 2
    Nope, only if it is not safe to be changed outside. Thing is, for a primitive like 'int' you can just create a getter without a setter to protect your variable. But if you return a reference type (say, a collection) from your getter, the internal state of that object can be manipulated outside (something like member.getFriends().clear()) If you can not afford that, return a copy (or a read only wrapper). – Ekin Koc Feb 22 '10 at 17:36
  • 2
    How does this relate to C# vs Java properties? Ain't this common sense for any returned value? – Dykam Feb 22 '10 at 17:59
  • 2
    C# properties are just a syntactic sugar for getter and setter methods. No difference than Java there (except for the 10x better code). You're right, same thing applies to any kind of return value, no matter how you acquire them. – Ekin Koc Feb 22 '10 at 20:25
4

As the others said, no Java does not have properties per se. The accepted method is to use getters and setters. On a side note, Delphi has support for properties that is very similar to C#'s.

Definitely nothing like AutoProperties is supported in Java. Can't seem to find any mention of any future support for it either.

Bryce Fischer
  • 5,336
  • 9
  • 30
  • 36
2

Last time I checked, Java did not support properties.

brian
  • 1,080
  • 9
  • 7
0

C# properties are similar to Delphi properties for the simple reason that they were inspired by Delphi properties. Having one of the key people from Borland's Delphi team move to Microsoft and (help) design C# had of course nothing whatsoever to do with that :)

There was a proposal (several in fact) last year for adding C# style properties to Java, but those were effectively shot down by the community as being mere syntactic sugar with no real added value.

jwenting
  • 5,505
  • 2
  • 25
  • 30
  • not necessarilly. A lot of things just enable more obfuscation. tbh I rather like the properties in C#, but I can see why it could lead to problems not being able to differentiate in calling code between accessing a member and its getter/setter. If I've a derived class for example I'd possibly want to bypass the getter/setter and directly access the class member in some situations, for example in an overridden getter or setter or for performance reasons. – jwenting Mar 04 '10 at 13:26
  • 2
    It seems like in many cases, simple getters and setters can double the lines of code that classes really need. – Jon Onstott Jul 10 '12 at 21:58