[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: OO design help
From: "Nathan Bradshaw" <nathanlbradshaw () gmail ! com>
Date: 2008-07-17 17:57:10
Message-ID: 92af7fc70807171057v4bf84cbap9113c5828b03e729 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Jul 17, 2008 at 4:31 AM, Sebastian Tr=FCg <trueg@k3b.org> wrote:
> On Tuesday 15 July 2008 13:35:27 Nathan Bradshaw wrote:
> > 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 probabl=
y
> > less functional way) the metadata structures in other applications.
>
> Just to clarify: are your libs using the interface or providing it?
Providing it. My thinking on this is that rather than try and force people
to implement a musicbrainz specific set of classes that will probably serve
as nothing more than transfer points between the m/brainz service and the
client app's own, more specialized, meta data class model my lib will just
provide a set of abstract interface classes that client apps can then
implement in what ever way makes most sense for them.
The musicbrainz lib would then just have a bunch of functions that it
performs against classes that implement the interface. The main operations
would be creation and visiting combined with update / creation (for example
when an existing local hierarchy is refreshed from the musicbrainz service,
say when an artist releases a new album)
>
>
> [If its the latter: Did you have a look at libkcddb (which has no
> maintainer
> AFAIK). Maybe you could build upon that?]
Nope, haven't looked at the cddb lib, will do when I get home from work
tonight.
>
>
> > 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 enoug=
h
> to
> > just specify in the artist interface that it return a reference to an
> > object implementing the releasecollection interface? This scares me a b=
it
> > as it means implementations will probably end up passing out handles to
> > member data structures. Is this a valid concern for an interface design=
er
> > or is that a problem that gets passed on to the client code?
>
> I think the proper encapsulation cannot be enforced completely be the
> interface designer. One could still code a class that would expose member=
s.
> QT4 tends to return shared copies of almost everything. This makes usage
> very
> easy and you don't have to care about exposing internal data members sinc=
e
> changes will return in a deep copy.
>
> More after clarifying the question above. ;)
I guess the area that I'm going back and forth on the most is how to model
the container classes in a way that doesn't force implementation decisions
on the client. If I define an interface that is essentially a subset of a
typical QList type container class with the basic accessors and modifiers
required for the lib to do it's job then clients can put regular containers=
,
databases or any other type of back end behind it, which is what I'm lookin=
g
for.
WRT encapsulation, my concern is that an interface class such as IArtist
would have to offer non-const access to an object that implements the
IReleaseList container, which in turn leads to exposing the IArtist
implementation's internals. Is this a valid concern?
cheers Sebastian :)
Nathan
>
>
> Cheers,
> Sebastian
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Jul 17, 2008 at 4:31 AM, \
Sebastian Trüg <<a href="mailto:trueg@k3b.org">trueg@k3b.org</a>> \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">On Tuesday \
15 July 2008 13:35:27 Nathan Bradshaw wrote:<br> > Hi all, one of the last things \
I want to do to finish up the KDE<br> > musicbrainz lib I've been building is \
to replace my local<br> > album/release/track classes with a set of interface \
classes that actual<br> > real software (rather than my toy test progs) can \
implement alongside<br> > whatever their native representation of music metadata \
is. My libs can then<br> > just operate on this interface and I won't be \
duplicating (in a probably<br> > less functional way) the metadata structures in \
other applications.<br> <br>
</div>Just to clarify: are your libs using the interface or providing \
it?</blockquote><div><br>Providing it. My thinking on this is that rather than try \
and force people to implement a musicbrainz specific set of classes that will \
probably serve as nothing more than transfer points between the m/brainz service and \
the client app's own, more specialized, meta data class model my lib will just \
provide a set of abstract interface classes that client apps can then implement in \
what ever way makes most sense for them.<br> <br>The musicbrainz lib would then just \
have a bunch of functions that it performs against classes that implement the \
interface. The main operations would be creation and visiting combined with update / \
creation (for example when an existing local hierarchy is refreshed from the \
musicbrainz service, say when an artist releases a new album)<br> \
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> <br>
[If its the latter: Did you have a look at libkcddb (which has no maintainer<br>
AFAIK). Maybe you could build upon that?]</blockquote><div><br>Nope, haven't \
looked at the cddb lib, will do when I get home from work \
tonight.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br>
<div class="Ih2E3d"><br>
> One thing that is getting me is when I try to come up with a way to<br>
> represent container classes for things like an artist's release \
collection.<br> > In an effort to not force implementation decisions on clients, \
it would<br> > seem that the way to go would be to specify a collection class \
that<br> > provided accessors, iterators etc and allow the client to specify \
the<br> > implementation (QList or what have you).<br>
><br>
> My other concern is how to represent the relationship between a higher<br>
> order class such as an artist and their release collection. Is it enough to<br>
> just specify in the artist interface that it return a reference to an<br>
> object implementing the releasecollection interface? This scares me a bit<br>
> as it means implementations will probably end up passing out handles to<br>
> member data structures. Is this a valid concern for an interface designer<br>
> or is that a problem that gets passed on to the client code?<br>
<br>
</div>I think the proper encapsulation cannot be enforced completely be the<br>
interface designer. One could still code a class that would expose members.<br>
QT4 tends to return shared copies of almost everything. This makes usage very<br>
easy and you don't have to care about exposing internal data members since<br>
changes will return in a deep copy.<br>
<br>
More after clarifying the question above. ;)</blockquote><div><br>I guess the area \
that I'm going back and forth on the most is how to model the container classes \
in a way that doesn't force implementation decisions on the client. If I define \
an interface that is essentially a subset of a typical QList type container class \
with the basic accessors and modifiers required for the lib to do it's job then \
clients can put regular containers, databases or any other type of back end behind \
it, which is what I'm looking for. <br> <br>WRT encapsulation, my concern \
is that an interface class such as IArtist would have to offer non-const access to an \
object that implements the IReleaseList container, which in turn leads to exposing \
the IArtist implementation's internals. Is this a valid concern?<br> \
</div><div><br><br>cheers Sebastian :)<br><br>Nathan<br> </div><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"><br> <br>
Cheers,<br>
Sebastian<br>
<br>
>> Visit <a href="http://mail.kde.org/mailman/listinfo/kde-devel#unsub" \
target="_blank">http://mail.kde.org/mailman/listinfo/kde-devel#unsub</a> to \
unsubscribe <<<br> </blockquote></div><br></div>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic