views:

13016

answers:

7

I'm new to Java, but have some OOP experience with ActionScript 3, so I'm trying to migrate relying on stuff I know.

In ActionScript 3 you can create getters and setters using the get and set keywords, meaning you create a method in the class and access data through a property of an instance of that class. I might sound complicated, but it's not. Here's an example:

class Dummy{

    private var _name:String;

    public function Dummy(name:String=null){
        this._name = name;
    }

    //getter
    public function get name():String{
        return _name;
    }

    //setter
    public function set name(value:String):void{
    //do some validation if necessary
        _name = value;
    }

}

And I would access name in an object as:

var dummy:Dummy = new Dummy("fred");
trace(dummy.name);//prints: fred
dummy.name = "lolo";//setter
trace(dummy.name);//getter

How would I do that in Java?

Just having some public fields is out of the question. I've noticed that there is this convention of using get and set in front of methods, which I'm OK with.

For example,

class Dummy{

    String _name;

    public void Dummy(){}

    public void Dummy(String name){
        _name = name;
    }

    public String getName(){
        return _name;
    }

    public void setName(String name){
        _name = name;
    }

}

Is there an equivalent of ActionScript 3 getter/setters in Java, as in accessing a private field as a field from an instance of the class, but having a method for implementing that internally in the class?

+6  A: 

Nope. AS3 getters and setters are an ECMAScript thing. In Java, you're stuck with the getVal() and setVal() style functions--there isn't any syntactic sugar to make things easy for you.

I think Eclipse can help auto-generating those types of things though...

zenazn
So does Netbeans with "Encapsulate Fields"
So does Emacs/JDEE with M-x jde-gen-get-set-methods.
Glenn
Yes--Your editor of choice can probably do the same thing. I heard M-x M-butterfly can even write the rest of the program for you :)
zenazn
+2  A: 

In Java, the only option you have without exposing the internals of your object is to make your own getters and setters as you have in your example.

The convention is to prepend get or set in front of the field which is being altered. So, as in your example, the field name would have getName and setName methods as their corresponding getter and setter, respectively.

coobird
+9  A: 

Your Java code is fine, except that you would,

There are no get and set keywords in Java as in your As3 example. Sorry, it doesn't get better than what you're doing already.

Corrected code:

class Dummy {
  private String name;

  public void Dummy() {}

  public void Dummy(String name) {
    this.name = name;
  }

  public String getName() {
    return this.name;
  }

  public void setName(String name) {
    this.name = name;
  }
}
Stephan202
Thanks for the link, I'll stick to the Java conventions when writing Java. And I promise to call properties fields when talking about Java ;)
George Profenza
@George Properties and fields are different concepts. A property may or may not be stored in a field (the area of a circle is a property, and there may be a getArea method, but internally it may be calculated from the radius).
Adam Jaskiewicz
@Adam I thought that functions of a class are referred to as methods(private, public, etc.) and variables of a class are referred to as properties/fields. I'm not 100% sure I follow you're example. You're saying that circle.area and circle.getArea() are both properties of a Circle class ? Thanks for pointing out that the properties and fields are different.
George Profenza
@George: the variables of a class are referred to as fields. A property is a more general concept. A property of a class *may* be stored explicitly in a field, but it can also be calculated on demand. To elaborate on the cirlce example: we may have a Cirlce class with one field which stores the radius. A circle has at least two properties (radius and area) but only the former is stored. The other can e.g. be queried using getArea() (which internally uses the radius field).
Stephan202
@Stephan Thanks! Got it now.
George Profenza
+3  A: 

Sadly, no, there isn't the equivalent language-level support in java.

The get* and set* patterns though are so established in java culture that you'll find strong IDE support for them (e.g., eclipse will make them for you automatically), and if you're working in something that uses the expression language first made for jsps (EL), then you'll be able to use the property notation to access getters and setters.

Daniel Martin
+1  A: 

I would consider not having the getter or setter as they don't do anything in your case except make the code more complicated. Here is an example without getters or setters.

class Dummy {
  public String name;
  public Dummy(String name) { this.name = name; }
}

Dummy dummy = new Dummy("fred");
System.out.println(dummy.name);//getter, prints: fred
dummy.name = "lolo";//setter
System.out.println(dummy.name);//getter, prints: lolo

IMHO Don't make things more complicated than you need to. It so often the case that adding complexity will suffer from You-Aint-Gonna-Need-It

Peter Lawrey
+1  A: 

Also before adding setters and getters, it might be a good idea to ask yourself why are you exposing the internal data of the Object in question.
I suggests you read this article - http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

KingInk
Take anything Alan Holub says with a huge grain of salt; he's an encapsulation-as-data-hiding extremist. If you're writing a simulation app, I agree that you don't want to expose state; but for other apps, think of encapsulation as data-protection (control changes to your data) vs data hiding (don't allow others to know you have data)
Scott Stanchfield
KingInk
+2  A: 

An IDE-independent way is to use Lombok, an annotation-based library that generates getters, setters, and even equals() and hashcode(). It does this for the compiler, but not in the source file, so you don't have to look at the methods, just use them.

drhorrible
Horrible design(weird red, many different and unsuitable fonts), handy tool! Thanks drhorrible !
George Profenza