-4

To simulate some auto-generated classes which looks like this, I made a small jUnit test class to simulate inheritance and hidden fields.

public class ClassDerivationTest {

    @Test
    public void testChild() {

        ChildClass child = new ChildClass();

        // Implicit boolean as it is hiding the super value
        child.value = true;

        // one way to update the parent value
        // child.setParentVal("true");

        // child.super.value = "test";
    }

    public class ChildClass extends ParentClass {
        public boolean value;
    }

    public class ParentClass {
        public String name;
        public String value;
    }
}

My question is: is there any short way to assign the super class value field in a similar way like this:

child.super.value = "test";

instead than creating a specific setter in the ChildClass:

    // Imagine this method is not existing for the question
    public void setParentVal(String val) {
        super.value = val;
    }

I am using Java 7, and I am wondering if it would be possible without modifying the ChildClass nor the ParentClass (Like it could be auto-generated code).

UPDATE: I know you there are several ways to manage this by a) Casting according to Jon's answers: ((ParentClass) child).value = "test"; but not very well b) Instanciate the super class like this (as much as possible): ParentClass myInstance = new ChildClass(); The code myInstance.value will refer to the field in ParentClass

But I wanted to be more focused on the new features of Java 8. For example is it possible to resolve this with a lambda, or another new feature of Java 8?

рüффп
  • 5,172
  • 34
  • 67
  • 113
  • Is it strictly necessary that they be named the same thing? I'm thinking the correct solution for a child class that wants to set parent members would be to not override them in the first place. – Thomas May 05 '15 at 15:28
  • 8
    You're not overriding the parent field. You're hiding it. Polymorphism only works with methods. Not with fields. Using public fields is extremely bad practice. Just don't do it. – JB Nizet May 05 '15 at 15:29
  • 1
    @JBNizet It is bad practice, unless you call it "Data transfer object" and make a pattern out of it. You see, if you use a bean and have stupid getters and setters for those ... what is the essential difference to field access? Just the theoretical possibility to change the setter at some later point in time. – GhostCat May 05 '15 at 15:36
  • 2
    There are many differences: consistency with the other classes, ability to still add methods to the DTO (think getFullName() returning the concatenation of first and last name), ability to make the DTO immutable, ability to implement an interface, ability to use the DTO with frameworks relying on JavaBean conventions (JSP, etc.), ability to rename a field but still leave the old getter in place for easier migration, ability to add breakpoints or logging traces to getters and setters to know when the property is accessed, etc. – JB Nizet May 05 '15 at 15:42
  • I made the sample short but in fact I do not have too much control on the classes. Think about Jaxb autogenerated classes using `XmlAccessType.FIELD` as accessor type. I know this is not best practice at all but I was just wondering of some shortcuts were existing other than modifying the classes. – рüффп May 05 '15 at 15:52
  • And I agree with you: this is not my way how to design classes... I also tends to use private/protected fields and use getters/setters even there is more code (and Eclipse can still generate them very quickly). My question is more about "how to cope with bad design others made (when no refactoring is possible)" ;) – рüффп May 05 '15 at 15:59

1 Answers1

8

Well you can just cast child to make the compiler resolve the field value with respect to ParentClass instead of ChildClass:

((ParentClass) child).value = "test";

But frankly I would a) avoid non-private fields; b) avoid knowingly giving superclasses and subclasses fields with the same name.

Contrary to your comment, the subclass field doesn't "override" the superclass field - it hides it.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • @JoopEggen: Inheritance *is* involved (`ChildClass extends ParentClass`) but I agree that the subclass field hides the parent one - and I was just writing an edit to that effect. – Jon Skeet May 05 '15 at 15:31
  • Why should `protected` be avoided? I can understand `public` but just curious about `protected` being avoided as well. – Chetan Kinger May 05 '15 at 15:33
  • @ChetanKinger: IMO, fields are an implementation detail which should be restricted to the class itself. If I want to change that implementation later (rename the field, change its type) I should be able to do that without breaking subclasses. – Jon Skeet May 05 '15 at 15:34
  • So if I understand correctly fields should always be marked private and accessible through `public` or `protected` methods? – Chetan Kinger May 05 '15 at 15:42
  • 1
    @ChetanKinger: Well that's how *I* personally work, yes. – Jon Skeet May 05 '15 at 15:43
  • If the top user on stackoverflow as of this writing says that's the way to go, I can't argue with that! :) – Chetan Kinger May 05 '15 at 15:48