[Kde-games-devel] A design issue when using C++
Inge Wallin
inge at lysator.liu.se
Tue Mar 17 12:33:08 CET 2009
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
More information about the kde-games-devel
mailing list