[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    OO design help
From:       "Nathan Bradshaw" <nathanlbradshaw () gmail ! com>
Date:       2008-07-15 11:35:27
Message-ID: 92af7fc70807150435i62e5a17cg105fcb5f1faabd23 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi all, one of the last things I want to do to finish up the KDE musicbrainz
lib I've been building is to replace my local album/release/track classes
with a set of interface classes that actual real software (rather than my
toy test progs) can implement alongside whatever their native representation
of music metadata is. My libs can then just operate on this interface and I
won't be duplicating (in a probably less functional way) the metadata
structures in other applications.

Attached is a screen shot of the start of my interface class UML. The main
area I'm wrestling with is how to represent the class hierarchy of
artist(s)->release(s)->track(s) in such a way that:
- I don't force implementation decisions on clients
- I don't break encapsulation too badly

One thing that is getting me is when I try to come up with a way to
represent container classes for things like an artist's release collection.
In an effort to not force implementation decisions on clients, it would seem
that the way to go would be to specify a collection class that provided
accessors, iterators etc and allow the client to specify the implementation
(QList or what have you).

My other concern is how to represent the relationship between a higher order
class such as an artist and their release collection. Is it enough to just
specify in the artist interface that it return a reference to an object
implementing the releasecollection interface? This scares me a bit as it
means implementations will probably end up passing out handles to member
data structures. Is this a valid concern for an interface designer or is
that a problem that gets passed on to the client code?

would love to get some advice on all of this....

cheers
Nathan

[Attachment #5 (text/html)]

<div dir="ltr">Hi all, one of the last things I want to do to finish up the KDE \
musicbrainz lib I&#39;ve been building is to replace my local album/release/track \
classes with a set of interface classes that actual real software (rather than my toy \
test progs) can implement alongside whatever their native representation of music \
metadata is. My libs can then just operate on this interface and I won&#39;t be \
duplicating (in a probably less functional way) the metadata structures in other \
applications.<br> <br>Attached is a screen shot of the start of my interface class \
UML. The main area I&#39;m wrestling with is how to represent the class hierarchy of \
artist(s)-&gt;release(s)-&gt;track(s) in such a way that:<br>- I don&#39;t force \
                implementation decisions on clients<br>
- I don&#39;t break encapsulation too badly<br><br>One thing that is getting me is \
when I try to come up with a way to represent container classes for things like an \
artist&#39;s release collection. In an effort to not force implementation decisions \
on clients, it would seem that the way to go would be to specify a collection class \
that provided accessors, iterators etc and allow the client to specify the \
implementation (QList or what have you). <br> <br>My other concern is how to \
represent the relationship between a higher order class such as an artist and their \
release collection. Is it enough to just specify in the artist interface that it \
return a reference to an object implementing the releasecollection interface? This \
scares me a bit as it means implementations will probably end up passing out handles \
to member data structures. Is this a valid concern for an interface designer or is \
that a problem that gets passed on to the client code?<br> <br>would love to get some \
advice on all of this....<br><br>cheers<br>Nathan<br><br></div>


["uml1.png" (image/png)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]