Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

You need to break up the design more cleanly.

by skyknight (Hermit)
on Mar 07, 2005 at 14:28 UTC ( [id://437217]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Understanding 'Multiple Inheritance'
in thread Understanding 'Multiple Inheritance'

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.

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
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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://437217]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (7)
As of 2024-03-29 14:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found