The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Q. on the design of inheritance in Java

Java inheritance treats members and functions differently. If I have:

class SuperClass {
    String s = "SuperString";
    void print() {
        System.out.println("In SuperClass");

class SubClass extends SuperClass {
    String s = "SubString";
    void print() {
        System.out.println("in SubClass");

SuperClass t = new SubClass();

Will output:
in SubClass

Which means, among other things, that implementing getters and setters could, in theory, change the behavior of a program.

Is there a good reason to implement subclasing like that? ? Why would anyone ever want to use " functions style" inheritance?

Or where the java designers drunk when they wrote the specs?
Monday, October 17, 2005
I suspect this has less to do than the desing of inheritance than to the difference between static binding and dynamic binding. The static class of the variable 't' is SuperClass, the compiler does the binding for the access of t.s, the dynamic type of t is SubClass and so the dispatch, according to the dynamic typ is as expected.

Here is perhaps another good reason never to ever ever access fields directly from and outside class. The other good reason is of course it violates the abstraction that an object provides you.
Monday, October 17, 2005
> nother good reason never to ever ever access fields directly from and outside class.

If another object needs a piece of information you are saying an object should give it? An object should include all possible operations on a a piece of infomation it contains?
son of parnas
Monday, October 17, 2005
Java's right, you're wrong.

In your SubClass you have 2 instances of s. When you print t.s you're accessing the SuperClass s.

If you want to print the same thing:
- make the SuperClass s protected
- assign values in constructors
Dino Send private email
Monday, October 17, 2005
Correction it's not 2 instances of s, but 2 strings with the name s: SuperClass.s & SubClass.s
Dino Send private email
Monday, October 17, 2005
Son of parnas: I assume that what Curtis meant by "directly" was by accessing a public member variable rather than by using a "get" method.  He's right: in this example, if you only access member variables via methods, you don't care and will never know that your subclass happens to have a member variable with the same name as your superclass.

To me, by the way, the example works exactly as it should.  If I'm "inside" a class (for example inside the print() method of the subclass) and I refer to a member variable, I would expect to get the most local one.  If I'm "outside", and am referring to the class by the superclass type, I would expect to get the variable local to the superclass.  How else would it work?

Remember that there ain't no such animal as member variable overriding.  :)  If you want to "mask" a public member variable in a superclass, well, you can't.  Either use a get/set method, or refer to the class by the subclass type.  Or include a method in the superclass that allows its children to change the value of that member variable, and do that when you create the subclass.
Jacob Send private email
Monday, October 17, 2005
Another way of putting it:
All methods in Java are virtual.
John Haren Send private email
Monday, October 17, 2005
This brings about another question for me:

With all of the little enhancements to Java that arrived with JDK 5, why didn't they give us properties?

The implementation proposals that I've (generally just jotted on napkins by coworkers) look something like this:

class MyClass {
  public property String myProperty;
  public property String myOtherProp;
  // This method overrides the implicit setter created
  // by the myOtherProp property. The implicit getter
  // will still work.
  public void setMyOtherProp(String p) {
      this.myOtherProp = p.toLowerCase();

class SomeOtherClass {
  MyClass myObject = new MyClass();
  // The property creates an implicit getter & setter
  String x = myObject.getMyProperty();

I keep wondering why there are no JSRs for properties in Java. Anybody know anything about that?
BenjiSmith Send private email
Monday, October 17, 2005
Thank you all for your comments.

Now see the logic behind this. Is does offer maximum flexibility to the programmer.

String s = "SubString"    In my example above seems like a natural way to “override” the value of s, but I am creating a new object… I should write this in the constructor to get the effect I was expecting.
Tuesday, October 18, 2005
"I keep wondering why there are no JSRs for properties in Java."

It is a little strange.  They were already halfway there with JSPs, where you don't have to explicitly call the getter method to access a field in a POJO (though there has to be a getter there).  There doesn't seem to be any reason to not do it, unless they're trying to stick with TOOWTDI.  :-P
Matt Brown
Tuesday, October 18, 2005
"Why getters and setters?"

In larger systems, you may want events to trigger when a value changes.

I almost never implement them.  I tend to use a vector of objects that are notified on a change, which is even better design-wise.  It usually means I don't have to subclass.
Tuesday, October 18, 2005
In my code, I avoid defining member variables of the same name in a class and its subclass. Also, my member variables are generally private, except for public static final constants.

With those guidelines, inheritance behavior of member variables doesn't matter.
Tuesday, October 18, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz