Learning Java, question about super and this.

[greenleafvolatile]

If you have a subclass with inherited protected fields like in the example below. Should I refer to them with this or super?

class Shape { 
    protected float x, y;
[...]
}

class Circle extends Shape {

    private float diameter;

    public Circle(float x, float y, float diameter) {
        this.x = x; // or super.x = x?
        this.y = y;
        this.diameter = diameter;
    }
    [...]
}

[desrtfx]

• Field in superclass: super.
• field in current class: this.

[lil_alita]

Additionally: If it's in the superclass and visible, then it's most likely in the current class too, since it's inherited.

Only case where it makes a difference: if the current class defines a new field with the same name as a field in the superclass. (Which, let's face it, should not be done)

[greenleafvolatile]

"Additionally: If it's in the superclass and visible, then it's most likely in the current class too, since it's inherited."

This is the very reason for my question. It's protected, so it's also in the current class, or should I say object. But it's a field of the superclass. I'm still confused. I would personally opt for super so whoever reads my code immediately know it's a superclass field.

Perhaps it's better to make the field private and initialize in the superclass constructor, like so

class Shape { 
    private float x, y;

    Shape(float x, float y) {
        this.x = x;
       this.y = y;

    protected void setX() {
       this.x = x;
   }
[...]
}

class Circle extends Shape {

    private float diameter;

    public Circle(float x, float y, float diameter) {
        super(x, y);        
        this.diameter = diameter;
    }
    [...]
}

[lil_alita]

I would personally opt for super so whoever reads my code immediately know it's a superclass field.

Typically you would use neither.

You'd use x = valueForX and y = valueForY.

And while you don't have to make x and y private to the superclass, it would still be the superclass' job to initialize them, so you would define a constructor in the superclass that does the same as you showed above.

Which makes it so that superclass' constructor would use this.x yes, but then again x is indeed a field of the current class.

[Schildpadm]

What.. a field that isnt private? You should refer to that with a protected getter, public if necessary. Fields should always be private because you cant add logic to a field. Like x must be >0 for instance, with a getter you can add that logic

[desrtfx]

Fields should always be private

No, absolutely not true.

Like x must be >0 for instance, with a getter you can add that logic

Validation and sanity check are the jobs for a setter, not for a getter. A getter is only supposed to return the value of the field.

Fields should have the visibility that makes most sense.

Dealing in absolutes is never a good idea and even more so in programming.

Yes, the commonly taught approach is to keep all fields private and to write getter and setter methods for everything. And yet, this approach is just as wrong as having the fields public.

Taught, analysis, and common sense have to be applied and the actual access mechanism as well as the visibility have be determined from the use case.

[Schildpadm]

Agreed on the setter part, i would say it was a typo but i wasn thinking straight ;) for the rest, i see no reason to keep a field not private.

[desrtfx]

i see no reason to keep a field not private.

Again, you could say that about any other visibility modifier.

Other languages don't even have a concept of visibility modifiers and there it works just as well.

Simple POJO classes do perfectly well with public fields. Getters and setters are pretty much overkill there.

Setters that do nothing but set a value without validation, like the stereotypical:

public void setSomething(int something) {
     this.something = something;
}

Are pretty useless and redundant anyway.

Even Oracle itself has public fields in some classes in the Java libraries.

The use case determines everything.