[Kde-games-devel] A new highscore manager - KScoreManager

[Parker Coates]

On Thu, May 1, 2008 at 14:23, Albert Astals Cid <aacid at kde.org> wrote:
> A Dijous 01 Maig 2008, Parker Coates va escriure:
>> 2008/5/1 Matt Williams <matt at milliams.com>:
>> >  After some discussion with Albert, I've separated the UI from the
>> > management even further. The functions for accessing the information
>> > about the scores has now been made private. I've then created an abstract
>> > class called KAbstractScoreBoard which is a friend of KScoreManager so
>> > that it can access its private functions. This way, whatever funky
>> > display widget you can think of will just have to subclass
>> > KAbstractScoreBoard.
>> >
>> >  This way, all the display based functions and enums can be moved to
>> >  KAbstractScoreBoard.
>>
>> Unfortunately, friendship isn't inherited.
>> (http://www.parashift.com/c++-faq-lite/friends.html#faq-14.4) So while
>> KAbstractScoreBoard will have friend access to KScoreManager, any
>> classes derived from it won't. I had thought of using friendship to
>> clean up the API a while ago, but couldn't find a way to make it work
>> other than declaring every possible display class a friend. But of
>> course this would mean new classes couldn't be added without modifying
>> the KScoreManager header, which is nasty.
>>
>> Unless, of course, Albert knows a way around this.
>
> We do not need to inherit friendship, we will access the KScoreManager private
> fields trough protected calls on KAbstractScoreBoard. That way you can have
> an unlimited number of KAbstractScoreBoard derived classes accessing
> KScoreManager private functions.
>
> Albert

Holy thread revival, Batman!

So I've started trying to implement this new high score system. I've
got the KScoreManager class roughly written and the basic
functionality seems to be there. So I've started on
KAbstractScoreBoard and KScoreBoardDialog, but that's where the
intricacies of OO design have slowed me down.

As the quoted mails mention, the decision was made to make all data
access methods in KScoreManager private for better encapsulation. All
access would happen through a friend class, KAbstractScoreBoard from
which all score UIs would inherit. But this isn't seeming as elegant
as it did originally.

Time for an example; we'll look at KScoreManager::scores(). This
method returns a QMap containing all the scores for all the score
groups, which is obviously data we'll be needing to fill our
KScoreBoardDialog. Our KScoreBoardDialog::fillBoard() method can't
simply call KScoreManager::scores() because that's a private method,
so we have to have add a function to the KAbstractScoreBoard base
class to get this information for us. So we end up with a method that
looks like this:

const QMap<QByteArray, QList<KScoreManager::ScoreInfo> >
KAbstractScoreBoard::scores() const
{
    return KScoreManager::self()->scores();
}

One such pass through function isn't too bad, but when you consider
that there are 4 or 5 other bits of info that will have to be
extracted from KScoreManager and that each will require their own
pass-through method, things look a bit kludgey. Maybe there's a more
elegant solution that I'm just not seeing. If so, please let me know.

At this point, I'm tempted to make KScoreManager's data access members
public, get rid of KAbstractScoreBoard and let the UI classes talk to
KScoreManager directly. Thoughts?

Parker