Java Multiple Inheritance without Source Code

Question

I have a class called Thing and a class called Robot. Thing has a public void setBlocksExit(). Robot has some methods I also desire.

I have extended Robot but I also want setBlocksExit() from Thing. I would make an interface that has setBlocksExit() and then make a class like:

public class C extends Robot implements BlockExit {}

The problem is I don't have access to the source code for Thing and Robot. I am using an educational package 'becker.jar' and all of the code is compiled so I can't access it to extract interfaces. What are my options?

@immibis No, it doesn't unfortunately. It's outrageous not to include source code in an educational package. Ah well... — Fred James, Mar 16 '15 at 21:31
1) You don't need the source code to 'extract' or use interfaces 2) There are library / class / JAR browsers 3) Java can be decompiled if you really want — user2864740, Mar 16 '15 at 21:36
Why do you need source code, just extend it and you have full access to modify (almost) anything. — Mordechai, Mar 16 '15 at 21:37
Do you need C to extend Robot? As you describe it, looks like your are subclassing Robot just for convenience, so you can easily access its methods. Could you include both Robot and Thing instead of subclassing any of them? — Renato, Mar 16 '15 at 21:37

score 3 · Answer 1 · answered Mar 16 '15 at 21:37

One alternative would be to wrap Robot and Thing in your own wrapper classes

public class MyRobot extends Robot implements IBlockingObject

and

public class MyThing extends Thing implements IBlockingObject

where you can force the interface

interface IBlockingObject{
   void setBlocksExit(boolean blocksExit);
}

Then you can use IBlockingObject reliably elsewhere in your code, without much overhead.

Another alternative would be to compose a class with both Robot and Thing as member fields

Something like

public class RobotThing extends IBlockingObject{
  // This is now a robot thing...
  private Robot mRobot;
  private Thing mThing;

  @Override 
  public void setBlocksExit(boolean blocksExit){ 
    mRobot.setBlocksExit(blocksExit);
    mThing.setBlocksExit(blocksExit);
  }
}

I assume the first would be more flexible for you in the long run.

score 1 · Accepted Answer · edited May 23 '17 at 12:22

Your options are the following:

Extend Thing and have a reference to a Robot which you delegate all Robot methods to.
Extend Robot and have a reference to a Thing object which you delegate setBlocksExit calls to.
Create a fresh class and have a reference to a Robot and a reference to a Thing and delegate calls to these two objects.

If you're using an IDE such as Eclipse you can even "extract interfaces" and generate delegate methods automatically.

Option 1:

class C extends Thing {
    final Robot robot;
    public C(Robot robot) {
        this.robot = robot;
    }

    public int robotMethod1() {
        return robot.robotMethod1();
    }

    ...
}

Option 2:

class C extends Robot {
    final Thing thing;
    public C(Thing thing) {
        this.thing = thing;
    }

    public void setBlocksExit(boolean flag) {
        return thing.setBlocksExit(flag);
    }

    ...
}

Option 3:

class C {
    final Thing thing;
    final Robot robot;
    public C(Thing thing, Robot robot) {
        this.thing = thing;
        this.robot = robot;
    }

    public void setBlocksExit(boolean flag) {
        return thing.setBlocksExit(flag);
    }

    public int robotMethod1() {
        return robot.robotMethod1();
    }
    ...
}

If you're using Eclipse you could use this feature:

Fast implement wrapping (delegate methods) in Eclipse?

I'm sure whatever IDE you're using has a similar feature.

This seems like a decent solution although I am not quite comprehending it. Could you please show me in code? — Fred James, Mar 16 '15 at 22:17
Quick question, what does 'flag' mean or is it just a placeholder name? if the method requires 4 arguments would I pass 4 placeholder names? Also, how are you returning in a void method? — Fred James, Mar 17 '15 at 00:16
Yes. `flag` is just a generic name for a boolean variable :-) You can probably come up with better names. — aioobe, Mar 17 '15 at 05:49

Java Multiple Inheritance without Source Code

2 Answers2