Title: My Pet Project Monopoly 2

The Site and Player are reference, rather than value, objects, i.e. it does not make sense to take a copy of the 'Car' player, debit £50 cash from the copy, and expect that the 'Car' player itself is £50 worse off (although that probably would have been the intention had it been coded that way). It must be confessed that this implementation did not declare a private copy constructor, and assignment operator. Rather it relied on the programmer instead of the compiler to enforce the correct copy rules.

The following relationships exist between Players and Sites.

Bearing the required copy semantics in mind, it seems quite natural to want to write:

Site& aSite (aPlayer.Location ());  
  // or…
Player& aPlayer (anAssetSite.Owner ());

This means, though, that neither Site nor Player is a standalone class; each is dependent on the other. I wouldn't want that dependency if I could help it, but in this case I haven't really come across a better solution. References [1] and [2] address this issue in depth - perhaps I should go back and re-read them)

Another interesting dependency involved the AssetSites and the colour group to which they belong. In this implementation ColourGroup and Site were referred to in two ways each(!), (yes, I did say two!). First they both were enumerated types. The ColourGroup enumerated type was passed to an AssetSite when the object was created.

Secondly, they were in global (again!!) arrays. The Site* array, already mentioned, representing the board, and a ColourGroup* array indexed by the enumerated type for a given colour group, for each set of the Site's enumerated types.

If one were to add new sites or colour groups then two places in the code would need changing, one - the addition of the appropriate enumerated type and two - the creation of the object itself. Although this works it clearly isn't good practise - it would be easy to forget (or overlook) changes one of those places.

Colour groups need to know about the sites that make up the colour group. It's debatable if sites need to know about their colour group, but (ignoring necessary casts) it seems natural to want to write:

AssetSite& anAssetSite 
                (aPlayer.Location ());
ColourGroup& colourGroup
          (anAssetSite.ColourGroup ());

But we cannot have the following constructors:

class AssetSite {
public:
  AssetSite (ColourGroup&, etc…);
};
class ColourGroup {
public:
  ColourGroup (AssetSite&, AssetSite&);
// Utility, Mayfair & OldKentRd
  ColourGroup (AssetSite&, AssetSite&, AssetSite&); // Most BuildingSites
  ColourGroup (AssetSite&, AssetSite&, AssetSite&, AssetSite&); // Stations
};

because an asset site cannot be created until its colour group exists, and vice versa. So do we have a default constructor for a colour group, then add the sites later, or ignore the colour group when the site is constructed and assign it later? Which, if any, of these is appropriate should come out of the design process and this gets discussed in the next article.

In this implementation it can been seen that, when we look at the hierarchy under AssetSite, that the AssetSites represent two things. One is the Site itself - the player lands on the site and something happens. The other is they represent an Asset that is owned by a player, i.e. the TitleDeed cards. The distinction between these representations was not made in this implementation.

This application lends itself naturally to the Model-View-Controller pattern. However this design and implementation wasn't based on the pattern and any similarity was pure happenstance.

The purpose of the pattern is to separate the data from the user control and views of the data. More details on the pattern in general can be found in references [3] and [4]. It is also discussed, with respect to this project, in the next article.

This implementation described here partly failed in this respect.

As you can see from the diagrams opposite, whenever a user issued a command, the controller (theApplicationWindow) had an internal knowledge of the data (by direct access to those global variables), and manipulated them accordingly.

The viewing part of the system was slightly better organised. The main view onto the status of the game was known as the BoardView. This had it's own knowledge of the bitmaps representing the sites, and the icons representing each player, which means there's no dependency of the game objects (Site, Player etc) on the view, but the view (a window) still directly accessed the appropriate global variables. The same was also true of player status and auction dialog windows.

The standard template library wasn't around at the time this version of the program was implemented, but it would have been useful to use the container classes. I.e. all the current players could be stored in std::list<Player>, the assets belonging to a player referenced through std::set<AssetSite> etc.

But wait… we've already mentioned that Player and Site are reference based objects and not value based objects required by the STL. How we get round this and a different look at the game's design will be given in the final part of this article. Also we have a first stab at applying some Patterns.