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

[Albert Astals Cid]

A Dissabte 18 Octubre 2008, Parker Coates va escriure:
> 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?

Why is it kludgey? I mean what's the difference between

void KScoreBoardDialog::someMethod()
{
	... some code here ...
	foo = KAbstractScoreBoardDialog::foo();
	... some more code here ...
	bar = KAbstractScoreBoardDialog::bar();
	... even some more code here ...
}

That is going though KAbstractScoreBoardDialog to get the data

and

void KScoreBoardDialog::someMethod()
{
	... some code here ...
	foo = myKScoreManager->foo;
	... some more code here ...
	bar = myKScoreManager->bar;
	... even some more code here ...
}

that is what you are tempted to do?

It's the same amount of code, just that maintaining Binary Compatibility is 
almost impoosible with the second version.

Albert

>
> Parker
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel