views:

157

answers:

5

In C#, you can use properties to make a data field publicly accessible (allowing the user to directly access it), and yet retain the ability to perform data validation on those directly-accessed fields. Doese Java have something similar? For Instance, suppose there exists a C# class with the following implementation(see below):

public class newInt{

    public newInt(){...}

    public int x{
        get{ return this.x }
        set{ this.x = isValid(value) }
    }
}

private static int isValid(int value){...}

This definition in the class allows the user to "naturally" use the data field 'x' when retrieving values from it and assigning values to it. Below is how it would be used in main.

public class Test{

    public static void main(String[] args){

        newInt a = new newInt();
        a.x = 50;

        int b = a.x;
    }
}

The question is... can java do this as well? if so, what is it called?

+8  A: 

No.

That's why Java has getters/setters.

In C# you typically have something like:

public class SomeObject
{
    private string _title = "";

    public string Title { get { return _title; } set { _title = value; } }
}

// Or with Auto-Properties
public class SomeObjectAutoProperties
{
    public string Title { get; set; }
}

The Java getter/setter equivalent would be:

public class SomeObject
{
    private String _title = "";

    public string getTitle() { return _title; }

    public void setTitle(String value) { _title = value; }
}
Justin Niessner
In modern C# you'd be more likely to have `public string Title { get; set; }` :)
Jon Skeet
@Jon Very true. I thought about using auto-properties, but I wanted to show the backing private field so there was a Java analog.
Justin Niessner
I really really have problems to understand what's so cool about `auto properties` when public attributes would do. I mean, if you don't add any validation, and the `property` is already public, why don't better use: `public string Title;`?
OscarRyz
@Oscar - Because if you use auto-properties, you can add validation later if you find you have the need. If you used a public field, that would be a breaking change.
Justin Niessner
@Oscar, there are [a bunch of great questions and answers addressing just that](http://stackoverflow.com/questions/1180860/c-public-fields-versus-automatic-properties/1180870#1180870) here on SO. A few of the reasons: you can't databind to fields, changing a variable to a property is a breaking change if you ever change your mind, reflection interacts with fields in a different way than properties, and (most importantly?) fields can't be part of an interface.
Jeff Sternal
@Justin - I don't like the concept of using public fields, but it doesn't seem like it would be a breaking change; accessing a public field or a property of the same name would have the same syntax.
Jon
and... a breaking change .. is... ? .. what? :P :P something that makes your code not compile anymore? A get the point about reflection and somehow databind, they are C# specific problems don't they?
OscarRyz
@Justin : on the original answer. The problem with Java getters and setters is that you can't use them as if they were attributes, I mean you have to type `int b = o.getX(); o.setX( 10 );` I don't want to imply that make your answer wrong. Actually this is **the** correct answer and*unfotunately* the common idiom for Java. I would've like much better something like: `int b = o.x(); o.x(10)` :P but much of the reflection code relies on the method name startWith "set.." and "get.."
OscarRyz
@Oscar A breaking change is something that would break any code calling yours. If you had a public field that changed to a public Property, the assembly calling your code would need to be re-compiled to continue working.
Justin Niessner
@Justin got it... Thanks.
OscarRyz
+3  A: 

Nope, you would use getter and setter methods instead. This is a Java convention.

public class newInt {

    public newInt() {...}

    private int _x = 0;

    public int getX() {
        return this._x;
    }

    public void setX(int x) {
        this._x = isValid(x);
    }
}
Greg
+1  A: 

No. Java doesn't have properties. The Java idiom is to use mutator/accessor (getter/setter). Even though a lot of people are in favor of adding them, it is unlikely they will be included in the next version (Java 7).

Curiously, JavaFX has properties.

Keep in mind that when Java was born it borrowed a lot of ideas from C++. Thus some of the syntax and idioms are very similar to that language.

dustmachine
And likewise C# borrowed from Java and Smalltalk :) Ohh what lovely cycles you have
xximjasonxx
+1  A: 

There's the Java platform, and there's the Java language.

The Java language does not support properties (and probably never will), but you are not forced to use the Java language to work with the Java platform (just as you don't need to stick to C# in order to work with .NET platform).

Check:

And many others.

Fábio Batista
+1  A: 

No, it hasn't.

I really have a bit of a problem to understand this C# properties, because, I think one of the rules is to perform as less code as possible in them and since they are already public, why don't use public attributes instead?

So, your Java equivalent ( and probably ugly ) would be:

public class NewInt { // In Java class names start with uppercase by convention 
     public int x; 
}

And you use it like:

 NewInt ni = new NewInt();
 ni.x = 50;
 int b = ni.x;

There is something I'm missing that's for sure, but, most of the times this would do ( BTW I never code like this :P )

BTW

I don't really like getters and setters, but I accept them as part of the Java conventions.

I just would like they have used this instead:

 public class NewInt {
     private int x;
     public int x(){ 
         return this.x;
     }
     public void x(int value ) {
         this.x=value;
     }
  }

So the usage would've been:

  NewInt a = new NewInt();
  a.x(10);
  int b = a.x();

Probably in the next Java life.

OscarRyz
properties are not quite equivalent to public fields as accessing or mutating a property value in c# can be done as a method call. You can include other code whilst getting or setting a property value.
serg10