The Pet Project - Monopoly (Part 3)

Wherever we wish to add a Player object to a list we do so by making the list entry refer to the object's address, i.e. we have std::list<Player*>. It works^[3], but one ends up with 'ugly' code having to de-reference or take addresses of objects whenever we use the list. We also enter an area of my own uncertainty - what happens when Player is becomes an abstract class and has HumanPlayer and ComputerPlayer derived from it. I have a niggling suspicion that this could end up with some implementation dependent code if we were comparing object addresses.

GOF definition of the Proxy pattern states that it "provides a surrogate or placeholder for another object to control access to it." Well this sounds like what is needed - if we have a PlayerProxy, which is value-based, and it and its copies are the placeholders for Player, we could declare it thus:

class Player;
class PlayerProxy 
{
public:
  PlayerProxy(Player& p) : myPlayer(p) {};
  PlayerProxy(PlayerProxy const& p) :
                 myPlayer(p.myPlayer) {}
  operator Player& () { return myPlayer; }

private:
  Player& myPlayer;
};

We can then use PlayerProxy whenever we want to put Players in an STL container. Note that the operator Player&() provides a mechanism to get the original Player object when its required. However we talked about 'ugly' code when using pointers and the above still requires us to deal with proxy objects separately from the original object - see example at top of next column:

Player me ("Nigel");
PlayerProxy myProxy(me); // Here,
std::list<PlayerProxy> thePlayers; // here
  thePlayers.push_back(myProxy); 
// and here we deal with the Proxy class or object.
  Player& currentPlayer(thePlayers.front()); 
// but we can get the original!

Another problem with this solution is that, if we're not careful, it is possible for the proxy object to reference a non-existent player:

PlayerProxy CreatePlayer(std::string name) {
  Player p(name);
  PlayerProxy pp(p);
  return pp;
}
foo {
  std::list<PlayerProxy> thePlayers;
  thePlayers.push_back(CreatePlayer("Nigel"));
// but the Player object no longer exists!
}

It would be much nicer if we could treat the proxy object as if it was the real player (but value-based) and let it control creation, lifetime and access to the real reference-based Player object. So I'm after a PlayerProxy, which controls the interface to a Player but the Player performs the actual implementation.

I've already stated I want to treat the proxy object as if it was the real player, so from now on I rename the classes. I shall use the class names Player and PlayerImplementation. Player now represents value-based objects; PlayerImplementation represents the reference-based object.

Warning: I now believe my next steps to be wrong, but I'm relating my experiences and this proved a slight, but nevertheless useful diversion.

Design Patterns (Ref [GoF]) describes Bridge thus "Decouple an abstraction from its implementation so that the two can vary independently".

So my (incorrect) train of thought was, "An abstract class (or better a pure abstract class) defines an interface, so let's define an interface but, rather than make it abstract, let's give it a bit of intelligence and responsibility about the creation of the implementation object". The interface class would be value-based, but only one 'implementation' object would get created. Without thinking too deeply we end up with something like:

class Player {
public:
  Player(std::string name) : myPlayerImp(
      new PlayerImplementation(name)){}

  Player(Player const& p) : 
      myPlayerImp(p.myPlayerImp) {}

  ~Player() {delete myPlayerImp; }
  int GetCash() {
    return myPlayerImp->GetCash();
  }
// etc
private:
  PlayerImplementation* myPlayerImp;
};
class PlayerImplementation 
{
public:
  PlayerImplementation (std::string name) : myName(name), myCash(1500) {}
  int GetCash (void) { return myCash; }
// etc
private:
PlayerImplementation (PlayerImplementation const&);
  PlayerImplementation& operator= (PlayerImplementation const&);
private:
  std::string myName;
  int myCash;
};

Of course we ought to think further! What happens in the following (rather contrived) case?

Player CreatePlayer (std::string name) 
{
  Player p (name);
  return p;
}

foo 
{
  Player aNewPlayer (CreatePlayer ("Nigel"));
}

Well, the creation of object p will create the implementation object then, on exit from CreatePlayer, p gets destroyed and the implementation object gets destroyed. We end up with aNewPlayer.myPlayerImp pointing to a non-existent PlayerImplementation object. We only want to destroy the PlayerImplementation when the final Player object, referencing it, is being destroyed. So we need to add a reference counting mechanism. I will not do this here - it's more than adequately covered by Scott Meyers in Ref [Meyers].

There's one more important point to note here. It goes back to my statement about giving the interface ("abstract") class Player "a bit of intelligence and responsibility". By doing this I'm not using the Bridge pattern at all. In fact I've simply turned it into a better Proxy pattern than my previous example. The differences from the original are:

If you wish to read more about the Bridge pattern and decoupling abstraction from implementation, then the case study in Ref [Martin] provides many examples of this.

Well this series of articles started out as a trilogy, but I'll look at the Visitor pattern and mention a quick word about UML and Monopoly in the fourth and final part of the trilogy!