In Java, can I make a constructor for non-extended instances?

Question

Let's say I have two Java classes:

class MyClass {
  public MyClass() {
    do_things();   
  }
}

class MyOther extends MyClass {
  public MyOther() {
    super(); // Will do_things().
  }
}

What if I want to do some things ONLY when the class is NOT extended? For example:

class MyClass {
  public MyClass() {
    do_things();
    if (!(this instanceof MyOther)) {// Ugly
      my_own_things();
    }
  }
}

class MyOther extends MyClass {
  public MyOther() {
    super(); // Will do_things() but not my_own_things.
  }
}

Is there a cleaner way to do that?

I'd argue then that you've broken the "is-a" relationship between the superclass and subclass. — Jim Garrison, Jan 24 '14 at 02:40
It seems that your inheritance relationship isn't too strong. then why to use inheritance? . A workaround you can always override that method `my_own_thigns` in `MyOther` to empty method.. but overriding a method in constructor is not a good practice — nachokk, Jan 24 '14 at 02:40
Well, I really do need both classes to do some things in common. There just might not be a way to test if an instance is further extended... — eje211, Jan 24 '14 at 02:42
This seems to be an [XY problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). I can't provide using a solution using inheritance cause it seems that your relationship between child and parent is not such relationship. I would reconsider making a new design — nachokk, Jan 24 '14 at 02:57
@eje211 If you explained what you _really_ want to accomplish (i.e. give a real use case) we might be able to help. You've narrowed the problem down to what _you_ believe is the right approach, when it most surely is not. — Jim Garrison, Jan 24 '14 at 03:40
@JimGarrison The real use case is much more complicated. But I've come to that conclusion: I'm putting things in the constructor that should not be there. The actual use case would lead to a completely different discussion. I think that the actual conclusion is: "It's not possible and it's not possible for a good reason." — eje211, Jan 24 '14 at 05:47

score 0 · Answer 1 · answered Jan 24 '14 at 02:47

It seems exchanging subclass with superclass would seem appropriate here. No type-check would be required this way.

If your some other functionality is being broken due to this (I assume you are at an early design phase in your project), then I'd recommend you to seriously reconsider design.

Hope this helps. Good luck.

score 0 · Accepted Answer · answered Jan 24 '14 at 02:52

If the super-class has to know about its sub-classes before they exist, then you're choosing circular dependencies, which in my view, unless you really know what you're doing, is almost always bad design. In order to fix a problem anywhere, you have to fix every problem everywhere, or nothing in the dependency-chain will function.

This also alludes to the problem of calling interface functions directly in the constructor, which is A Bad Thing, because once that function is overridden, the super-version will never be called again.

Although I have no idea what you're actually trying to achieve here, this might be a better design for you:

class MyClass {
  public MyClass() {
    do_thingsMC();   
  }
  public void do_things()  {
     do_thingsMC();
  }
  protected void do_thingsMC()  {
     //Do super-things only
  }
}

class MyOther extends MyClass {
  public MyOther() {
     super();
     do_thingsMO();
  }
  public void do_things()  {
     super.do_things();
     do_thingsMO();
  }
  protected void do_thingsMO()  {
     //Do sub-things only
  }
}

Now the super-things can always be done when needed (by calling do_thingsMC()), as can sub-things (with do_thingsMO()), and publically, users of your code can be assured of being able to do everything (with do_things()).

This is what I need. I read this a couple of hours ago and I did not get it the first time, but this is EXACTLY it! Like so many StackOverflow issues, it seems obvious now that I have the answer: when a subclass calls its parent's constructor and that parent constructor calls a method that the subclass overrides, the parent constructor will call the overridden method, not the original one. This is it; and it's much simpler than what I expected. Thanks. — eje211, Jan 24 '14 at 08:01

In Java, can I make a constructor for non-extended instances?

2 Answers2