You need to break up the design more cleanly.

As DragonChild suggests, you ought to take a more component oriented approach, assembling the final product from base components.

I would probably have something along the lines of the following classes: CDPlayerInterface, RadioInterface, AudioDeviceInterface, CDPlayer, Radio, and RadioCDCombo. The Radio class would be a marriage of the RadioInterface and AudioDeviceInterface, the CDPlayer class would be a marriage of the CDPlayerInterface and the AudioDeviceInterface, and the RadioCDCombo class would be a marriage of CDPlayerInterface and RadioInterface and AudioDeviceInterface.

Or something like that... I'm not sure I like the specifics of my solution, but I think the general paradigm is better.

Comment on You need to break up the design more cleanly.

Replies are listed 'Best First'.
Re: You need to break up the design more cleanly. by BrowserUk (Patriarch) on Mar 07, 2005 at 14:52 UTC
See Re^5: Understanding 'Multiple Inheritance' (hindsight) Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply] [d/l]
Re: You need to break up the design more cleanly. by Anonymous Monk on Mar 08, 2005 at 09:21 UTC
you ought to take ... Ah, the classical fallacy. Whenever someone raises an objection against use of inheritance, or multiple inheritance, someone is bound to step up and say you should have redesigned your entire inheritance tree differently. Well, then you have missed one of the important aspects of OO: code reuse and encapsulation. You want to be able to take an existing Radio class, and an existing CDplayer class, and combine them into a Radio/CDplayer. Regardless how the Radio class and the CDplayer class are implemented. Hopefully, they are build using smaller units, and if I'm lucky, they share some parts as well. But ultimately, for me, as the constructor of the Radio/CDplayer, it shouldn't matter how the Radio and the CDplayer are implemented - that's what's encapsulation is about. I do have to care about overlap in the API - both classes may have an `on` method, and they both may have a `volume` method. My combined object probably wants two `on` methods (although they can't be both called 'on'), but on `volume` method. I do have to care about the interface, but I should not have to care about setting the volume - the inheriting classes will know. If I can only do (multiple) inheritance properly if I'm in full control of the entire inheritance tree, OO becomes utterly useless to me. I want to reuse code. Reuse code that I haven't written, and shouldn't need to inspect.	[reply]