Designing class hierarchy without multiple inheritance in Java [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I'm trying to figure out how to design the class hierarchy for a Carrier class I'm implementing.

I currently have an abstract base class Ca开发者_如何学Crrier.

I have another abstract class TimedCarrier(TC) which extends Carrier with timing and domain related information. Concrete classes extend from Carrier and TimedCarrier.

User requires a progress monitor, so I create an abstract class MonitoredCarrier(MC) which extends from Carrier. Concrete classes extend from Monitored Carrier.

That works fine for awhile until user requirements change. Now I require a MonitoredTimedCarrier. I obviously can't subclass both TC and MC. I'm thinking of implementing MC as an interface:

class TimedCarrier implements IMonitored
class Carrier implements IMonitored

(since that makes more sense to me in the context of this domain, I should be able to monitor Carriers whether or not they're timed), but MC is richly implemented class, and I will have to copy-paste all the methods into classes which used to extend from MC. I don't want to code duplicate.

How would I then solve this problem? Thanks.

[Edit]

TimedCarrier extends Carrier with a bunch of member variables and getter/setter methods. MonitoredCarrier extends Carrier with member variables, getter/setter methods, and a bunch of methods which work with the monitor.

class TimedCarrier extends Carrier {
    int var1..
    int var2..

    public void setVar1(int var1) {...}
    public int getVar1() {...}
    ....
}

class MonitoredCarrier extends Carrier {
    int var1..
    int var2..

    public void setVar1(int var1) {...}
    public int getVar1() {...}
    ....
    public void monitorSomething() {...}
    public void monitorOtherSomething() {...}
}

---

It sounds to me like you should be considering using delegation. For example, instead of a class extending TimedCarrier, it would just extend Carrier - but then be passed to the constructor of TimedCarrier as the delegated instance. TimedCarrier would then delegate operations but keep track of timing as well.

Ditto MonitoredCarrier.

Of course, without knowing the details of what's going on, it's hard to say exactly whether this is appropriate, but it's the kind of approach I've used several times successfully. (Do you need Carrier to be an abstract class rather than an interface, by the way? Would it perhaps make sense to have an interface and then an abstract class implementing the interface for common operations?)

---

I would approach it like this,

interface Timeable {....}
interface Monitorable {....}
interface Carrier {....}

And then go with this.

class TimedCarrier implements Carrier, Timeable {....}
class MonitoredCarrier implements Carrier, Monitorable {....}
class MonitoredTimedCarrier implements Carrier, Timeable, Monitorable {....}

Its not a far-fetched idea. Its everywhere in the Java API. Look at Runnable, Comparable and similar.

---

I would have Carrier, Timer and Monitor as interfaces so classes can implement whichever they need.

As for mixing in the functionality, you could make MonitoredTimedCarrier extend MonitoredCarrier and implement Timer, and then proxy all the Timer methods to an internal class which extends your abstract class with the functionality you need.

This is just one potential way, there are multiple design patterns that could help you here. Good luck!