Media Devices, 2.0
mkossick at gmx.de
Fri Sep 15 10:21:41 UTC 2006
On Friday, 15. September 2006 11:03, Jeff Mitchell wrote:
> As someone who's worked with the MediaBrowser class and authored a
> media device, I'll be the first to admit that the codebase is
> currently messy. This is primarily because it was written with iPods
> in mind, and not with awareness of the different needs and
> capabilities of various devices, which had to be tacked on later.
> I was thinking about this today and wanted to toss something on the
> mailing list for people to think about and discuss. Here's my idea:
> take advantage of abstract data types and multiple inheritance, and
> define a set of different capabilities interfaces that different
> devices can inherit. For instance, all media devices should inherit
> (e.g.) from MediaDeviceBase. If they can handle podcasts, they should
> also derive from (e.g.) PodcastCapableMediaDevice. Devices that
> support playlists can derive from (e.g.) PlaylistCapableMediaDevice.
> If they can use KIO for data transfers (and thus can handle slaves),
> they could derive from KIOCapableMediaDevice (this could be useful if
> either a native library or KIO could be used for transfers, and one is
The problem I see is that your proposal requires casting in the class which
has to handle the media devices.
> I'm not sure how this would affect linking times, but it does seem
> like this would make it easy to support device features that, as of
> yet, no one has thought of. Simply add a new interface, which should
> be very implementation-agnostic, and plugin authors can implement the
> interface at will. It's cleaner than cluttering up MediaDevice with
> tons of virtual or null functions, and would help make it clear which
> functions Amarok uses to support specific operations, so that plugin
> authors can easily figure out what functions they must override in
> order to support a feature on their device.
> Devices could easily be queried to see if they support a function by
> either casting, or simply having member variables corresponding to the
> different types of interfaces available, set to 0 by default and set
> to 1 if the device supports that interface.
Uh, no. That's not object-oriented at all. If we really have to check whether
a device supports a feature, provide a method like hasFeatureX() which
returns bool. You can provide a default implementation which returns false in
the base class, so the actual plugins don't have to override the method if
they don't support that feature. It would be even better if the manager
simply delegates to the media device plugins using the GoF strategy pattern.
> I look forward to hearing what you guys think, especially Martin and
> the various existin plugin authors.
> Amarok mailing list
> Amarok at kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the Amarok