7

Possible Duplicate:
Absence of property syntax in Java

See the following situation:

class Test extends Object {
    private int x;
    public getX() {return x;}
    public setX(int _x) {x = _x;}
}

As you can see, nothing special. However, I'd like to know if it's possible to keep that "private x" in a way that someone using the class don't need to use getX(), in other words, if I could map some variable that automatically called the gets and sets.

Something like the "property" in Delphi. It'd prevent the need of using setX() and getX() in a complex expression and would ease the understanding of who reads the expression.

For example, suppose another identifier xx and yy could be used in place of the get and set methods. See:

import Test;
public static void main(String[] args) {
    new Test() {
        setX(10);
        setY(20);
        int z = getX() * getY() + (getY() * getY());
        System.out.println("%d", z);
    }
    // would be like this
    new Test() {
        xx = 10;
        yy = 20;
        int z = xx * yy + (yy * yy); // xx would access the method getX() automatically
        System.out.println("%d", z);
    }
}

I hope you guys got what I mean here.

EDIT:

Rolly crepe! That's a lot of answers! Thank you very much, everyone.

Community
  • 1
  • 1
  • 1
    In Java, it is strongly recommended to make variables private and access using get/set than directly using. You may see advantage with this approach if your subclass has same attribute names. – kosa Dec 02 '12 at 13:11
  • 1
    or if you have good reason not to, just make it public – NimChimpsky Dec 02 '12 at 13:12
  • Either you want it to be private, or you don't. If you want it to be private, you don't want access to other classes. If you want access to other classes, don't make it `private`. – Peter Lawrey Dec 02 '12 at 13:31
  • @Nambari And what if your subclass has same **method** names? That's even worse. – Marko Topolnik Dec 02 '12 at 14:58

7 Answers7

19

you can access them, by using reflection,

Test test = new Test()
Field field = test.getClass().getDeclaredField("x");
field.setAccessible(true);

System.out.println(field.getName() + "="+field.get(test ));

but, you shouldn't do this

user902383
  • 8,420
  • 8
  • 43
  • 63
12

You can't.

That's why we talk in "encapsulation". Only if you change or modify from private to something else or if you use reflection (what would make it even more complicated).

I don't see any problem in using the famous getters and setters.

  • You are wrong. You can ! There are some situations wher you want to access private fields. Unit tests for example. – Mehdi Sep 16 '20 at 17:02
6

I think you're trying to idealize it like C# properties, as the following code, right?:

public sealed class Example {
    private int _code;
    private string _name;

    public Example(int code) {
        this._code = code;
    }

    public int Code {
        get {return this._code;}
        set {this._code = value;}
    }

    public string Name {
        set {this._name = value;}
        get {return this._name;}
    }

    public override string ToString() {
        return this._code.ToString();
    }
}

Up to now in Java I believe we don't have such resort, but also I don't see nothing wrong in using the getters and setters.

4

At most you can switch the private with protected so whatever inherit it can access it directly.

But yeah, you really can't. This property is associated to the method. It has to sport the parentheses () in Java. There's no way "yet" to do it like this in Java, it'd have to be some kind of pointer to a method.

3

Having a getter and setter already breaks encapsulation in spirit, so don't hesitate to use public fields. The argument "a day will come when you'll want validation in your setter, and you'll thank yourself for the visionary decision to have them" sounds plausible at the face of it, but in practice it is just a child's tale. I have written several thousand setters in my career; never one had to be added validation later on. If there was validation, it was always happening on the outside. This decouples the validation from the data and allows different rules for each use case.

Another idea is to keep the methods, but make the names real short: int x() and void x(int x).

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
2

Think in future you are going to not allowed to input minus values for x user who are going to use your variable x. In that case you have to have change setX with your validation and people who are already used that method won't get affected which is encapsulation. So highly reccomand you to use use public getter and setter while having private declaration.

someone
  • 6,577
  • 7
  • 37
  • 60
0

I will try to explain them...............

class Test extends Object

First of all you Don't have to use Test extends Object. Whenever you don't or do explicitly extends your class to any other class, it will always extend the Object Class, directly or indirectly.

- Ok now to your question, Well what you see here is called Encapsulation in its simplest and most basic form. In Java you can't do the way as you do it in Delphi or .Net.

Kumar Vivek Mitra
  • 33,294
  • 6
  • 48
  • 75