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

List:       kde-devel
Subject:    Re: OO design help
From:       Sebastian =?utf-8?q?Tr=C3=BCg?= <trueg () k3b ! org>
Date:       2008-07-17 8:31:21
Message-ID: 200807171031.21772.trueg () k3b ! org
[Download RAW message or body]

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 probably
> less functional way) the metadata structures in other applications.

Just to clarify: are your libs using the interface or providing it?

[If its the latter: Did you have a look at libkcddb (which has no maintainer 
AFAIK). Maybe you could build upon that?]

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

I think the proper encapsulation cannot be enforced completely be the 
interface designer. One could still code a class that would expose members.
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 since 
changes will return in a deep copy.

More after clarifying the question above. ;)

Cheers,
Sebastian
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]