[Kde-games-devel] A design issue when using C++

[Inge Wallin]

On Tuesday 17 March 2009 12:25:29 Ian Wadham wrote:
> On Mon, 16 Mar 2009 9:48:21 pm Inge Wallin wrote:
> > On Saturday 14 March 2009 11:43:34 Kevin Krammer wrote:
> > > class EnemyView
> > > {
> > >   friend class LevelPlayer;
> > >
> > > public:
> > >   Directiony getDirection( int i, int j )
> > >  {
> > >     return mLevelPlayer->getEnemyDirectiony( i, j );
> > >   }
> > >
> > > private:
> > >   // Level Player is our friend and can thus call the private
> > > constructor // Nobody else can create instances of the view
> > >   EnemyView( LevelPlayer *levelPlayer ) : mLevelPlayer( levelPlayer )
> > > {}
> > >
> > >   LevelPlayer *mLevelPlayer;
> > > };
> > > <snip>
> >
> > Isn't this the classic Facade design pattern?  We have something similar
> > in Marble where we have a read-only facade to the main marble data store
> > called MarbleDataFacade.  I suggest you name your class not ...View, but
> > ...Facade instead.
>
> With respect, to both Kevin and Inge, I would not use either name.  That
> is because I think names in programs should be descriptive of *what*
> something is or does, rather than how it is implemented.  If there is
> some aspect of the implementation that needs to be recorded, such
> as use of the Facade pattern, I would mention it in the API doco or
> program comments.

You are of course right here.

> > (You can of course take a look at Marble to see the details there.)
>
> I did, and could not help thinking why not call it MarbleDataReadOnly
> or some such?  What if you later find a need for another facade, yielding
> a different subset of or mode-of-access to the Marble data?  What will
> you call the new facade?

This is not a bad idea, in fact.  I'll talk to tackat to hear his opinion. 

	-Inge